Mobile Game Performance

Discussion and feedback on Construct 2

Post » Sun Aug 23, 2015 2:27 am

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?
B
12
S
4
G
1
Posts: 100
Reputation: 2,362

Post » Sun Aug 23, 2015 5:23 am

@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!
Twitter: https://twitter.com/pudgyplatypus

Learn to make a clicker game for cheap!
https://www.scirra.com/store/games-with ... e-game-666

Try out Pixel Golf on the Scirra Arcade!
https://www.scirra.com/arcade/sports-ga ... el-golf-67

Pudgy Platypus Games website!
www.pudgyplatypus.com
B
59
S
20
G
5
Posts: 212
Reputation: 7,390

Post » Sun Aug 23, 2015 5:28 pm

ThunderLion wrote: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.
Scirra Founder
B
395
S
232
G
88
Posts: 24,371
Reputation: 193,782

Post » Sun Aug 23, 2015 5:56 pm

@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.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,018

Post » Sun Aug 23, 2015 6:07 pm

jayderyu wrote: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?
B
86
S
25
G
11
Posts: 652
Reputation: 11,051

Post » Sun Aug 23, 2015 6:33 pm

@lolva 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.
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
53
S
22
G
18
Posts: 2,122
Reputation: 17,123

Post » Sun Aug 23, 2015 9:52 pm

@lovla
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.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,018

Post » Mon Aug 24, 2015 10:45 am

Iolva wrote:
jayderyu wrote: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.
Scirra Founder
B
395
S
232
G
88
Posts: 24,371
Reputation: 193,782

Post » Mon Aug 24, 2015 12:14 pm

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.
Follow my progress on Twitter
or in this thread Archer Devlog
B
38
S
15
G
17
Posts: 949
Reputation: 12,320

Post » Mon Aug 24, 2015 12:54 pm

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 ?

jayderyu wrote:
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.

Image
Get it on Google play or play on papio.nu
B
11
S
2
Posts: 79
Reputation: 786

Next

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 9 guests