No samples for StateObject?

[Dekker3D]

I'm struggling to figure out how to use StateObjects to save generated chunk data, and the samples don't seem to do anything with saving/loading. Is that correct, or am I missing something? (I'm using Sythelux' Godot version, but did check the code for the samples in this repo, too)

[runevision]

Hi!

You're right, I haven't gotten around to adding an example that shows how to use the SaveState system.

Here's a summery of how to use it:

The current state of the world is stored in a class called WorldState.

In a game manager script:
Call WorldState.Load() to load state from disk.
Call WorldState.Save() to save state to disk.

The actual state to load/save consists of StateObjects containing StateWrapper objects.

Example code to use in the Create method of a chunk:

// This chunk needs a number of save-state booleans to keep track of which doors are open.
// After creating a doors array with door objects, we give them state like this:
StateWrapper<bool>[] doorStates = StateWrapper<bool>[doors.Length];
for (int i = 0; i < doors.Length; i++) {
	doorStates[i] = new StateWrapper<bool>();
}

// Create the StateObject (which loads the state) and add it to the chunk.
int hash = new RandomHash(34567).GetInt(index.x, index.y); // Make sure to use a unique RandomHash seed for this chunk type.
states.Add (new StateObject (hash, doorStates));

for (int i = 0; i < doors.Length; i++) {
	// Call init method which saves door state in door object
	// and inits the door according to the state.
	door.Init(doorStates[i]);
}

When the state of a door changes, change the Value of the door's StateWrapper state.

When the StateObject is created, it automatically fills the StateWrappers with the relevant data from the WorldState if it exists.

When a chunk is destroyed, it calls Unload on all StateObjects added to the states property of the chunk. This ensures the data from the StateWrappers is saved in the WorldState.

WorldState.Save() also saves the state of all StateObjects to the WorldState before the WorldState is saved to disk, and WorldState.Load() sets the state of all StateObjects after loading it from disk. Generally the syncing of data is taken care of automatically.

Apart from bools, the other supported data types are currently int, Point and Point3.

I hope this can get you started. You'll probably have to look at the APIs of the mentioned classes to figure out more details. Let me know if anything is still unclear.

Oh, and I'd be curious to hear about your project! Perhaps you could write a few words about it over in the Present your project category?
https://github.com/runevision/LayerProcGen/discussions/categories/present-your-project

[Dekker3D]

Ah, so it is as I feared. Seems quite fiddly/tricky to use with arbitrary objects, though it would work well for static-sized simple data like terrain heights. I'd prefer to just write my own serialization functions for objects, and have this library call those functions when a chunk has to load/unload. I guess I'd put that in the Create function of the chunk, and just load/unload based on whether destroy is true, and... hook into the WorldState's load/save callback to actually load or save my custom stuff?

I'll write up a bit about my project, though it's really only a fledgling thing I'm largely doing for fun.

[runevision]

I'd prefer to just write my own serialization functions for objects, and have this library call those functions when a chunk has to load/unload. I guess I'd put that in the Create function of the chunk, and just load/unload based on whether destroy is true, and... hook into the WorldState's load/save callback to actually load or save my custom stuff?

WorldState is quite tied to StateObject and StateWrappers. If you want to do custom serialization, you're probably better off creating a world state solution from scratch than try to use the one included with the framework.

I'm pretty sure the included one is far from ideal anyway. I'm no expert on save state implementations and on top of that, I wrote that part of the framework long ago when I was a less experienced programmer.

The good thing is that the coupling between the WorldState system and the rest of LayerProcGen is very light. It's literally just the states property of LayerChunk. Storing your own state in chunks and handling it in the Create function would do the same thing.

I'll write up a bit about my project, though it's really only a fledgling thing I'm largely doing for fun.

Thanks! It's the first I hear of any project using LayerProcGen at all (apart from my own) so learning about it is nice and motivating. :)

[Dekker3D]

