Game Development Reference
In-Depth Information
With this functionality, a simple string-based file format can be created. For
our implementation, we used XML:
<object name= object0 type= ExampleObject>
<field name= field0 value= 1 0 />
<field name= field1 value= someString />
<field name= pointer value= object1 />
</object>
<object name= object1 type= AnotherObject>
</object>
...
Names of objects are only required during serialization to resolve pointers. Dur-
ing load these names can either be saved (for debugging or saving purposes) or
thrown away after load.
This simple file format is extremely lenient about format changes. Fields can
be reordered, removed, or added, and the file will stay backwards compatible. It is
easy to debug, can be edited with rudimentary tools, allowing it to be modified and
updated without a complex tool chain. It is mergeable with a text merge utility,
making it significantly easier for multiple users to edit it simultaneously.
Unfortunately, this format suffers from the same issue as other off-the-shelf
solutions: it is not built for speed. The above example may only require a handful
of bytes to represent in memory, but the on-disk size may be tens or hundreds of
times larger. Fortunately, this format is only used during development time during
load, so these trade-offs do not cause lasting issues to the shipping product.
The file API above is completely agnostic to the method of storing the data.
By relying on a simple file format, the underlying representation of the data can
change.
7.4 Disk Image
The opposite extreme of an XML file is a direct memory image of what will be
used in game. By serializing an image of the object layout, data can be read with
minimal memory and performance overhead. These files are extremely fragile and
need to be matched with an exact build of the game, but they are optimal.
Memory images can also be completely created from the game code and the
XML files. As with our iterative file format, all tools and other external customers
can rely on the robust, easy-to-parse files, while the final engine can rely on the
fast, carefully crafted files (see Listing 7.1).
The three major issues with serializing a memory image are pointers, virtual
tables and platform specific issues.
