Cogito World State - resource for consistency between levels

[Phazorknight]

Hey everyone,

I've encountered this in a different game recently and was wondering if this should be a built-in Cogito feature, something that I'm simply calling World State

Let's say you have two level scenes: Headquarters_Interior and Headquarters_Exterior. And then lets say in the Exterior level scene, there's lit up sign. In the Interior level scene, there's a switch in the basement that cuts off power to the building. Now when you go back to the Exterior level scene, the sign should be dark, because the building power is off.

My idea for this would be creating a CogitoWorldState class that's a custom resource that gets managed per save slot (similar to CogitoPlayerState), except in this case, we don't know exactly what data the user needs to save.

I haven't tried this at all, but in my head I'd approach it like this:

1. Create a tab in the Cogito Editor tab called World State Data

2. Create a simple interface that lets the user create a new WorldStateData resource (.tres)

3. Let the user add which kind of data/variables the WorldStateData resource can contain (keeping it maybe Strings, bools and ints )

4. Now in game runtime, if there's a WorldStateData present, it's contents gets saved/loaded as a state resource file as part of each save slot. My hope is that we can just write all variables present in the WorldStateData into a dictionary and then save/load that.

Thoughts, ideas, critiques?

PS: This would be for after the 1.0 release.

[OvercastInteractive]

This makes a ton of sense, and your approach seems logical. I have been simply adding my save and load dictionaries and functions within the cogito save state and scene manager scripts for my own variables, which makes it problematic when updating through version control. FYI, I had been saving nested dictionaries, which wouldn't be possible based on your limitation to Strings, bools and ints, in which case I would just stick with my original implementation. I think those three types are good though.

[Phazorknight]

I'm happy to expand on what kind of data we could save/expose, but wanted to start with these three as they're easy to expose in an editor/inspector and usually very easy to save/serialize.
With the issues with the editor tab, I'm now leaning more towards just introducing a third resource that gets added to the player save slot.

I'm curious about your implementation:
Do you have your data only in code or are you exporting it in the inspector for easier access?
If we implement a WorldStateResource, it should be possible to simply move your implementation over from the current state files to a WorldStateData file.

[OvercastInteractive]

In projects outside of Cogito I had been saving data in Resource files, but when first starting out with Cogito I found it easier to lump my save data next to like-for-like functions and properties in Cogito's save management scripts. So, I was saving data primarily from dictionaries unexposed in the editor/inspector, many of which stored integers that would point to indexes in arrays of resource files.

[Phazorknight]

So folling up on this: Since the Cogito Editor tab brought more issues, this plan will have to change a bit as well.

I'm thinking that only using a custom resource by itself would be easier to implement for now.

Instead I'd structure it like this:

WorldStateResource with a few exported fields that the user can manage to create a WorldStateData file.
CogitoSettings could then save a reference to the WorldStateData so code can easily reference it, but it can also be swapped/updated.
And point 4 of my original post would still apply in terms of handling WorldStateData as part of each player save slot.

[OvercastInteractive]

I like this approach and was something I'd thought about when dealing with custom save data in my last Cogito project. It sounds like a simple, consistent, easy to use and manage approach that covers most use-cases.

[Phazorknight]

So for some reason I had issues getting this to work. But also realizing that only saving a single dictionary, creating it's own file for it might be overkill.

So I've opted to use a similar approach as you and added it to the CogitoPlayerState file.

I've pushed this in commit 215cee5

It is "cached" by the CogitoSceneManager so any object can reference it as needed.
In the demo scenes, the Laboratory ceiling fans check for a "lab_power" value, which is controlled by a new switch in the Lobby.
If you run into any issues with this, please make sure to start a new game, as the world dictionary is set when starting a new game.

I've written up a section in the manual describing how it works here: https://cogito.readthedocs.io/en/latest/manual.html#world-state-world-dictionary-wip

But tl;dr: Any key value pair can be added to it at runtime (in addition to setting a few when starting a new game).
This should make it very easy to use without having to code (a lot).

Currently, it seems like it's not being saved/loaded from the state file properly, so it still requires some work.