Optimizing a game for mobile platforms. Your tips?

Get help using Construct 2

Post » Tue Oct 29, 2013 6:43 am


Update.
It appears that half of the post got cut off...
I'll upload to pastebin or a similar site.
posted here as text: http://pastebin.com/aiFyQtjQ
Also, here's the post, uploaded as an imgur album (with links below the images):
              IMGUR ALBUM

You'll have to excuse me for this method of posting, but it appears that the forums tried to remove links from my posts and because of some error removed more than half of all the text (i've tried to re-post it a couple of times, but the post just won't update properly).

Update.
The whole post, now right here on the forums!


tl;dr - a rather long post describing things i've found about optimizing the performance, asking for you to share your own experiences etc.


Let's say that you are making a game for mobile platforms, more specifically, a game that would work on the older/cheaper Android smartphones which don't have dedicated graphics chips (graphics are not "accelerated", system memory is used instead). Now, since we are going for optimal compatibility, let's say that you've decided to opt for exporting the application to an .apk file (or simply because you intend to upload it to Play Store, once it's finished), using something like CocoonJS, so you can forget about the fancy WebGL and shader effects - canvas2d is what you'll be using.

While this means generally worse performance (and inability to use certain features, such as the image memory stat in the debugger), it also guarantees that the performance will be more consistent across the board (since you won't have such a gap between devices that support WebGL and the ones that don't -> no huge performance difference). Obviously, this will create some limitations for you, but also encourage you to use better practices in creating the game, so that the memory is used more efficiently (unless you go "hnnng" while playing games that run at <10 frames per second), which is one of the reasons this thread was made - to share experience and tips.

First off, let's assume that you've lurked the site and have found and read (to a degree) read some articles describing things that are commonly done to ensure decent performance:
- Best practices
- Performance Tips
- Performance Tips for Mobile Games
- Remember not to waste your memory
- Optimisation: don't waste your time

And that you have a rough idea (a tl;dr, if you will) of things that affect the framerate of your game:
>   processing the game logic (usually little impact, <10%) - if your game isn't stuck in endless loops and doesn't have memory leaks, you really shouldn't have to worry much about this part
>   rendering things on screen (most of the processing time goes here, >90%) - this is where you will be spending most of your time while optimizing the game, this includes things like drawing the sprites, moving and rescaling them, changing opacity and blend modes, effects (however those require shader support and WebGL), pretty much most of the things you see happening on screen at any given time, such as particles being emitted, various objects moving across the screen, and even text being drawn, will have some effect on how well the game performs

So, you eventually come across do's and don'ts of design process, a couple of which (the ones i think should be mentioned) i'll list here.
/mind that the things mentioned might be out of date, as noone is capable of keeping up with all of the changes made by newer updates, however in such case someone would probably point these things out



Sprites and other visuals.
The amount of pixels rendered will have the most effect on your memory usage, therefore most attention should go into ensuring that things are done as efficiently as possible. So, the question is "Wat do?" Before giving the answers (or trying to), however, i feel like i should also point out what not to do.
/most of the list turned out to be about the things you should not do, such is life, i guess

DO NOT use unnecessarily large textures for your objects - if you are making a game for mobile platforms, anything above 512x512 is overkill

DO NOT make huge background images - while this tip is similar to the previous one, i'd like to point out that, in case you have a need for backgrounds that take up large portions of the screen, then you should consider creating the background from many different images of lower resolution on a separate layer (so you can manipulate it later), perhaps tiling things or stretching them, where possible

DO NOT make images with large areas of transparency - as described in one of the articles i linked, transparent particles also take up space, therefore you should try to keep empty areas to minimum, perhaps slice up your image (but only bother if it's pretty big) in many smaller and use something like the "Pin" behaviour to keep them together

DO NOT have too many semi-transparent pixels in your images, change the transparency in steps - it is generally more efficient to have either full transparency or no transparency (image format-wise too) in case you need to make a fade effect, i'd suggest that you avoid fade/sine behaviour, and opt for changing transparency in increments of 5 or 10, perhaps by using a function, as this should be more effective (because it's not done every tick)

DO NOT resize/rotate sprites every tick - see above, you could move the image by x pixels at regular intervals, small changes shouldn't even be noticeable to the eye, animations should also be played at moderate speeds

DO NOT have too many images in your layers - reuse things where possible, delete any obsolete ones as all of the images in a layout will be loaded into memory as the layer starts and will be cleared only after a new one is opened, keep this in mind when making animations

DO NOT assume that the images that are invisible don't take up processing time, this is false - they are still rendered if the object is not destroyed, so you should consider either destroying it, or moving it off the screen, which will stop rendering it, i guess you could do this for whole layers (in situations where a layer represents)

DO NOT use effects for permanent changes - don't do things like applying a grayscale effect to an image as a permanent way to alter it, use image editing software such as GIMP or PAINT.NET and add another frame as an animation, instead

DO NOT use particles unless necessary - if you intend to create an explosion or another effect, where a big amount of particles is needed (to create an area covered in them, or similar effects), then you should consider using animated sprites with an additive blend mode, or at least keep the sprite resolution low (e.g. something like 4x4 pixels, scaled up). of course, keep in mind that if your sprite would have large areas of transparency, you would be better off using the particles

DO NOT use retina display - as shown in the performance benchmark, the framerates are almost 2 times lower when this feature is on (then again, Android devices don't have those :P)

DO compress your images - while this will not improve performance, since the images are decompressed they're loaded into memory, this will decrease the download size immensely, allowing your game to load much faster. you should use .jpg for compressing images with no transparency and .png for images with transparency (also, if there are no semi-transparent pixels and less than 256 colors in the image, you could use PAINT.NET to save the image as png-8). if you want to see how much space the image takes up when decompressed, open it in GIMP and look at the lower left of the screen, keeping tabs on this information helps you figure out ways to optimize your game further(example of what i'm doing)

DO use Spritefont instead of Text - it is often mentioned how the spritefont object is faster than the text, and of course there is also the added ability of having various symbols you wouldn't normally have access to if you used the normal font plugin (also, incompatibilities with webfonts were/are present when the game is opened in Chrome with WebGL on - might be somewhat irrelevant to this particular thread, however). what i like to do, is to create a low resolution font and then scale it up as needed, as this should be quite memory efficient (example text spritesheet, 64x96)

DO create your images in lower resolution and rescale them - memory usage is only affected by the source size of the image, not what size it is drawn at on the screen (or so i've been told), so you could create your image at 32x32 and rescale it to 64x64 and save a decent amount of memory (percentage-wise). because of this, i recommend that you use pixel art - just remember to set your sampling method to "point" and rescaled images won't be smoothed, otherwise some ugly visual effects will appear

??? stretching vs tiling - this part is what i am not sure about, yet to me it seems that stretching a 1x1 pixel to 256x256 would be more efficient than tiling it for producing a solidly colored background (of course, usually the layer background color parameter should be used for that). either way, it was pointed out that using the tiled background object is more efficient than doing the same thing with a bunch of sprites, so there's that...



Sounds.
I really haven't got much advice to give in regards to this, but there always are a couple of intuitive things you should know (unless i got this wrong).

DO NOT use higher bitrates than needed - 96-128 kbit/s should be good enough for most sounds used in mobile games, as the sound quality is often limited by the hardware on these platforms, therefore it most likely won't be necessary to use high bitrates (such as 256 kbit/s). it should be remembered, however, that the format is of little importance here, as the sounds are converted upon being imported into C2

DO split your music tracks into looping parts, or split the repeating sections (e.g. bass or drum rolls) and repeat them over the main beat - while this might be somewhat cumbersome, there really is no need to have the same fragment of audio repeated twice (or 3, 4, 5, n times) in a song, as that is wasted memory. just remember not to have too many channels playing sounds at once.

??? mono vs stereo - it would seem to me that there should be little difference in regards to sound quality between using mono and stereo sounds, as the speakers are pretty close together on mobile devices (unless peripherals are used), which means that using mono sounds would be pretty effective in saving memory, as the trade-off in quality would be minor



CPU intensive processes (behaviours).
Little snippets of information i've gathered in regards to physics, pathfinding and collisions

DO NOT use physics, unless absolutely necessary - physics can slow your game down quite a bit, therefore you should seek alternatives, such as writing your own formulas for simpler tasks, where the full list of physics features is not needed

DO NOT re-generate the obstacle map unless something changes - this is listed as a CPU intensive process, so you should only do this if something changes in your map, that would prevent movement (tiles that don't affect pathfinding are unimportant), upping the grid size is sometimes also mentioned as a remedy

DO NOT check for collisions too often - if the movement speeds of objects in question are slow, then you can do this at regular intervals


This sums up what i've read on the forums pretty well.
And yet, i'd like more advice. What have you guys got to add?


Also, can anyone explain to me, why my Spritefonts and 9-patches are garbled up like this in the layout editor but perfectly fine in preview? (i made this in r139 or something, shown here opened in r142 - this was persistent in r139 too)

The PC in question doesn't support shaders, if this helps explaining the situation.

Stiivais2013-11-01 10:18:35
B
10
S
1
Posts: 163
Reputation: 1,436

Post » Fri Nov 01, 2013 10:17 am

Bump?
I'd really like it if you could spare a minute and look at this post, so i can finally get some answers about the validity of these statements.
B
10
S
1
Posts: 163
Reputation: 1,436

Post » Sun Feb 16, 2014 7:13 am

Interesting post.
Thanks
B
157
S
27
G
17
Posts: 910
Reputation: 32,588

Post » Sun Feb 16, 2014 7:33 am

thanks for tips if i read this i think we cant do good game with big world to mobile.

I do some research and i see if i have game with resolution 480x 240 and when switch game to full screen with letterbox scale, game runs in lower FPS

An i have question better to have one big tiled background or 5 smaller?delgado2014-02-16 07:39:54
B
109
S
26
G
46
Posts: 1,886
Reputation: 35,168

Post » Sun Feb 16, 2014 8:17 am

Very nice summary. I have been using some of these practices in my game already. Although, I still think there is something bogging down my game. Not sure what it is yet.
B
56
S
15
G
13
Posts: 826
Reputation: 17,645

Post » Sun Feb 16, 2014 8:23 am

Wow, thanks for this post. And I would really like to see what some of our members think of its efficiency as well.
B
45
S
23
G
31
Posts: 688
Reputation: 20,602

Post » Sun Feb 16, 2014 12:12 pm

The responses took a while, someone must have done some serious lurking... :)

@delgado - the problem with the fps is most likely caused because the amount of pixels that has to be rendered has increased, you could try working around this by using the low quality scaling option present in the newer releases of C2 to get similar performance.

It is indeed better to have 5 smaller background images as opposed to having one large one, because those off-screen won't be rendered, you could probably destroy the image objects to clear some memory, too!
B
10
S
1
Posts: 163
Reputation: 1,436

Post » Sun Feb 16, 2014 12:23 pm

Use Tilemap heavily. If there are any sprites left in the project that have no code tied to them, transport them over to Tilemap.
HARMLESS SIGNATURE THAT IS VIEWED BY OTHERS AS OFFENSIVE AND CONTROVERSIAL
B
14
S
3
G
3
Posts: 356
Reputation: 4,377

Post » Sun Feb 16, 2014 2:53 pm

@Stiivais you say and this is true :"the problem with the fps is most likely caused because the amount of pixels that has to be rendered has increased, "

but it should not be.delgado2014-02-16 14:59:23
B
109
S
26
G
46
Posts: 1,886
Reputation: 35,168

Post » Sun Feb 16, 2014 8:10 pm

I don't think that i entirely understand what you mean by this.
Let's suppose that we have a game that is running at a resolution of 320x240. This means that the game's area is represented by 76'900 pixels, which have to be redrawn each tick. Now, if we increase the resolution up to 640x480, then there are 307'200 pixels that need to be updated now, a difference of 3x the original amount! This will obviously be a performance hit for any game...
B
10
S
1
Posts: 163
Reputation: 1,436

Next

Return to How do I....?

Who is online

Users browsing this forum: ChoosyZerk, lukewasthefish and 16 guests