Way back at the dawn of Orb I decided that I wanted all my data to be stored in XML. Every object in Orb should be easily written to XML and then later, easily recreated from that same XML. The promise of XML was too seductive to ignore; fantastically flexible, perfectly portable, and only 80 calories per serving! Sure, my files would probably be a little large and slower to read, but who cares? Modern hardware is the panacea to all inefficiency!

Would XML prove to be the best decision of my life or one that I would spend the rest of my days crying into my beer about? Read on to find out!

---

Decision #1: What XML implementation should I use?
Requirements: It’s gotta be C++ and it’s gotta be fast. Don’t forget about portability!

Choices, choices! Lots of people have made XML implementations. But which one to use? Microsoft XML? Apache XML? Roll my own? SAX? DOM? SAX2? I knew Microsoft was out if I wanted any hope of Orb being cross-platform. I really didn’t want to be side-tracked for months as I wrote my own implementation. The only other serious choice was Apache’s implementation, Xalan and Xerces. I had quite a bit of experience with those libraries already, though the thought made me cringe. As I remembered, they were very difficult to understand, even harder to pronounce, worse yet to use, had out-dated documentation and community tools, and stagnant development. I still couldn’t tell you the difference between a Xalan and a Xerces. But, to their credit, they were blazin’ fast, open source, and written in C++.

So my course was clear, I would integrate Xalan and Xerces into Orb. But how?

---

Decision #2: What’s the best way to embed an XML parser into a game engine?
Requirements: Be fast and unobtrusive.

I quickly saw some very nice parallels between my engine’s object tree and structure of an XML document. My object tree was node-based, with the World at the top, followed by Layers, WorldSpaces, and then all the renderable game objects. Each node contained the nodes below it in a parent-child relationship, just like XML. Perfect! DOM looked like the obvious choice, each game object just needed to store a pointer to a node within an XML document.

Simple object properties like Name and Visibility could be easily represented by XML attributes. More complex attributes like Position (X, Y) and Color (R, G, B, A) could be represented by child nodes, for example

<position X="5.0" Y="-2.5">

None of this was very difficult beyond fighting with Xalan and Xerces. The final implementation looked something like this:

• Each World contained a DOMDocument object
• Each object contained a DOMElement object, with room for its children and attributes
• When an object was added to the World, its DOMElement would be inserted into the DOMDocument
• All objects were given a serialize() method that would write out its DOMElement to a string or file

The only hit to performance comes from the fact that every object’s DOMElement is instantiated in the object’s constructor. During heavily-scripted events, such as particle effects, many many objects are instantiated very quickly. I was concerned that the overhead of creating a DOMElement for each object might impact performance but thankfully, Xerces is efficient enough that this was not an issue.

---

Decision #3: How should I keep object attributes in synch with the DOM without impacting performance?
Requirements: Be fast.

Now came the semi-tricky part in this implementation, synching object attributes with DOM attributes. Object attributes are updated frequently, sometimes once per frame, and keeping the DOM in precise synch with them would be rather expensive. However, an object’s DOM attributes are not needed until that object is serialized (or queried with XPATH, more on that later), so there’s no need to set any DOM attributes (except for ID, which never changes) until they’re needed. Serialization happens rather infrequently and generally not during any time-critical moments. Thus, my implementation looked like this:

• Give each object a refreshDOM() method which updates each attribute in its DOMElement and calls refreshDOM() on each of its children
• Call refreshDOM() from serialize() to synch all attributes before serializing

---

And that was that! I now had a secondary version of my World data structure stored in a DOMDocument with very little impact to performance. Object attributes can still be updated quickly since the DOM is only synched when needed. So far, XML is looking like a good decision, though Apache’s XML implementation certainly has some ups and downs.

Apache XML Pros

• Tons of functionality
• Open source
• Smokin’ fast
• Unrestrictive license

Apache XML Cons

• Development status is unknown
• Confusing differences between Xerces and Xalan
• Very difficult to do simple operations
• Explodes all the time for unknown reasons
• Supported through archaic mailing lists
• Newest Xerces and Xalan versions are incompatible
• Website is impossible to navigate
• Huge DLLs to distribute

Use Apache XML as your own risk! I think its advantages eventually outweigh the headaches, but in my experience, the headaches were incredible. At any rate, XML and Orb are beginning to get along nicely. Parts 2 and 3 of the ORB XML saga will go into more detail on how I used my newfound XML serialization ability to great effect!