Object persistence
Please note the following warning about Risen 2, 3 and ELEX 1 and 2
The following information only applies to Gothic 3 (2006) and Risen (2009). While newer Genome engine games share the same overall concepts, they have significant implementation differences that warrant their own section.
The engine is, due to the nature of the games themselves, required to store and load a vast amount of different types of data from the user's hard-drive. In order to streamline this parsing and/or serialization process, Genome implements an object persistence system using its own built-in runtime type information (RTTI) system.
Any class derived from bCObjectBase
may declare its own member properties in such a way that when the object is then written into a file using the bCAccessorPropertyObject
class, its associated properties will be automatically serialized into the stream by using special preprocessor macros. When the object is read back from the file, the class will be automatically initialized using the stored members.
Additionally, classes may overload the Read
and Write
(OnRead
and OnWrite
in Risen 1) virtual methods that allow the class to save additional data required during parsing such as paths to other necessary files.
As this system is quite flexible, it is used to store most of the game's data, from meshes, animations and textures to level and quest data. This is quite different from ZenGin, as its object persistence system is only used for worlds, saves, output units and parts of compiled meshes.
File format
Files
bCAccessorPropertyObject
eCProcessibleElement
Implementation
A practical example
Let's propose that we have a class which is declared like so:
The hypothetical class then implements these virtual functions:
We then initialize the class in the following way:
If we now serialized, or to use the engine's term "archived", this instance into an ASCII stream, the result would look like this: