Objects on layouts vs. event creation

I'm not even sure zones are necessary. Unless zones are desired, one big array would work just as well. For a massive world, I would simply keep a cache of created objects for each object type (i.e. never destroy objects), then hide/show them on screen screen as they are needed. If more of a single object type needs to be on screen, it's only then you actually create another sprite. Even a zone itself might have more objects than will actually show on screen.

Oh, forget about the array part, my mistake, but the rest is valid.

procrastinator

Makes sense. I think for non-grid games, it's still more efficient to create all the objects through events, and just let C2 handle it.

But say we want something to not spawn until the player gets to a certain area. Would the best way to handle this just be make an invisible sprite across the area and trigger the objects once the player overlaps?

Just use the distance equation in C2, or simple math to determine the players zone area.

Regarding the OP question, the peak memory use is probably identical. However each option affects when Construct 2 loads the object images.

If objects are placed in the layout, Construct 2 will pre-load all the object's images (for all animations with Sprites) at the start of the layout.

If the object is not placed on the layout and you create it at runtime, Construct 2 probably has released the object's images to save memory. This means it has to load them the moment you create the object. This can cause pauses/stuttering at runtime.

Apart from that it should be identical. Basically, any objects you use on a layout should be placed on the layout, even if you destroy them on startup (C2 will still pre-load them).

Thank you for the clarification. Now I have another question: is it possible to preload layouts, then? A lot of other games have loading screens. Suppose I am making a large game, and I want to send the player to a 'loading screen' layout while the gameplay layout is preloaded (and have some kind of loading bar sprite update on the loading screen). Would it be possible to do this? I would rather have a loading screen than have the game 'hang' while its loading a large layout.

Before I go further, is this even needed at all since GPUs don't render what's on the screen? I understand the CPU is still tracking everything that isn't rendered, and mobile CPUs aren't very powerful right now.

The alternative is to implement some sort of manual background loading and have the layout load in segments, kind of like what procrastinator suggested. However, this is a complicated issue for non-grid games and coming up with a working approach might take some time and math to do. If this is the only way, procrastinator would you be willing to help me figure something like this out? The benefits of having some method of loading large layouts would be good for everyone who uses C2.

Just a clarification, did you mean gpus don't render what's NOT currently on the screen? On a side note while they may not render it on the screen at the time if it is already in the layout vs created on the fly it will still be using memory until destroyed regardless of it is currently being rendered, though this should be a much smaller hit on memory for instances.

Excal, I think that would really only benefit you if you had 1000s of objects on the layout. Every little bit of optimisation helps with mobile devices though, so even if you had 500 or so objects, it may help. I'm not sure my idea would even make a difference tbh. It was more of a suggestion to try if you had problems when you started on your next game. Obviously, as has been pointed out, you're going to have other issues, like stuttering.

If I have the time, sure, I'll pitch in when you're ready to see if we can come to some solution if you have performance issues. I've never needed to optimise because I usually only do smaller games on desktop, but that's not to say it wouldn't come in handy when I do create a game with a large layout with a lot of objects to track!

Sometimes the best optimisations come from rethinking the game design. In your case, adding something like motherships / bases where the enemy won't fly further than some distance away from said mothership / base. JoyfulDreamer's distance suggestion gave me that idea. You can destroy enemies not in the current zone, and because you've limited how far they can travel, you don't need to worry about storing ship coords etc when entering a new zone. So that way you can limit the enemies to different zones, while retaining a huge level, and no need for complicated code ;p