Mobile Optimization Tutorial Version2

0 favourites
  • 8 posts
From the Asset Store
a ready made template of Mobile Advert, Google Play and Mobile IAP Plugin,
  • Hi guys I know alot of you may have run into problems with your games and apps when running them on your mobile devices whether it's Iphone or Android . Here are the methods I use to make sure the games I make run smooth with no glitches,errors,bugs,slowdown,etc. I made a game that is a great example that has 30-40 sprites moving at the same time on a mobile device here

    https://play.google.com/store/apps/deta ... t.ad&hl=en

    1) Graphics Size-

    A) Backgrounds- you should always use Tiledbackground unless its an animated background. The sizes for optimal speed the background size can be 840x480 or 960x640 which you can have 30-50 moving sprites onscreen. At 1920×1080 and higher you are going to have to limit the amount of sprites you have onscreen to around 10-25. Now also when we talk background size below 300kb is optimal. Once the size moves past 300kb you will have to start lowering the amount of sprites used onscreen.

    B) Sprites Size- The optimal range of moving sprites 20x20 to 140x140. The optimal size of the sprite file is 10 - 30kb. Now if any sprites sizes are larger than those you just have to reduce the amount of moving sprites. Also remember to cut out the transparent edges on your sprites to reduce memory impact.Non moving and non-used sprites- Make sure that you uncheck collisions on sprites that are pieces of the background but are not used in the game.

    2) Coding Practices- The optimal way to program so you don't have to much repeat code or bad code. Before starting your game make a quick draft on your computer of what you want to include in the game. The draft will include things like

    A) Start menu- what buttons will you put i.e. start , options, missions, rate me, etc.

    B) How many stages , powerups , story ,etc.

    Now of course you will add more to your game as you go along but doing a draft will help you organize code with this next part the Event Sheets . Split your Events Sheet by feature first so that you will not get lost in code. For example have a separate event sheet like Game Events, Player Events, Saving Events,etc. Here is an example look at the event sheets here

    Another tip is to break each block of code down into groups. That way you easily find your way around when you leave your project and come back. Also for each level you can break things down that only happen in that level but not other levels and you don't need a ton of event sheets to do it.

    3) Destroy Sprites not used- If any moving sprite is not used it should be destroyed. Even if a moving sprite is offscreen its still using memory and counted as an onscreen moving sprite .

    4) Music-- Sound files around 5-20kb are fine. Full music soundtracks can be up to 7mb with no problem. Make sure if leaving the layout you have a command to stop the music otherwise the music will keep playing and you will have 2 soundtrack playing over each other when you enter back to the layout.

    5) Guest Post tunepunk -- This post tips is his

    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.

    Any questions just ask!!

  • Nice tutorial

  • PixelPower - can you show how you got the numbers for sprite counts and sizes of images? seems a bit too small (30-50 sprites), especially if you want to use particles.

  • PixelPower - can you show how you got the numbers for sprite counts and sizes of images? seems a bit too small (30-50 sprites), especially if you want to use particles.

    I got the numbers by making my game and testing the limits . I didn't count particles because thats a bit different . You can have literally 100 tiny particles moving around with very little impact on game speed. But I doupt your particles each are going to be 40x40 sprite size ,30kb each particle or higher, that would impact speed.

  • can you make a testing capx with table of stats?

    you know that it also depends on your cpu?

    i bet my numbers would be different on my machine (i7/8gbram/gtx980)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • can you make a testing capx with table of stats?

    you know that it also depends on your cpu?

    i bet my numbers would be different on my machine (i7/8gbram/gtx980)

    The best to me is in actual application rather than stats. Thats why I put my game as an example of 30-40 moving sprites onscreen on a mobile device. The reason being is one developer can have a game with 50 moving sprites working smoothly but another developer only have 20 moving sprites and the game glitches and slows down.

    My guide is aimed at novice and intermediate level developers. In actuality I can have way more enemies onscreen like 100 or more. But Iam not going to tell another developer to try that if he has only been using Construct 2 for 1-5 months. When making guides you can't assume everyone's skill level is the same. What you do when making a guide is try to help everyone at every skill level.

  • That was useful as reference -- thank you! Have a look also at this post about collision cells, as it involves some coding practices that's good keep in mind.

    The only thing that's disheartening me is the soundfile sizes. Some of mine sounds are easily 200, 300kb...! 16bit mono wavs them all, short things like grunts and chops. 20kb is so... tiny.

  • That was useful as reference -- thank you! Have a look also at this post about collision cells, as it involves some coding practices that's good keep in mind.

    The only thing that's disheartening me is the soundfile sizes. Some of mine sounds are easily 200, 300kb...! 16bit mono wavs them all, short things like grunts and chops. 20kb is so... tiny.

    The rules are for super optimizing and running but they can be bent as long as you test the game often on your device. I suggest phonegap build for testing since its just 2 steps and then apk. So you can include those sound files . If you need to make them smaller go here

    http://www.online-convert.com/

    Good luck on your game!! And of course you need any advice we can help.

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