About r191 (RE: Room Object)

Discussion and feedback on Construct 2

Post » Sat Dec 06, 2014 1:45 am

@Ashley To my knowledge, Rendering Cells & the new system action "Reset persisted objects" were to address the issues brought up in this thread.

However, I fail to see how they do so. The consensus was to add a single new action, something like "Reload Layout Zone (x1,y2,x2,y2)" with a button to specify which object types in that zone would be reloaded. This would allow us to dynamically load & destroy portions of a layout, which would be ideal for metroidvanias & open-world type games such as Zelda.

What I don't get is how "Reset persisted objects" is supposed to solve this, since it only works when you exit and re-enter a layout.

The rendering cells were also surprising because, with the above solution, "far off cells" wouldn't even exist outside of memory. Instead, the "cells" would be loaded & unloaded as you progress based on distance to the player (or however the dev wants), which would result in a lower average CPU/GPU usage. I suppose they are currently beneficial to GTA-style sandbox games where you have one continual seamless area with no resetting, but that's about it.

Is there something I'm missing? Is the "Reload Layout Zone" action still on the horizon?
Image
B
243
S
30
G
13
Posts: 1,787
Reputation: 18,770

Post » Sat Dec 06, 2014 2:42 am

I don't think render cells + reset persisted objects is a replacement, but it's a start. Just brainstorming, but here goes:

Think about a 'Reload Layout Zone' command. One of the problems will be avoiding a 'halt' every time a chunk is loaded/unloaded due to creating/destroying all those objects. One way to handle this is some sort of lazy loading; a 'timeToSpawn' setting perhaps. OTOH, what if we didn't have to create/destroy so many objects in the first place?

One way to handle this would be to have another command: 'Reload Layer Zone'. This would only reload the objects on a particular layer, within a particular zone.

This way, stationary objects (tilemaps, decorations, that sort of thing) can be put on their own layer w/ render cells enabled, and simply be left alone. The only objects that have to be spawned in/out are 'active' ones.

Thoughts?

Semi-OT: Somebody ought to bump that old 'Room Object' thread; some good stuff on there.
Don't lose your work. Backup your game with Dropbox.
B
44
S
10
G
10
Posts: 1,106
Reputation: 9,202

Post » Sat Dec 06, 2014 3:21 am

Ashley recently optimized the destroying of objects specifically for this. Loading on the other hand might cause a slight hiccup if your zones are huge but, as you said, lazying loading can fix that or the dev can put in some sort of transition.

The creation & destruction of objects is necessary to "reset" them when re-entering a room or zone, and making sure that nothing is going on outside of the current room or zone. What better way than just destroying them and calling them back when needed? Instead we got this new action that doesn't really apply here...

Layer zone isn't a bad idea either but you'd then have to specify the object types for each layer so that's a no-go.
Image
B
243
S
30
G
13
Posts: 1,787
Reputation: 18,770

Post » Sat Dec 06, 2014 4:38 am

I basically agree with you. I sincerely hope Ashley is still working on such a command. But, I see render cells as a stepping stone, not a replacement. I also see it as a companion to a 'reload layout/layer' command.

Yes, as you say, you would have to handle zone loading on a per-layer basis to get any benefit from render cells, but I still think it would be preferable in some circumstances.

For example: I envisage a zelda style game with seamless transitions between all zones, where tilemaps and immobile objects (scenery, houses, that sort of thing) are simply spawned in and left alone. Render cells should take care of any overhead they might pose. Then, all that has to be spawned in are active objects, which can all be on their own layer (or 2 or 3 layers).

On a slightly different note: what about the initial load? Let's say you have a massive layout with 30,000 objects in it. Now: what about mitigating the initial delay as those objects spawn in? And then, afterwards, we have to delete all but the ones right around us? Hmmm...
Don't lose your work. Backup your game with Dropbox.
B
44
S
10
G
10
Posts: 1,106
Reputation: 9,202

Post » Sat Dec 06, 2014 5:19 am

I'm just assuming this is everything because there have been 3 releases since that thread. If there are plans to continue with these features then yeah the rendering cells are pretty useful. I personally will be modifying the tilemaps at runtime so I'd still create/destroy them as needed, but they will be good for static backdrops.

The initial load has crossed my mind. All I can think of is a layout option like "Don't create objects at start of layout" and we can do it ourselves with zones. Maybe it ignores global layers or objects w/ persist behavior or something for HUD elements, player, etc.
Image
B
243
S
30
G
13
Posts: 1,787
Reputation: 18,770

Post » Sat Dec 06, 2014 2:31 pm

I haven't got round to the "recreate zone" action yet, but the last few releases have included bits and pieces to try and improve it whichever way you want to design your game. Also I think render cells are applicable to a wide range of game genres so are a more useful general-purpose tool to have. "Reset persisted objects" wasn't aimed at your request at all, it was for an unrelated request IIRC.

I think jank will be a problem if you create and destroy large numbers of objects at once, and it is difficult to see how that can be worked around. (It's not at all straightforward - you can try and spread out the creations, but then if the game keeps running you may run in to issues where you reach the new area before it's finished creating all its objects, and stuff randomly pops in to existence.) So one of the useful things about render cells is you can use them to avoid having to create and destroy any of your static scenery objects. They can exist over the entire layout and render cells allows the far away ones to have zero performance impact.

So then once we get 'recreate zone' you don't need to use that for any static scenery, just the changing things like enemies and powerups. Ideally that reduces the number of objects to create/destroy at a time to a small enough number as to make the jank unimportant.

Destroying large numbers of objects at once used to be particularly slow, but another recent release made that a lot faster. So I think we're getting there.
Scirra Founder
B
399
S
236
G
89
Posts: 24,519
Reputation: 195,361

Post » Sat Dec 06, 2014 2:45 pm

Oooh ok. Sorry for jumping the gun on that one ^^; Looking forward to the next release then!
Image
B
243
S
30
G
13
Posts: 1,787
Reputation: 18,770

Post » Sat Dec 06, 2014 2:50 pm

Also due to the r190 being stable, I would guess this would have been a risky thing to implement, I however am looking foward to this beta cycle, as it seems really promising!
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
53
S
22
G
18
Posts: 2,122
Reputation: 17,123

Post » Sat Dec 06, 2014 7:22 pm

Yeah, r191 brought an amazing number of improvements...I don't know how Ashley managed all that in two weeks. :shock: :mrgreen:
Don't lose your work. Backup your game with Dropbox.
B
44
S
10
G
10
Posts: 1,106
Reputation: 9,202

Post » Sun Dec 07, 2014 6:27 pm

Hey @Tokinsom
The 'reset persisted objetcs' is my fault. :)
It was needed to be able to "quit a game" (with persistant objs) to main menu and then "Start a new game". (so the objs get their original stats)
B
72
S
21
G
12
Posts: 314
Reputation: 12,116

Next

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 9 guests