Some time ago, I decided to write a small C# “wizard” tool for enemy encounters and other level design patterns. The idea was to create pattern types, that designers could define with a small amount of data (different for each type of pattern) that could be exported into a much more complex xml format that could describe when to spawn what enemies, what behaviors and properties to give them, etc. in order to make each instance of a pattern unique.
The properties set by the designers were stored internally as an XML document, since XML in C# is incredibly easy to manipulate, and since the data would be different for each level design pattern. It was easy enough to save out the raw XML data as it was stored internally, but the problem was how to transform this data into the format that would be read into the game. Enter XSLT.
C# has the functionality to transform data internally with an external XSLT file. It’s easy enough to associate a XSLT file with a specific pattern, apply it at run time, and then simply write out the result. At this point, it’s simply a matter of providing the designers with the data files necessary to generate their data.
The advantages here are great. Putting the complex structure and syntax in an external file, and separating it from the designer’s view, allows them to concentrate on what’s actually important. The downside is that someone has to craft these XSLT files, which is a format that is a bit obtuse for someone used to functional languages. Additionaly, XSLT has little to no debugging capability.
Now, more recently, I’ve had the challenge of writing an exporter from OpenOffice Calc, which also uses XSLT as filters for importing and exporting. All OpenOffice documents are are stored as XML. In fact, if you simply rename an .ODS file to a .ZIP file, you can explore the format, which is spread over several files inside the .ZIP, the most interesting of which is called content.xml. This is the data that needs to be transformed in order to get the information out of OpenOffice into your own format.
What we wanted was a way to store properies of all enemies in a single table, so designers could tweak values easily. The data then needed to be exported into a proprietary text format (not XML). This is also relatively easy with XSLT, but as with anything, exporting from Calc with XSLT had its pitfalls.
It’s easy enough to access individual cells in a row in Calc. Unfortunately, for some reason, they decided that if adjacent cells in a single row have the same value, it would only be stored in the first cell and an attribute on that cell would indicate the value repeats for n-number of cells.
With XSLT, there are no variables that can change their values, only constants within a single template (the XSLT equivalent of a function). Consequently, there are no “for loops” in the traditional sense. The way to get around this with XSLT is to use recursion. In my script, I basically have every cell recursively calling the template on the next cell in the row, or on itself in the case of repeated cells, and track the cell heading (the first row of the table) separately. Just thinking about it gives me nightmares.
At any rate, more and more data is being stored as XML, and consequently XSLT is probably here to stay. It’s another tool that should be available in the game developer’s toolbox, but must be used with care. To learn more, there are tons of resources on the web, but your best bet for a good introduction is the W3 schools site at http://www.w3schools.com/xsl/.
I actually use XSLT 2.0 as a code generator. .NET’s support for XSLT 2.0 is non-existent, but by using Saxon I can output to several result documents, use complex query functions and use multiple document formats. It’s very cool.
When we were building a toolchain for our quiz game series about a year ago I also looked at XSLT. The idea was: Word 2007 documents are XML (just like OpenOffice docs, as you describe above), and we can transform them to XML for the game engine using XSLT.
I find XSLT a bit annoying to work with (for the reasons you describe above). I’ve done some things with it, but nothing like this. For this and some other reasons, what we ended up with was a Python tool that reads data from Word 2007 (and later Excel 2007) documents into internal data structures, and then generates C++ header files containing that data. We had to rebuild to refresh data anyway, and given that this was a DS project the time and space savings were not insignificant. Also, it was simpler: we didn’t need any XML or JSON libraries.
Part of why I chose this approach was that I am more familiar with Python than with XSLT or C#, which naturally is kind of an arbitrary thing. However, I honestly don’t know if some of the more complex logic I later had to write to parse Word files (handling invisible text written by translation tools, or especially handling line breaks removed using Track Changes) could have been implemented using XSLT. (But maybe it would have been easier? I don’t know.)
An additional benefit of the route we took is that we could do a lot of preprocessing and especially analysis and error prevention in the tool, which greatly sped up our workflow.