Objects on layouts vs. event creation

Discussion and feedback on Construct 2

Post » Wed Apr 24, 2013 4:27 am

@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?
Project Lead of Zems Online Card Game

Producer at Impulse Limited
B
18
S
6
G
3
Posts: 677
Reputation: 5,194

Post » Wed Apr 24, 2013 5:11 am

I think where C2 is inefficient is objects that have animations (they'll still animate offscreen - even if under the hood it's just keeping track of the frame number and increasing that - 1000 objects is still more than the few that's onscreen) and objects with a behaviour like the bullet behaviour will still move around offscreen and so on. I don't think an invisible zone trigger would matter in those circumstances, since you have "inverted if object onscreen" event to control those. Of course, having an invisible zone trigger would mean you could have some turret fire at the player even if it's 500 pixels (or whatever) offscreen.

Is it just an asteroids game? Or a bit more complex?
B
15
S
5
G
7
Posts: 877
Reputation: 5,650

Post » Wed Apr 24, 2013 5:21 am

@procrastinator

You can play the latest version of the game (arcade mode) here: http://exeneva.com/html5/IcarusWA

The next step is to turn it into an iOS space shooter with a campaign, and the campaign levels won't have wrapping but will involve a large layout and many objects to be rendered.
Project Lead of Zems Online Card Game

Producer at Impulse Limited
B
18
S
6
G
3
Posts: 677
Reputation: 5,194

Post » Wed Apr 24, 2013 7:59 am

Ahhh nice!

If you had a LARGE layout, for example, 10000x10000 and let's pretend you had 100 zones, laid out in a grid like fashion. So each zone would take up 1000x1000. Each zone would have its own invisible trigger (an invisible 16x16 rect scaled up to 1000x1000 to save on memory).

You would dynamically create each zone rect at start of layout. Add an array to the rect in a container. So when each rect is created, the array is created with it. Loop through all the rects and store each zone's ship positions / types in the array and then destroy the objects / ships (except in the zone the player is currently in).

When the player leaves each zone and enters another (basically testing if the ship overlaps that zone's rect), the one the player leaves would save the positions and ship types in an array that's attached to that zone at the time of leaving, and then destroy those objects. If a ship is onscreen but is attached to the previous zone, then don't destroy it, instead attach it to the new zone. This way you'll only be dealing with the ships in the current zone, plus any others that straggled into the new zone. Then you won't have ships suddenly disappear when entering the new zone. It seems simple enough in my head, but I imagine it could be quite complex when you get down to it.

Does that make sense? It does to me, but I'm not sure if I've explained it correctly. Sleep deprivation and all that ;p
B
15
S
5
G
7
Posts: 877
Reputation: 5,650

Post » Wed Apr 24, 2013 11:33 am

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).
Scirra Founder
B
359
S
214
G
72
Posts: 22,946
Reputation: 178,518

Post » Wed Apr 24, 2013 11:37 am

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.
Jack of all trades, and master of some.
B
29
S
9
G
7
Posts: 174
Reputation: 7,601

Post » Wed Apr 24, 2013 11:42 am

Oh, forget about the array part, my mistake, but the rest is valid.
Jack of all trades, and master of some.
B
29
S
9
G
7
Posts: 174
Reputation: 7,601

Post » Wed Apr 24, 2013 11:44 am

[QUOTE=Excal] @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?[/QUOTE]

Just use the distance equation in C2, or simple math to determine the players zone area.
Jack of all trades, and master of some.
B
29
S
9
G
7
Posts: 174
Reputation: 7,601

Post » Wed Apr 24, 2013 12:19 pm

[QUOTE=Ashley] 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).[/QUOTE]

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.
Project Lead of Zems Online Card Game

Producer at Impulse Limited
B
18
S
6
G
3
Posts: 677
Reputation: 5,194

Post » Wed Apr 24, 2013 5:32 pm

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.
B
49
S
11
G
10
Posts: 1,833
Reputation: 14,418

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 4 guests