Optimizing Mobile Games: 8 Very Critical Tips

2 favourites
  • 15 posts
From the Asset Store
Get the assets for your isometric games. Four sets of buildings with interiors and objects.
  • 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.

      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.

    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.

  • 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.

  • 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.

  • 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.

  • 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.

  • 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.

  • 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • tunepunk These additions come handy for PC development too, not just mobile. Thank you.

  • Just a few notes from me.

    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.

    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.

    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.

  • 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.

  • Hello! After going through a little bit of optimizing, my app went from 256 memory use to 132. How can I further lower this?

    Would you suggest a complete resizing of all images? My average sprite size is 600x600 px reduced to 200x200 to fit 480x640 screen.

  • Hello! After going through a little bit of optimizing, my app went from 256 memory use to 132. How can I further lower this?

    Would you suggest a complete resizing of all images? My average sprite size is 600x600 px reduced to 200x200 to fit 480x640 screen.

    Excellent!! Are you still having trouble running your game on your device ? If so yes your sprites should be the size they are in game.

  • Thank you for all your advice guys!

  • From my experience:

    Don't use effects on mobile! A very simple effect applied to a small sprite could cost a few fps on an older phone. Ten sprites with this effect - and the fps can drop down to unusable numbers.

    Blend modes with "Force own texture" set on the layer can also have a noticeable impact on performance.

  • Helpful information here. Thanks.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)