Optimizing Mobile Games: 8 Very Critical Tips

Discussion and feedback on Construct 2

Post » Wed May 25, 2016 12:26 pm

I see a lot of user coming here with problems like
</br>
1)Game runs super slow on device
2)Black screen game won't run
3) Loading takes forever
</br>
So here are some thing to consider when making a mobile game run faster.
[list=]
1) Resolution= the best resolution is 650,350 or 800x480 once you start going into 960x640 your in game graphics will be much larger and take longer to load. Yes you can make a smooth running game at higher resolutions but it will be much harder.

2) Tilebackgrounds= you should always make your background into tiledbackgrounds . Using sprites will cause higher running memory usage.

3) Collision Checks= Construct2 is great at detecting collisions in a pixel perfect way. That said if you have sprites that don't have collision events, turn off the collision detection. That will be one less collision that your device has to compute and check for.

4) Graphics Size= Make your graphics the right size for example don't make a 400x400 sprite then resize it in the layout screen to 200x200. No the memory footprint is still 400x400 . Go into your graphics editor like gimp and resize the sprite correctly. If too many graphics are too big, you will get the black screen.

5) Event Sheets= Now this is tricky so please read very carefully. If you have 10 levels in a game you don't need 10 event sheets, repeating some of same code over and over in each sheet while adding new code to the next sheet. Instead for example have 3 sheets 1 for game events, 1 for player events, one for enemy events. Now in the game events sheet go to the top of the event sheet , right click on mouse a menu pops-up then select include event sheet. Now for each layout you can select the game events sheet and the other event sheets are included.

6) Timers= Be careful in using too many timers in your game. I use timers in all my games and can get away with using 7-8 timers per level with no performance problems just some glitches none game breaking.

7) Coding= over time learn how to minimize coding so there is less code your device has to run through to get information. I suggest you learn if and else statements to cut down on code.

8) Destroy Non used sprites= If you have a bullet flying offscreen and its never destroyed, it will keep using memory. If you have game elements that go offscreen you must put a destroy code so that each non used sprite is destroyed when not in the field of use.

[/list]

Example of game that uses 2-3 timers per level ,bullets flying left and right, 3-6 enemies per screen, larger graphics images, and still runs smooth then try my game to see

https://play.google.com/store/apps/deta ... ion.undead

Any questions or anything you feel I forgot just let me know.
Last edited by PixelPower on Sun May 29, 2016 7:50 pm, edited 1 time in total.
Check out my awesome Android Game releases https://play.google.com/store/apps/deve ... ames&hl=en
B
38
S
18
G
24
Posts: 682
Reputation: 16,615

Post » Wed May 25, 2016 1:47 pm

I'm sure your advices will come handy for newcomers. However keep in mind that it's not the event sheet number that is slowing down a game, but the unoptimized code. So building efficient code with great organization is more important. You can have that code on 100 event sheets, it will still run well.
B
135
S
33
G
17
Posts: 1,559
Reputation: 20,732

Post » Wed May 25, 2016 1:56 pm

glerikud wrote:I'm sure your advices will come handy for newcomers. However keep in mind that it's not the event sheet number that is slowing down a game, but the unoptimized code. So building efficient code with great organization is more important. You can have that code on 100 event sheets, it will still run well.


Yes but It make no sense for anyone to have 10 event sheets with the same code and only minor modifications in each event sheet. I have well over 100 events in my games no problem.
Check out my awesome Android Game releases https://play.google.com/store/apps/deve ... ames&hl=en
B
38
S
18
G
24
Posts: 682
Reputation: 16,615

Post » Wed May 25, 2016 6:10 pm

PixelPower wrote:Yes but It make no sense for anyone to have 10 event sheets with the same code and only minor modifications in each event sheet. I have well over 100 events in my games no problem.

Yes, reusable code is also important.
B
135
S
33
G
17
Posts: 1,559
Reputation: 20,732

Post » Sun May 29, 2016 7:51 pm

I saw at least 10 posts in the last 3 days about mobile performance. If you know about this thread please share it to help others thanks you.
Check out my awesome Android Game releases https://play.google.com/store/apps/deve ... ames&hl=en
B
38
S
18
G
24
Posts: 682
Reputation: 16,615

Post » Mon May 30, 2016 9:34 am

From doing a mobile game as well, I've learnt a few things that helped me to keep the performance smooth.

