Game Development Reference
In-Depth Information
12.4 Enter Stage: XML Serialization
12.4.1 An Anecdote
I stumbled across XML serialization in an odd way. As a consultant for a game
project, initially I was looking into a performance issue when instantiating existing
object hierarchies for a GUI system built on top of Unity. A prototype for a GUI
layout was kept around from which new layout instances were launched (e.g., a
layout for a specific inventory item). Much of the data were objects in arrays, so I
had to perform a deep copy of the actual data. This was expensive for a variety of
reasons, one of which was resizing of new arrays. So, I looked at alternative ways
of instantiation with serialization methods. I tried both custom binary serializers
and decided to also try XML serialization for comparison. In the end, I decided
to go with duplication methods that used custom constructors for initializing array
sizes and .NET array methods for the actual copy. Even though I discovered XML
serialization for the first time while investigating this problem, it still did not occur
to me that I should use this for parsing other XML data, much less as a storage
format.
The GUI authoring tool that produced the data for the game was a legacy
tool that ran under Windows, which natively stored its data in XML. Looking at
the source for the authoring tool, the XML for each layout was being written out
and parsed in a manual way using a DOM-based approach. Most of the other
developers on the team had moved over to using Macs for iPhone development, so
either they ran this authoring tool in a virtual machine or kept a separate Windows
PC around which they used to export the layouts. Additionally, an exported version
of a layout, also in XML, was parsed in Unity to produce GUI objects that were
needed for rendering. Unfortunately, this process created an awkward workflow
for GUI layouts and caused delay in getting layouts into Unity, which required an
export each time from the authoring tool.
The first improvement I made was to allow the XML to be saved directly to the
Unity project folder and have that picked up automatically instead of requiring a
manual import from within Unity. Unfortunately, this still required an export from
the authoring tool. However, the savings of having Unity automatically import this
XML with an
AssetPostprocessor
instead of requiring the developer to import
each time in Unity were significant. This change smoothed the workflow out a bit;
however, I knew that the whole process could be done better.
Code already existed in Unity for parsing an exported version of XML from the
layout-authoring tool. However, the source XML document that the authoring tool
used could not be read in directly. I adapted this code, which was DOM-based,
to parse the source XML document directly instead of the export. Unfortunately,
even at this point, I didn't think to switch over to XML serialization for parsing
the source format. From this source layout data, I began constructing a layout-
authoring tool directly in Unity. My goal became to provide an in-Unity layout
