About r191 (RE: Room Object)

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?

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.

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.

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

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.

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.

Oooh ok. Sorry for jumping the gun on that one ^^; Looking forward to the next release then!

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!

Yeah, r191 brought an amazing number of improvements...I don't know how Ashley managed all that in two weeks.

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)

What's the current status on this?

As it currently stands, I'll probably keep my one-screen-per-layout approach to a nonlinear zelda-y world, since it sounds like it has very few drawbacks once I figure out how to seamlessly handle the transition between screens... (save player X and Y in a variable, maybe, and alter one or the other to put the player on the 'opposite side' of the screen?)

Televangelist There's no need to use multiple layouts as "rooms" now that we have the "Recreate initial objects" action and rendering cells. Check em out!

Won't the Events sheet for that single layout become very bloated, if it's clogged with the various NPC interactions, events, etc. from a dozen different screens?

Check out "event sheet includes". The idea is to have a "parent" event sheet attached to a layout, then other event sheets attached to that.

The other thing I worry about is if I'm making my zelda-y world multiplayer... far and away the easiest way to avoid too much data having to sync back and forth seems to be that players only 'sync' with each other if they're on the same screen together. If they're on the same layout, that's easy; not sure if it's equally easy if you have one large layout separated out like this.