Mismatch of Entity System and Savegames

Question

There is a theoretical mismatch of 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.

(Originally, I described my entity system in more detail. But it wasn't directly related to this question and and wanted to shorten the question. It can still be viewed in the revision history.)

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 of 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?

Answer 1

A window handler should not be an entity property. As you said it will be retrieved every startup. So no need to store it as property. Store the handler in a subsystem responsible for dealing with windows.

Your meshes: the entity properties should contain everything to recreate the meshes, but not the meshes themselves. Read the necessary data from the properties to create the meshes, but hold the mesh ids in a render manager or something similiar.

Think about it that way: your entities and their properties represent state of the game world. They describe the state of the game world and your subsystems (rendering, physics, audio, ai etc.) read these properties and create any necessary internal objects (sprites, meshes, loading sounds etc.).

Answer 2

Two pieces.

First, it's handy to have an idea of "archetypes." This is some data that defines a type of game object and which components it has and what their data is. For instance, you might have data file like:

Player:
  Sprite:
    image: character/players.png
  Physics:
    size: [2,2]
    center: [1,1]
  PlayerController
  AudioListener
  Health:
    max: 100
    current: 100
Enemy1:
  Sprite:
    image: character/enemy1.png
  Physics:
    size: [4,2]
    center: [2,1]
  AudioSource
  Brain:
    script: ai/enemy1.lua
  Health:
    max: 50
    current: 50
Enemy2:
  Sprite:
    image: character/enemy2.png
  Physics:
    size: [1,1]
    center: [0.5,0.5]
  AudioSource
  Brain:
    script: ai/enemy2.lua
  Health:
    max: 400
    current: 400

Assuming you track for each game object which archetype it was spawned from, you can save levels and save games as a unique ID and a list of data changes from the baseline. Exactly how you do that will vary a lot based on how you represent archetypes and inheritance of game object definitions.

It can seem like this is a class-based architecture, which it is to a degree, but maintains the flexibility of components and their data-driven potential. You can allow a form of "multiple inheritance" for archetypes if you want mixins and the like. Again, there's a bazillion ways to do this. You'll need to design a method that best fits your needs.

With this technique, you'll be default only be saving components that have changed in some way. Say your level has an instance of Enemy1 that has taken some damage. All you'd need to save is something like

object #7586 [Enemy1]:
  Health:
    current: 17

All the other components and fields are implicitly loaded as part of the Enemy1 definition. No need to save or load that data. Furthermore, since you aren't saving the whole object, the save can react to data definition changes. If you don't want that, just version you data (which you need to do in some capacity for saves anyway).

The second part then, which is fairly simple, is to just mark components or fields with extra metadata about whether they persist across save/load. If you mark the Health.max field as being non-persistant, then even if some effect modifies it for a particular enemy, the save file won't contain it. If the effects are saved/loaded and reapplied after load this is probably want you want.

You really want this kind of metadata markup anyway for networking, editors, and so on. You want to be able to mark up a field as being read-only so auto-generated editor GUIs don't let designers modify the field. You want to set which fields will be replicated over the network, and how (highly volatile data or semi-reliable data). Doing this in C++ is a complete pain in the rear, but it's trivial or even already partially built-in in many other languages.

Answer 3

You can split the ID integer space in Temporal IDs and Permanent IDs and treat it different. E.g: using a 16bits unsigned integer:

• [0 - 32767] Permanent IDs
• [32768 - 65535] Temporal IDs

This way a saved entity never will get a temporal ID and there will be no collision.

You can adjust the ranges knowing the amounts of entities of each type.