#How to persist data between levels?

1 messages · Page 1 of 1 (latest)

leaden cobalt
#

If each level is a separate Scene, then for a DOTS project, how would you persist data between Scenes? Data could be story mode-wide stuff like coins collected, inventory, moral compass, enemies killed, etc. Also, what’s a good way to change this persisted data, like upgrading your equipment using your inventory before a level begins? Finally, how can a Subscene use this persisted data to bake entities? For example, there are two characters in a subscene Player and AI. AI’s appearance will be randomly generated, but Player’s appearance will be determined by the persisted data of Equipment and Customization.

Also, how can the solution to all of this be structured in a way that allows for easy testing and configuration? Like whatever configuration construct we use to persist data, I could just configure it to replicate any persisted player state, like a player that has collected X item, or a player with a terrible moral compass

zenith light
#

you can store everything non-player related in a subscene that don't get unloaded

#

You can think of subscene not just as level, with geometry

#

but also of asset bundles

#

because that's what they are basically

leaden cobalt
#

Interesting… so if all persisted state gets stored in a separate subscene, should that subscene be serialized and saved once the game exits?

#

And reloaded upon restarting the game?

zenith light
leaden cobalt
#

And all this talk of the relationship between baked entities and their baker authoring, would changes to the persisted state be reflected in the baker authorings?

zenith light
#

didn't we talk about this earlier?

leaden cobalt
#

Nope, must’ve been a different person

zenith light
#

maybe

#

but really similiar subject

#

basically you can have a set of subscenes (or just one of them) with data shared between levels and stuff

#

which you know for sure is always loaded

#

and you can have only level specific subscenes

leaden cobalt
zenith light
#

if you need to save something, you save it regardless from where is it

#

but when it comes to saving level specific stuff, this can get tricky

zenith light
leaden cobalt
zenith light
#

well, if all your levels store is geometry

#

and there is nothing to modify during runtime

#

(no need to save anything)

#

then it's all pretty clear

#

(except maybe for how to save)

leaden cobalt
#

Yeah, the levels itself won’t be modified, but each level will calculate player actions like enemies killed, loot acquired, and put those into persisted state, and each level will also read from persisted state to calculate the player appearance and starting situation, but the level itself and its logic doesn’t change at all

#

The levels are essentially stateless and separate in a sense from persisted state. I mean, the levels do read from persisted state to enact some changes, but the level state are untouched during gameplay

#

Thank you Issue, most of my questions are answered except for easy editing and configuration of player state for testing. Do I have to edit the entities directly in the subscene to replicate certain persisted state, or is there magic to reverse engineer what the monobehavior inspector view would look like, and I can edit with all the luxuries of Monobehavior editing support?

zenith light
leaden cobalt
#

If a baker bakes a float into a component, and I change the float in Runtime view, and I switch from Runtime to Authoring view, will the change be visible from the authoring?

#

Nevermind, I don’t think this is necessary. If I want to change the persisted player state, I can just delete the current entity (say with item X acquired) and drop in another entity (say with item A acquired) with different configuration