2 of 5 added 5 characters in body

Mismatch between Entity System and Savegames

There is a theoretical mismatch between the entity system and the savegame system, which is think is common, but I haven't found resources about that. Therefore I will explain both systems first, as short as possible. I would really appreciate any thoughts and solutions for this conceptual problem.

Entity system

I have an entity system for my game. That means there is a function to create a new entity that simply returns a unique integer id. And there are functions to add, get and remove properties, thus any C++ objects, to a given id.

An entity id is just a contiguous integer, which is stored as a member. When a new entity is created, this number is incremented by one and returned as the new id. When entities get deleted, only all of their properties are removed and freed but their id actually remains and is not given to a new entity again.

Now you know the basics of my entity system. As an example, an entity might have properties for physics simulation, character animation, health and skill points, camera to render from its view, and so on.

Background about entity system (optional)

Internally, this is represented by a map with the type of property as key and another map as value that maps the actual object pointer to their entity id.

std::unordered_map<std::type_index, std::unordered_map<int, std::shared_ptr<void>>> list;

void Add(unsigned int Id, T *Instance)
    auto key = std::type_index(typeid(T));
    // some checks I won't mention in detail here...
    list[key].insert(std::make_pair(Id, std::shared_ptr<void>(Instance)));

Also there is a way to fetch all properties of one type, so that i.e. the physics code can loop over all rigid bodies regardless of what other properties they are bound with.

To expand the example above, even the application window is an entity property. It renders the scene from the camera property attached to the same id. So there can be multiply windows and they could be even attached to a player to exit when he dies. This particular example might not be that useful, but I just wanted to show that there are no restrictions in this entity system.

Savegame system

Previously, there was no savegame system and I created all entities as new ones on startup. But now I want to save the state when closing the application and load that on startup so that the player can continue where he left off.

I use SQLlite for storing, where each type of entity property gets its own table. I haven't decided yet if each row should store the entity id as primary key. Because this is part of my current problem.

Mismatch between both

Unfortunately, I cannot just store simply all of the entities to database, because some entities are only temporarily valid. For example the window property that holds a window handler from the operating system, which must be requested every startup. Or the meshes which aren't kept in memory, but just hold the VBO ids to the vertices on the GPU.

So I have to store some, but not all entities. I could store their entity id in the SQLite table and allow the entity system to add entities by a given new id. But I cannot guarantee that this id isn't already used by entities that where newly created at startup. Do you see the mismatch?

Can can I store the entity id to table, and still ensure that when being loaded, no other entity shares this id? Or how to restructure and rethink my entity system and savegame system to overcome this issue, in general?