Hello forum!

I'm running an ECS but still have problems with planning loading/saving.

Let's look at a specific case, a dragon-entity for example:

graphics_component = 
{
texture_path = "..."
}

other_component = 
{
...
}

So, this is an enemy, it will be used more than once, it is literally a class-concept that shall be instantiated during run-time. Therefore, it does not require a transform-component describing its location within the playable world just yet.

But what happens with the dragon-entity once it gets instantiated? Well, at some point, a transform-component will be added, that looks somewhat like this:

transform_component = 
{
x = 100
y = 20
width = 64
height = 64
}

But wait, where do we get the width and height from? So let's just add a minimal version of the transform-component to our dragon-entity.

graphics_component = 
{
texture_path = "..."
}

other_component = 
{
...
}
transform_component =
{
width = 64
height = 64
}

Now, when we save our game, what are my possible strategies? Keeping track of all entity-files within a table and assigning instantiated entities to their fitting ID?

index = 
{
[0] = "file/path/dragon.entity"
[1] = "file/path/rabbit.entity"
}

So a dragon-entity would obtain an id of 0.

And now, only writing the x- and y-coordinates into the save-file? Is this common? Assuming that the original level-file still contains a version of the transform-component that lacks information (x, y)?

My prior idea was to separate constant components (e.g. graphics) from variable components (e.g. transform). Keeping constant ones inside the blue-print and variable ones inside the save-file. This seems to be not doable without adding more components which would result in more complex code.

Is this it? Or are there better strategies?

Thanks for taking your time : )

Wow, that gives me a different point of perspective onto the whole thing. Sameish idea of using a somewhat unique identifier but different usage.

But one issue is still there, what if a component shares dynamic and static/constant values? As said with the transform-component, owning its static bounding box/size but also dynamic coordinates of position.

Should I simply implement them in such a way, that the component-serialiser only saves dynamic values and the deserialiser loads the bounding-box from the template and the coordinates from the save-file?

But one issue is still there, what if a component shares dynamic and static/constant values? As said with the transform-component, owning its static bounding box/size but also dynamic coordinates of position. Should I simply implement them in such a way, that the component-serialiser only saves dynamic values and the deserialiser loads the bounding-box from the template and the coordinates from the save-file?

I wouldn't even make the differentiation between "dynamic" and "static" values. Why force yourself to think about whats dynamic and whats static, and why limit you in such an obvious way (hint: in my 2d-game, on multiple occassions hitboxes can dynamically resize in a matter that needs to be saved ie. in a savefile; also position need not be saved for a static entity, etc... ).

I'd instead perform a simple delta-compression: You compare the runtime-entity to its definition, and store each field that is different - you can do that for savegames, also if you use some sort of template/prefab, you can do the same thing.

I would save the type/template data every time, regardless of what's changed. The last thing you want to do is break backwards compatibility with your save files between versions, but that's a very real risk if you make assumptions about type data that might not be the same when a save game is loaded again. However if all that data is readily available, it's relatively easy to load older save files and have the data remain valid and self-consistent.