Mobile performance and optimizations tips

So I just released an Android game, which is far from done to be fully share and made aware of. But since early development, I've been hitting on some (fairly large) performance hiccups.

I have begun to try and fiddle with memory management using System's Load actions, but apparently I worsened things up. Now, after searching the forums for "performance", "optimization", "mobile performance" and only finding posts for 4 or 5 years ago, about Construct Runtime 2, I thought of asking.

What are the best performance tips for mobile games made in Construct 3? Are there any good docs for improving mobile performance?

While my game runs nicely on an OnePlus 5T with Snapdragon 835, it is completely unplayable on any mid to lower-end device, even though it is possible to play 3D games on those devices.

After reading some old posts (from 3~5 years ago) of people hitting the same problems, I'm starting to think that Construct is not a good platform for mobile games, unless they are some really small, simple games. And the advertised "near native" performance is not true, even on desktops.

See Performance Tips. This is up-to-date advice documented in the manual.

I must note that people often make games that exceed the hardware capabilities of their device and then blame Construct. You can't do more than the hardware specifications of the device allow - no software or tool will save you from that.

I have read it over and over again... I am currently in the process of revisiting all sprites to remove transparencies, review each layout's layers for mistakenly applied own textures, and changing every layout transition to add a loading and remove items from memory (as I have seen the app crashing, even when using Unload unused images).

Also I will be revisiting every event sheet and redoing them as thoroughly as possible to optimize performance, and try my best to run actions only as reactions to events only.

However, some more insight into how Construct manages memory would be a great fit there.

In any case, not to say I'm blaming Construct for the performance issues, I really love the engine. It is a great way of working, and really makes it easy to develop games, and I intend to keep using it. Maybe not so much for mobile games, as there was too much of a performance gap between devices (comparing the devices used, this was unexpected and includes the game crashing in some with the same amount of memory than others that it was working fine). Yet I admit, some of this may be on my end, perhaps for mobile games this (JS games) approach is not that close to native as we think...

Thank you for your work and for replying quickly, I'll get back with my results as soon as I finish running some optimizations on my game.

However, some more insight into how Construct manages memory would be a great fit there.

That's also covered in the manual.

I then refrain from what I said, and feel kinda embarassed. Also is the time for my sincere apologies, I took it on your work what is probably my own fault.

Nonetheless, I'm still working on optimizing my game and will bring back any further results, just in case there is anything that can be furthermore improved on both ends.

Thanks, and sorry.

I have the same problem with my games.

To save memory you can group many objects in a single sprite (each sprite animation being a different object). This will "cheat" construct and group all those elements into a single sprite sheet.

Taximan

To save memory you can group many objects in a single sprite

I must say that it has already crossed my mind and I'm thinking about doing this. Although that would require some major changes to my event sheets. So you really had advantages with this?

—

Please, share! But if you prefer I can contact you personally.

Ashley

I have returned to the docs and re-read a lot of stuff. But there is one thing I can't find info on is the Project property Max Spritesheet Size. I noticed it can make a huge difference (in my case, crashes) when increased. The docs do not cover it in the Project section.

Found some great blog posts about memory as well, great work.

Thanks for all the help!

Taximan

> To save memory you can group many objects in a single sprite

I must say that it has already crossed my mind and I'm thinking about doing this. Although that would require some major changes to my event sheets. So you really had advantages with this?

This is actually worse for memory management. Construct can only load or unload entire objects in to memory. If lots of objects are combined in to one it forces Construct to load everything, making it likely memory is wasted. If they are kept as separate objects there is better granularity to load some but not others, saving memory.

But there is one thing I can't find info on is the Project property Max Spritesheet Size.

It's only available on the beta channel at the moment. We only update the documentation when it makes a stable release.

Ashley > This is actually worse for memory management. Construct can only load or unload entire objects in to memory. If lots of objects are combined in to one it forces Construct to load everything, making it likely memory is wasted. If they are kept as separate objects there is better granularity to load some but not others, saving memory.

Group all the sprites that always appear together and only with the platforms the game needs 300 megabytes less.

This is the sprite sheet.

It is much more effective than this, which is what generates C3 by default.

Ashley

This is actually worse for memory management. Construct can only load or unload entire objects in to memory. If lots of objects are combined in to one it forces Construct to load everything, making it likely memory is wasted. If they are kept as separate objects there is better granularity to load some but not others, saving memory.

Good to know. I was thinking of joining my explosions into a single sprite, and change animations on demand, as many different ones are used in the same layout. Now I'm not so sure about it. But in either case, this gave me some insights into some ways I can improve performance.

It's only available on the beta channel at the moment. We only update the documentation when it makes a stable release.

Fair enough, was not aware that it was on beta only.

By the way, according to the docs, it is more efficient to group objects with the same effects on a layer with the effect. However I have some player avatars, that can be locked (fully black + alpha) and unlocked (colored + alpha). In this situation, which is better?

1. Add both images (locked & unlocked) as different sprites
2. Add both images in the same sprite as different animations
3. Add one image and generate the other using Set Color effect on a layer

Ashley

Are you using the latest release? The latest versions already group different objects on to the same spritesheet if they are consistenty used together on layouts across the project.

I use the 135. I do not know if we have to group the sprites in any way, or C3 does it automatically.

By the way, according to the docs, it is more efficient to group objects with the same effects on a layer with the effect. However I have some player avatars, that can be locked (fully black + alpha) and unlocked (colored + alpha). In this situation, which is better?

1. Add both images (locked & unlocked) as different sprites
2. Add both images in the same sprite as different animations
3. Add one image and generate the other using Set Color effect on a layer

I have figured, based on the knowledge gathered here and in the docs, that it is better to use the effect on a layer. Why? Adding another sprite for the same thing is too memory-consuming, maybe worsening the situation as there is one extra thing to pack and load at runtime. Am I correct?

I think the difference will be negligible if there are only a few sprites, so you should choose the option that is easiest for your game design. As ever you can answer your own performance questions with measurements; if the options make any meaningful difference to performance then you can measure it, else it's not important.

Ashley

As ever you can answer your own performance questions with measurements

Yes, thats exactly what I did. But it wasn't negligible in my case as there are 15 avatars, which would mean 15 extra black sprites. Went with the layer effect choice, and it is looking great, even on lower end devices now.

Thank you all for the help, and Ashley, sorry again for being so rude before.