Since my other big feature at the moment has entered the implementation phase, I think it’s a good idea to start discussion on this one so I can run them in parallel.


Fossilisation has been a planned concept since before I joined the team. In short, it’s a way to save the organisms you discover during gameplay.

There are many things you could then do with them:

  • Browse them in a museum section of the Thriveopedia*.
  • Load them in the freebuild editor.
  • Share them with other players.
  • Create custom games populated by selected fossilised species.

* The Thriveopedia is a whole other kettle of fish, so I’ll make a separate thread about that in a moment.

Current Design Proposal

I think it makes sense to limit fossilised species to cells only for the moment, given how much multicellular creatures could change in the future. As such, everything below applies to only cells and the Microbe Stage.

When the player pauses the game, a button appears next to every cell on screen. Clicking this button opens a dialog showing organism statistics, an option to enter a species name (auto-filled with the actual in-game name) and a button to fossilise the organism.

I’ve actually already implemented this part, so here’s a screenshot. The icon is temporary, although I definitely think an ammonite fossil is the preferred choice for this icon.

If the species name matches an existing fossilised species, the player will be prompted to either overwrite or choose a different name.

A fossilised species file is then saved in the user’s data directory, much like saved games.

The player can access fossilised species in the ‘Museum’ tab of the Thriveopedia. Here, species are listed in clickable boxes modelled on art gallery items, with a panel to the right showing detailed information on the selected species. Here’s a very rough mock-up.

There is also a button under the selected cell details with the option to open this species in the freebuild editor (selecting this while accessing the Thriveopedia in-game warns the player they will lose unsaved progress in their current game). There’s also a button somewhere in the museum to open the fossilisation folder, so players can send saved organisms to one another.

Further, there’s a new button in the freebuild editor which opens a list of fossilised cells and allows the player to load one directly.

Future Design

I’m consciously ignoring the last two of my suggested uses for fossilised cells, at least for now. These seem like much bigger undertakings and aren’t necessary for the essence of fossilisation to work, but could be added in the future.

Eventually, this feature might take on the role of Spore’s Sporepedia, with a central server of uploaded fossilised creatures from all players. But I think you’ll agree that, if this even happens, we’ll have to wait for it for quite some time.

There are likely a few other options as well, but unless they’re simple to implement, I’ll leave them out too for now.

Implementation Status

As I said, I have the fossilisation buttons and dialog up and running on my branch, although clicking fossilise does nothing but close the dialog.

I don’t think the museum will be too difficult to make, given I can reuse many elements pioneered by the art gallery and auto-evo exploring tool.

The real challenge - and the part I’ll probably need help with - is actually saving and loading species, along with all the save name verification. I could maybe work it all out by reading the saved games code, but if anyone has some thoughts on how they might go about it, I’d appreciate them.

I think that’s everything, so I’ll open the floor to questions and suggestions.


Looks really good! No feedback from me at the moment.

I agree that the Ammonite is a very intuitive icon for fossilization. I can’t find it right now but last time someone drafted an Ammonite icon that looked like this:



The species class already supports serialization to JSON and loading from JSON. So the basic implementation can be as simple as using the json serializer to make it into a string, write that to a file using Godot. Then for loading the process is just the reverse of reading the file as a string and using the deserializer.

Though for future proofing I think a slightly fancier thing to do would be to create a holding class that has properties for all possible species class types, and that would be serialized, gzipped and then saved to a file. Additionally if we want to do stuff like store screenshots along with the species data, which we might want to skip to keep the shareable species files small, the data could be in a tar container like the saves.

I can offer to write that saving and loading part as long as all the other parts are done, and we have decided if we want to store just JSON info or also potentially a screenshot for the saved species.

1 Like

Also updating this thread to mention that fossilisation (which kind of became an afterthought in the eventual massive Thriveopedia implementation) is all but done. Here it is in action.