Hey, I have a question about how designing a game editor would for an engine would work. Let's say I am making an engine for some sort of RPG game. My instinct would tell me to build an editor tool which allows to to create a file which would record the data for a given spot like a room in a dungeon. The file could simply be a list of all the entities in the room and I could load the file when the game is running. However, what worries me is if I make a change to the data which an entity has (like an extra int to the entity struct), all the level files I made in the editor suddenly become useless and I would need to remake them from scratch.
I could only think of a couple potential solutions. The first is to simply not add any changes to entities once I began creating room files. This means I would need to be 100% sure my entities have all the potential data they need and I have tested them extensively before beginning to build the bulk of the game. This seems like the safest option, but the idea of not being able to add a new feature later bothers me a little.
A second solution would be a some sort of tool or function which could map older entity structures into newly changed entity structures. This sounds a little complicated and I haven't thought too much about how I would implement such a thing.
Another would be to try to format the room file in away to lessen the impact adding changes to entities might make. This might look like a room file having the number of entities in a room at startup and then a line that applies each specific attribute to each entity. That would mean that only the attributes that have been changed would break. This seems like a decent solution but might take a little more work...
Am I missing an easy solution? Are there any good resources on this topic? I have been thinking about this for awhile now and wanted to know what others think about this topic.
Thanks!
Edited by Max
on
You can have a look at this blog post: https://yave.handmade.network/blog/p/2723-how_media_molecule_does_serialization
You can create an abstract function for getting a reference to a variable by name (read and write access), and a function for listing all members (for saving to file or generating the GUI for editing). Then make a system that automatically saves and loads it using custom types with serialization to and from strings. The persistent types can also be tied to the construction of GUI components for selecting values in the editor, so that a color picker pops up when selecting a color.
When saving, you can either check which values are default values to only change what's different (more compact and backwards compatible), or you can just save everything (more well defined if no default value makes sense)
If the saved attribute does not exist in the program when loading, you can either give a warning about needing to upgrade the software, or ignore and continue anyway. If an attribute is missing, the default constructor will already have a default value to rely on, which should represent the same behavior as when the feature did not exist in the older version.
https://github.com/Dawoodoz/DFPSR/tree/master/Source/DFPSR/persistent
https://github.com/Dawoodoz/DFPSR/blob/master/Source/test/tests/PersistentTest.cpp
The class factory for default constructing from the type's name is the messy part, because you have to register everything from the main function. C++ cannot find types by name at runtime, because that would be easy to reverse engineer with identifiers exposed in a binary that can not be obfuscated. Registering types automatically for serialization would be undefined behavior. C++ don't like libraries executing global side-effects on initialization, because that would prevent optimizing away unused functionality when linking. If you can have one collection per type and no child members of arbitrary types, you might not need a class factory, but might run into limitations later on.
Edited by Dawoodoz
on