I'd prefer to just write my own serialization functions for objects, and have this library call those functions when a chunk has to load/unload. I guess I'd put that in the Create function of the chunk, and just load/unload based on whether destroy is true, and... hook into the WorldState's load/save callback to actually load or save my custom stuff?

WorldState is quite tied to StateObject and StateWrappers. If you want to do custom serialization, you're probably better off creating a world state solution from scratch than try to use the one included with the framework.

I'm pretty sure the included one is far from ideal anyway. I'm no expert on save state implementations and on top of that, I wrote that part of the framework long ago when I was a less experienced programmer.

The good thing is that the coupling between the WorldState system and the rest of LayerProcGen is very light. It's literally just the states property of LayerChunk. Storing your own state in chunks and handling it in the Create function would do the same thing.

Makes sense. It might still be nice to support this with the built-in systems: have some interface, with a GUID attribute (to be a different number for each class), a version attribute (to be changed when the loading/saving code changes), and a save/load function that takes a Stream. When serializing, just write the GUID, the version, the length of the stream, and then the contents of the stream. Then, you need a way to mark objects to be serialized. Maybe with attributes? I guess this would need to be a conversation of its own. I wouldn't mind giving it a shot, myself, though I'm not sure about submitting a PR to this repo when my own work is based on Sythelux' fork. As long as it doesn't touch anything Godot/Unity specific, I guess it should merge fine?

I'll write up a bit about my project, though it's really only a fledgling thing I'm largely doing for fun.

Thanks! It's the first I hear of any project using LayerProcGen at all (apart from my own) so learning about it is nice and motivating. :)

I would've assumed that Sythelux would have some use for it, but I couldn't find anything public on his GitHub profile. But yeah, this library seems quite well made. Threaded, and not too hard to implement, so why reinvent the wheel, right?

[runevision]

It might still be nice to support this with the built-in systems: have some interface, with a GUID attribute (to be a different number for each class),

I would suggest a regular 32-bit integer rather than a GUID.

• In terms of avoiding collisions, GUIDs are likely overkill.
• GUIDs are much less performant than ints.
• GUIDs are based on a concept of incorporating the time the GUID is generated as part of the GUID. But for procedural generation scenarios, the generation code must be able to deterministically generate the same GUID every time the generation is run, so it can't depend on time. This means GUIDs (when used as intended) are incompatible with deterministic procedural generation - unless I'm misunderstanding how you intent to use them.

a version attribute (to be changed when the loading/saving code changes), and a save/load function that takes a Stream. When serializing, just write the GUID, the version, the length of the stream, and then the contents of the stream. Then, you need a way to mark objects to be serialized. Maybe with attributes? I guess this would need to be a conversation of its own. I wouldn't mind giving it a shot, myself, though I'm not sure about submitting a PR to this repo when my own work is based on Sythelux' fork. As long as it doesn't touch anything Godot/Unity specific, I guess it should merge fine?

I'm quite open to considering integrating other save state systems into LayerProcGen in the long term, but it would have to be something that's fairly well proven, for example used in a shipped game. The current save state system is used in my own game The Cluster which I'll ship shortly, so while it may not be ideal in various ways, at least it's proven for real-world use cases of a full game.

What I'd suggest is that you implement intermediary layer and chunk classes and implement whatever layer/chunk support for your save system you need there. You can see templates on this page (a bit down) for how to create intermediary classes and have it work correctly with the type constraints:
https://runevision.github.io/LayerProcGen/md_ScriptTemplates.html

This way you can work on your save system over time, refining it and ensuring its versatility and robustness as you develop and test it along with your game, without any urgency to merge it into the upstream LayerProcGen framework.

Let me know if this sounds sensible to you.

[Dekker3D]

Ah, yeah, that does seem sensible. Regarding the GUIDs, I mostly meant for each class to have one, so that the right data ends up in the right classes. I did realize it wouldn't help if a chunk has more than one variable of the same class though. Anyway, I just figured it might be good if LayerProcGen had a more intuitive saving/loading system out of the box, but for now I'll mess around with ideas on my own,