Mobile Game Performance

I recently started a new game project that I plan to publish to the App Store and GooglePlay. My game will only be available for tablets with a screen resolution 1280x720 and above. I'm mid way of finishing my game, but I'm wondering if my game will run smoothly on tablets.

So my question is how many collision checks is too much?

Also how much Image memory usage is too much?

Is 40% CPU utilisation too much?

Inspector:

CPU 36%-40%

Est. Image memory 64MB

ObjectCount: 289

Collision Checks: 5806 (~142/tick)

I tried my project using safari on my 2gen Ipad 2, and chrome using my galaxy tab 4 and both of the tablets ran the game smoothly, but there will be times where the game will lag for bit. What are your experiences designing games for tablet?

ThunderLion

It's a bit all over the place for me when it comes to mobile performance.

Generally though I get at least 40 fps at more intense parts in some of my prototypes but most of the time it stays between 55-60 (My pixel golf game for example)

Main performance hits I have noticed and had to work with:

• Particles
• Collisions (make sure you turn off collisions on objects that don't need it since it is a default for some things)
• TEXT, for the love of god make sure you use sprite fonts and not the basic text
• Effects can make performance go down if too many
• The way you compile the game for mobile...it's odd..sometimes when I just throw my game on my phone and start it in CocoonLauncher it runs great but then try xdk and it runs poorly. But then other games they run horribly on cocoon but great on xdk...
• TEST TEST TEST on mobile devices, cannot stress that enough test A LOT

Good luck and have fun!

So my question is how many collision checks is too much?

Also how much Image memory usage is too much?

Is 40% CPU utilisation too much?

There are no fixed answers to these questions. If the game runs acceptably on an acceptable range of hardware (according to whatever your targeting is), then those numbers aren't really important. They might come in to play if the game is not running acceptably, to help guide your optimisation efforts. Don't optimise things that don't matter.

ThunderLion

As others have suggested it's difficult to really say what you should be aiming for. However from experience here are a few tips as guidelines.

1. Try to aim for CPU usage on a pc of 5% to 10%. This goes up the newer the minimal mobile hardware you are using. So iPad 3 and the most recent Android you could aim about 20% to 30%.

2. Try to keep collisions to a few hundred. Even on PC there is little reason to go over a few hundred.

3. Turn off object behaviour(collisions, movement...) when you don't need them. Such as when they are off the screen.(unless you need world simulation)

4. Group Sprites images, layout images, Hud wisely. Don't make a ui where 1 image counts as 1 sprite. all Menu UI should be on 1 sprite object, all game UI on 1 sprite object. If you need ui elements on both. It's ok to have 1 sprite object that exists in both game layouts and menu layouts.

5. Use Plugins more than Event Sheet. Try to keep ES code to just plugin interaction. If you need a feature, find a plugin or write one in the SDK as a plugin.

6. Try to keep your active game memory to 150 or less.

7. Constantly check you game on a device. If it's annoying. Check your game on the device after every new feature. If you add 5 new features and are finding performance problems. Only 1 of them might be the problem and you won't know which one.

8. Fx/Shaders are a total hit and miss on mobile. There should be(but isn't) a list of what FX/Shaders will run on mobile effectively and others that kill performance.

9. Ashley and I don't agree on optimization efforts. Maor at one point was told not to bother doing optimization. There was little he could do with enough performance impact. The game ran at 5fps(on mobile) and crashed. We sat down for 2 months going back and for over email and got the game running to 50fps+.

10. Study a lot of graphic texturepacking. C2 does texture packing for you, but you need to understand the effects of texture packing has on hardware so you can best take advantage of C2 texture optimization.

9. Ashley and I don't agree on optimization efforts. Maor at one point was told not to bother doing optimization. There was little he could do with enough performance impact. The game ran at 5fps(on mobile) and crashed. We sat down for 2 months going back and for over email and got the game running to 50fps+.

I don't understand completely, should we try to optimize or not?

— try to optimise your logic first (are there any dumb things you tell the game to do that are simply a waste of time? The case jayderyu made with disabling behaviours would be just that, if you game does not require that you update the positions of the ennemies that are far away, might as well "put them to sleep")

Then try to see if there is something that is draining your performances down, if easily spotted, correct it without influencing too much your game if possible, if not spotted that easily, try to experiment and see.

However micro-optimisation is not worth the effort when it comes down to fighting with the engine (if a flappy bird game doesn't run well because "not optimised enough", don't optimise it, changing engine would be a wiser idea in the long term, perhaps even mid term run, and since you have done a design work on your game probably, porting it over will hopefully not be as bad as it sounds), not saying it will not work though if you want it really.

To be honest, micro-optimisation is something the engine should already be taking care off, if you feel it is not doing it's job properly, try to see for other alternatives, C2 is a web-based runtime game engine, any other use is not warranted to be perfect.

Tl;dr try to see if the logic is flawed first, or incomplete ("we did not agreed on the fact ennemies should be doing things far off the screen or not, the game design doc we did said nothing about that nor the requirements, so what should we do?"), then profile the game and see what is bringing it to the knees, then see if you can work to make that better or if using another engine is a better choice.

Keep in mind that this advice is applicable because of the fact C2 adds a pretty visible overhead due to its browser based nature, and this overhead can be tricky as, while great games can be done on a very limited system when we know it, here the knowledge of the system is not easy to understand as the browser layer can be really nasty or even not related to the hardware.

—

Optimization for a Unity game

http://robotinvader.com/blog/?p=438

I work in Unity at a game programming company. And even our "simple" core mechanics still get's micro optimization treatment.

http://venturebeat.com/2015/07/17/pac-m ... on-mobile/

Even unreal engine 4 has topics about optimization

https://docs.unrealengine.com/latest/IN ... index.html

C2 does a lot of optimization, but this doesn't mean optimization efforts shouldn't be worked on. As the first link shows a game that would barely run was made it to playable on old devices.

Micro optimization 10 different areas does add up. but be prepared for a lot of work.

>

> 9. Ashley and I don't agree on optimization efforts. Maor at one point was told not to bother doing optimization. There was little he could do with enough performance impact. The game ran at 5fps(on mobile) and crashed. We sat down for 2 months going back and for over email and got the game running to 50fps+.

>

I don't understand completely, should we try to optimize or not?

I don't think we disagree, my point is that you should only optimize when you have measurements indicating that performance is not good enough, and in that case, your optimisations should be guided by the measurements. Too often people try to optimise things that have approximately zero impact, because they don't know what the real issue is. Obviously if a game is running at 5 FPS that is a clear sign performance is not good enough, and using other measurements can help guide you in to improving that.

For my game i noticed most performance improvements by limiting the amount of top level events and listeners. Keep the event sheet tidy, place events in groups and disable groups of events when not needed. After disabling groups I managed to increase the performance a lot.

I'm not sure i follow this one ? why would it matter in which way the images are organised - as far as i have understood there is really no difference performance wise whether you have 10 sprites or one sprite with 10 frames. am I wrong ?

4. Group Sprites images, layout images, Hud wisely. Don't make a ui where 1 image counts as 1 sprite. all Menu UI should be on 1 sprite object, all game UI on 1 sprite object. If you need ui elements on both. It's ok to have 1 sprite object that exists in both game layouts and menu layouts.

5. Use Plugins more than Event Sheet. Try to keep ES code to just plugin interaction. If you need a feature, find a plugin or write one in the SDK as a plugin.

Interesting. I might look in to that to see if i can get any further performance improvements.

Is there any particular events/conditions that can benefit more than others from this? If so, any recommendations?

Kali

This is more applicable to the GPU rendering pipeline rather than canvas. A GPU can render images extremely quickly if the GPU does not need to change the texture in the GPU memory. We are talking about 10,000's of sprites being drawn in a insignificant amount of time. A GPU stores 1 texture in the render pipeline. That texture max size is always a power of 2 square. New GPU's store 4096x 4096, however the current target standard 2048x2048. so let's pretend 2048 is your GPU's limit for this discussion.

(numbers are sample figures at this point because actual figures go into higher decimal points)

If you can store 10 "sprite" images onto 1 texture. And the gpu can draw 10k pixel fill per drawcall. Let us also set it up that there are 10 types of bullet graphics that we cycle the colour through. All of them stores in one texture. When we shoot 10k bullets, and cycle through the colours that's 1k of each bullet graphic. And let's say it takes 0.0016 of a second to make one drawcall. That will allow you to have 10k bullets drawn at 60fps. As it's only doing 1 draw call and are figure ways it's ok to draw 10pixel draws per call

ok. now let's say you make 10 sprite objects(I am talking about individual Sprite Objects, not Copy/Paste of of a single sprite object) 1 object per bullet type. The situation is the same. We are going shoot 10k bullets, cycle through creating a bullet so we will use each SpriteObject bullet 1k. Since each bullet graphic is on a different texture(details in a sec). This will force the GPU to have to swap the texture in ram for each bullet type and do another drawcall for that bullet type. So if it takes 0.0016 seconds for 1 draw call. that now takes 0.016. Which isn't 60fps anymore. it's 10 times longer. it's 10fps not 60fps.

And what's worse is what if those bullets overlap each other. Then the GPU needs to swap again back to a re-used texture because it needs to draw over an image of another texture. This could lead to even far less fps. However if you pack all 10 bullets onto 1 texture, then the gpu can write over itself a ton of times without ever needing a new draw call.

And to take advantage of drawcalls in c2. C2 packs images into textures based on Sprite Objects. So 2 different sprite Objects will be 2+ different textures. C2 will pack as many images in the frames and animations into a single texture of that Sprite as possible. However any images in a different SpriteObject will always garunteed be a different texture.

So developers who use 1 SpriteObject per graphical UI element, enemy, environmental objects are killing their performance.

tunepunk

I doubt it would be a massive performance. In this suggestion it's more about development performance and organization. Write new features for large projects using ES is not optimal.

thanks jayderyu thats a really good explanation of how it works..

Interesting topic, many thanks ; )