Hey guys! I have recently finished developing my first game ever!

It's been released on Google Play, for Android only (for now). I'll leave a video and a download link here. Hope you enjoy.

https://play.google.com/store/apps/details?id=br.com.gryphongamestudio.alienssettle

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.

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?

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

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!

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

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.

I am going to have to change a lot of things, but this is the best solution indeed. It will also allow for better customization of each shooting. This is what I needed. Thank you both for your help!

—

well not with 1 turret, but, if you have a spaceship and the guns are different sprites attached to the spaceship then you could use multiple turrets.

Have not thought of that. Great idea! Thank you.

—

Didn't understand how that would work. Can you add some details, please?

Now I get what you meant. It's a nice approach, indeed.

But in your demo, only one weapon can be used at a time. In my case, however, I want the spaceship that has Minigun and Missiles to both be used at the same time, with their respective fire rates. So that Minigun fires at 0.25 and Missile fires at 2.

Using only one turret behavior is not possible at the time, I'm afraid. Unless I set some variable on shoot, and see if it's the 8th time it has been fired. This works, but when you get to 5 different weapon types with differing fire rates (which is my case), this get out of hand pretty quickly.

I think we are not understanding each other, allow me to clarify my problem...

Let's say all my spaceships have two possobile weapons: a minigun and a missile launcher.

The Minigun has a fire rate of 0.25 seconds and the Missile launcher has a 2 seconds fire rate.

I have renamed the behaviors to Minigun and Missile, respectively, and am using "On Minigun shoot" and "On Missile shoot" events to spawn the bullets.

The distance is irrelevant (set to a large value), and rotations are disabled for both (I'm controlling it manually).

Both turrets are in the Spaceship family, toggled for each sprite needs (having one or both), and all of them have the Enemies family as target.

My issue is that when I have both turrets enabled, the "On Missile shoot" event is currently being fired 4 times per second (fire rate of 0.25), when only the Minigun turret should.

If I disable the Minigun turret, the Missile turret behaves as expected.