Saving and Loading State

[xkortex]

I'm sure it's already on your mind, but I think it's worth starting a thread, especially for getting into the weeds with the implementation: saving and loading state. There's a few main pieces of state I've identified:

• the window parameters
• hyperparameters (basically everything in the control panel)
• the fossil record (history and graphs)
• the genes of each organism
• the menagerie (the set of all species)
• the world state (location and contents of each tile)

That list is in rough order of the difficulty of implementing saving/loading. I dug a bit into the code and it's very OOP-style code, which makes serialization/deserialization a bit tricky. It looks like to reproduce, you make a new "blank" organism and then literally mutate state (pun intended =D).

Imagine each Gene is a data structure, separate from the Organism. It is immutable from the perspective of the Organism. The Organism's state comprises its immutable state (genome, traits, cell layout) and its mutable state (health, location, actual cells). You don't ever actually mutate the Gene directly, what you do is make a copy of the gene, splice what you need to, and return a new one.

Edit: I realized you can just JSON.stringify arbitrary objects so for starters we can probably just go that route to shuttle data in and out.

[xkortex]

Yeah, so part of the problem is if I try to naively dump an organism to json: var txt = JSON.stringify(self.engine.organism_editor.getCopyOfOrg());, I get Uncaught TypeError: cyclic object value. So that right there tells me the data model is a bit entangled. I think it would be beneficial to separate the immutable organism definition from the organism state, that way serialization is easy and painless.

...

Ok, I was able to dump an organism to JSON, but I had to delete a bunch of fields in order to remove the cycles.

What I would highly recommend is going to a pure-data-structure-based model. I would add a Gene class, which is an object containing everything needed to construct a new Species. This Gene would be (effectively) immutable; it would have something like a .mutated(mutation_args) method which returns a mutated copy of it (preserving the original). Then each Species would be created from a gene.

This arrangement has the nice property that the ID can actually the hash of the gene (e.g. md5sum of gene.toJSON() ), so if you import from another run, you don't run into any unintended collisions of ancestors. Lots of other cool things you can do there. This would also help disentangle the brain genes from the brain state, which is currently an Organism level attribute but I don't see it referenced from Species.

Those cycles are might make it challenging to de/serialize the game board, so that will take some thought, but it shouldn't be too hard to get started with a copy/paste organism from clipboard.

...

If that sounds interesting to you, I can take a stab at the refactor (shouldn't be too involved) and send a PR your way.

[xkortex]

That might be a bit abstract still so I took some time to put together a rough sketch of what I'm thinking.

https://github.com/xkortex/LifeEngine/blob/2d10144a4722d44a0985552206f8e098c33d5f07/src/Organism/Genome/Gene.js

Basically at the "nucleus" of each organism is its genome, a data-only object which is easy to dump to json. Something like:

{
    "genes": [
    {
        "chromosome": "body",
        "priority": 0,
        "state": {"name": "mouth"},
        "col": 0,
        "row": 0
    }, {
        "chromosome": "body",
        "priority": 0,
        "state": {"name": "producer"},
        "col": 1,
        "row": 1
    }, {
        "chromosome": "body",
        "priority": 0,
        "state": {"name": "producer"},
        "col": -1,
        "row": -1
    }, {"chromosome": "gamete", "priority": 0, "mutability": 5}], "name"
:
    "_maged3k4b"
}

Then organisms are built from genes. Since genome is now a static data structure (read: hashable), keeping track of organisms becomes much easier - instead of having to maintain state, you just have a hashmap. Makes things a lot easier to reason about.

OH, and unit testing. Makes unit testing way easier!

[MaxRobinsonTheGreat]

Hey @xkortex. Sorry its taken so long to respond to this. I've been thinking about it a lot and you are absolutely correct. I would like to implement saving/loading organisms, and this would be a huge pain to do with the current structure. Your system of having an inner immutable and easily serializable "gene" object would not only make this much easier, but radically improve reproduction, in which a parent simply passes a deep copy of its gene object down to its offspring, which constructs itself from this alone. This would be a significant refactor, but a deep improvement. Anyway just wanted to say your thoughts have been very helpful, and when I get around to implementing this I may use your code mockup.