1. Limit TLE's (Top level events). I would say is the most important and keep this in mind at all times. The best way to do this is to Group Events in a smart way, and turn those groups off when they are not needed, and turn them on when needed. As your project grows you will have a lot events "listening" for the right conditions to be met. If you have too many of those running every tick you will notice a performance drop, so when those events are not needed, turn off the group. For example: if you have a couple of events that detects conditions between objects, close the group if that objects involved is not moving, or is not on screen, by distance, or any other smart way you can think of. The less number of events the engine has to go through every single tick the better performance you will have.

2. Structure the conditions in a smart way. If you have an event with several conditions try to limit the picking of objects. The more objects your condition picks the heavier this event will be. Be smart, and try to reduce the picking to as few objects as possible, using conditions. I managed to reduce my Z-Ordering for isometric game to only sort objects that are overlapping, only one time if they actually are overlapping. Instead of sorting the Z order each tick my z-order will only order once if any moving object is actually moving, and actually needs to be sorted. Took my Z ordering down from sorting all sprites in layout every tick, to only 2 overlapping sprites maybe once every 2-3 seconds if they are actually overlapping. Made a huge difference to performance. And again, closing the Zorder group altogether when not needed.

3. Use functions / Trigger once / or Once every XX seconds. Unless a function is called it's not gonna be using any performance and they are naturally triggered once when called, so have functions do most of your heavy work that doesn't happen so often, they are very flexible and can take a lot of params. Trigger once while true can be useful in some cases, but "once every XX seconds" even more so. For example: If your character is close to a pickup like a coin or whatever. You don't need to check every tick if that's the case. Reduce it to something like every 0.1 seconds, that way you will save a bit of processing power.

That's just some of the stuff I learnt while doing my game to have it run much smoother. Hope that Helps.
Follow my progress on Twitter
or in this thread Archer Devlog
B
41
S
18
G
18
Posts: 1,025
Reputation: 13,347

Post » Mon May 30, 2016 4:57 pm

@tunepunk Excellent additions most members don't know about groups yet but groups can be very useful since you can turn them on and off.
Check out my awesome Android Game releases https://play.google.com/store/apps/deve ... ames&hl=en
B
38
S
18
G
24
Posts: 682
Reputation: 16,615

Post » Mon May 30, 2016 5:27 pm

@tunepunk These additions come handy for PC development too, not just mobile. Thank you. :)
B
135
S
33
G
17
Posts: 1,559
Reputation: 20,732

Post » Mon May 30, 2016 10:07 pm

Just a few notes from me.

PixelPower wrote:1) Resolution= the best resolution is 650,350 or 800x480 once you start going into 960x640 your in game graphics will be much larger and take longer to load. Yes you can make a smooth running game at higher resolutions but it will be much harder.

960x640 is fine these days IMO. Just don't go for full HD yet. Dowscaling hurts a bit. Also worth to mention that you should not make a static resolution for mobile devices as there are different ratios.

PixelPower wrote:3) Collision Checks= Construct2 is great at detecting collisions in a pixel perfect way. That said if you have sprites that don't have collision events, turn off the collision detection. That will be one less collision that your device has to compute and check for.

Collisions are being checked only for objects which have collision events. And only for those instances which are within each others collision cell.
Setting collision to disabled for objects that are not "coded" will not impact the performance at all.

PixelPower wrote:4) Graphics Size= Make your graphics the right size for example don't make a 400x400 sprite then resize it in the layout screen to 200x200. No the memory footprint is still 400x400 . Go into your graphics editor like gimp and resize the sprite correctly. If too many graphics are too big, you will get the black screen.

If your game resolution is small and you set both your sprite and it's image to 200x200, you will lose quality while upscaling. In other words you will have bad quality image on modern device with Full HD resolution.
I suggest always use an image of at least 1.5x the sprite object size. So use image 300x300 and resize it in the project to 200x200.
ImageImageImage
B
28
S
16
G
82
Posts: 1,030
Reputation: 45,804

Post » Tue May 31, 2016 6:50 am

@BackendFreak

1) Yes you can use 940x640 but since this guide is for everyone I went with a lower resolution because I have seen most people don't understand how to optimize code fully yet. So for people 1-8 months I suggest lower resolutions but if you have more experience then 940x640 is fine.

3) I just went by what I saw Ashley wrote a while back. He has too many posts for me to search for it but I remembered it. So to play it safe I uncheck collision in sprites that don't have it.

4) My games the graphics scaled properly without having to put in a larger image and downscale it. I never experience my graphics messing up but I use pixel art so maybe other graphics type has this behavior.
Check out my awesome Android Game releases https://play.google.com/store/apps/deve ... ames&hl=en
B
38
S
18
G
24
Posts: 682
Reputation: 16,615

Next

Return to Construct 2 General

Who is online

Users browsing this forum: maddy467, Pooya72 and 9 guests