I had planned to put up more of a tutorial post on rendering adaptive 2D grids for things like editors and such, since it was something I recently implemented. I got it working in my editor but then when I tried to conjure up a more “simplified” version in Blitzmax without any of the abstractions of a scenegraph, camera, and other numerous things I found I was tripping up over Blitzmax’s own graphics commands O_o. Being impatient I took the route of “at least it works in my system” and I’m just going to point you to a code listing that helped me generally implement it. Moving along now…
Since working on my weekend “Gunstyle 2” project I’ve had to develop a map editor that allows a mapper to save map files and load them into the game. In the first iteration of the game we had written the map files as binary files with all the assets needed in a single map file. On the 2nd iteration for the XNA Dream.Build.Play competition we used TorqueX as our engine of choice and it used XML files to serialize assets. After developing in both and developing the “next” version of Gunstyle in Blitzmax, I’ve had to tackle the decision of which type of serializing the framework and game would use.
I opted for XML in the end. The reasons were:
- Portability – Something we wanted to do with the newest version of the game was pull over some of our levels from the original and the XNA/TorqueX version so we could quickly test gameplay on fully-developed maps. Massaging a binary file to be compatible with another binary format is a headache to say the least. The maps in the original Gunstyle were binary, so I took the route of exporting the maps to an XML format. the Binary-> XML conversion wasn’t easy either, but once in XML updating the schema as the framework evolved was A LOT less painful. Extracting the geometry of levels from our XNA version (which was actually a custom XML file outside of TorqueX) proved to be trivial also.
- Readability – This is a difficult one to prove that is useful. If a binary file is valid, why do you need to read it? During development of the file format, being able to read the file output helps with debugging.
- Flexibility – With XML, you can treat the map file almost like a database. Using XPath or some other way of querying the data, you aren’t restricted to the exact order things are in the file.
- Ease of editing – With XML I can now leverage text editors to do simple edits in a map file rather than writing some custom tool to do what amounts to a basic ‘search/replace’ for a map if, for example, an asset name is changed.
While using XML did give me some benefits, there were some trade offs I had to deal with:
- Non-Encapsulation – Now a map file no longer was a single monolithic file. Which to me seems ‘cleaner’ and is much easier to distribute. Maps consisted of an XML file that essentially described the geometry, scenegraph layout, and where to find the textures and audio.**
- More Verbose Code – Writing a binary file in Blitzmax is less lines of code than writing an XML file (I’m using a binding to libxml by the way).
On the topic of encapsulation, I really liked having maps be a single file you can send to someone and be able to play. This also greatly simplified the auto-download feature of our previous game where we simply looked for the missing map file. I suspect to get this type of simplicity for users I would have to implement a virtual file system for the game and have assets and XML files be wrapped up in zip files or something. I’m fine with dealing with more verbose code as the benefits outweigh the downsides in my opinion.
There’s definitely more down-sides to using XML over binary than I listed above, but I can’t think of any at the moment. I attribute this to my hunger. I am now going to proceed to feed my face, play some games, and start doing some networking work :). Just as a note, I will be traveling for the next week-ish, so don’t be surprised if I don’t get a new (hopefully more insightful/useful post than this one) post up next weekend. Happy Labor Day Holiday!