Fost - Mr. Robot Art
Not much text this month (I'm sure everyone just wants pictures anyway :) ), as I'm working overdrive on effects. Normally these will appear in ghost hack mode (a section of the game which takes part inside a virtual computer world), but it's easier for me to set them up and test them in a dimmed room from the main game section, so all the screengrabs reflect this - you'll have to use your imagination and picture the effects occuring in a virtual reality world a bit like the matrix.
When coming from a reference point of making something similar to the real world, e.g: the smoke trail from a missile, you always have that refererence point to work to. With ghost hack, the only criteria is that it shouldn't look like the real world :) It's often hard to know when to stop tweaking an effect and several times I've made perfectly fine effects which then were transformed into something completely different after several iterations of tweaking! Moral: save often!
Things are progressing much faster than with effects creation on Starscape. Mark has made sure effects reloading works off several buttons, which speeds things up no end. I actually value that approach to programming games more than I would the solution of writing a dedicated particle systems editor. Text files aren't hard to edit, but if you don't have the ability to see your changes instantly, then it takes an age to create even the most basic of effects.
Poo Bear - Mr. Robot Programming
XML Storage Decisions
We already use XML for some file types in Mr. Robot, although it was more of an experiment in XML integration than something that was implemented in a sensible way. Whilst prototyping aspects of future games I've started to use it more and think about the best way to approach XML use in games.
I've not seen much discussion about what's considered best practice with regards to how xml is used to store data. There's 3 possibilities. E.g. storing data about a 3000 radius red sphere.
Multiple inline attributes in an empty element:
Multiple empty elements with a single inline attribute inside a containing block:
Whilst the use of multiple inline attributes in an empty element is the most tempting implementation, especially if you've come from using block files, it can get very messy if you have a lot and end up on multiple new lines. Once you start using a deditated XML editor rather than a text editor it starts to make a little more sense. Some commercial editors can even fold up container blocks making it easy to navigate and visually isolate data chunks (in fact, if you look at any xml file in the firefox web browser it will do this). So I've decided the last option fits most types of generic data. For single attribute empty elements I also try to stick to using the attribute name 'value' - it just makes things easier to remember. I'll still probably use several inline attributes for anything that won't break a line such as a particle system colour key like:
Whether this is good practice is anybody's guess, it just seems to be the best compromise between compactness, readability, and parsability by dedicated XML editors, but then XML wasn't designed with games in mind...
XML Document Type Definitions (DTDs) for Games
Using xml files for just about every type of game development file is currently vogue amongst developers. The main reason it seems developers have chosen this method is because it's then easy to use a lightweight, off the shelf file IO system like tinyxml, so you don't have to write your own text file parsing system. Sometimes though, I get the impression that people use xml files just because it's trendy :). On the face of it, they are much more unweildy than something like a blockfile.
//This is a comment
There's a lot of duplicate text for closing tags, and the HTML style commenting system is a bit unweildy. However, as well as versatile off the shelf file IO code, there is one other major advantage to using xml files that I don't often hear game developers talking about - and that's free file validation by using document type definitions. Document type definitions (DTDs) define what elements and values are allowable in a specific xml file type. This means that you don't have to write your own validation code to check for errors; you can use an off the shelf xml file parser that supports DTD validation (whilst tinyxml doesn't support this so it can stay small in size, there are many other xml parsers that do, such as xerces xml. Better still - you just use the built in validation systems of a dedicated xml editor (like the excellent and freeware xmlpad) to validate the file as it is saved out. Virtually all xml editors will also do code completion using the DTD, so it's easy to remember what tokens go where because the editor shows you what options are available at the current position in the file:
DTD based code completion in XMLPad.
Fost says that if he was still working in a big team as an art lead, he'd be pretty excited about this. Common errors that always crop up when text files are edited by non-programmers can be caught in the editing application before the game is even run. Normally this necessitates programmers adding lots of code to check the files on load and pop up suitably helpful and explanatory error messages. Automatic pre-validation of the files results in a massive time saving on both sides.
Writing a DTD is pretty easy too and it can be stored in a shared location; even on a webserver, so when the DTD updates anybody attempting to parse documents automatically uses the latest version.
Here's an example xml file representing some solar system data:
Solar System XML:
The solar system definition contains
line1: xml header
line2: DTD definition - this will be pulled out by an xml editor and used for validation.
In addition, each instance of contains surface sub containers, and optionally an
My point in making it this detailed is to show how different structures can be defined in the DTD:
Solar System DTD:
The first line: tells us to expect a 'solsys' element first, which will contain only 'config' and 'bodies' elements in that order.
The 'bodies' tag is defined: ' '
the '+' means allow any number of 'body' sub-elements.
Next we can define sub elements such as 'orbitScale':
this is marked as 'EMPTY' because is has no closing tag (i.e. it's written as
Even though the tag is empty, it can still contain inline attributes which are useful for storing game data. The following entry in the DTD defines what attrivute names can be used (in the case, I'm using the attribute called 'value' ):
The '#REQUIRED' keyword means this attribute must be present else the file won't validate.
If the attribute contains data from a predefined set, then we can define this here too, as with the '
This means you can insert any of the keywords: 'static', 'Mercury-VSOP87', 'Venus-VSOP87', 'elliptical' into the 'value' attribute. If anything else is present, then the file will not validate.
That's pretty much all you need for DTDs, at least as far as game data is concerned. The only other thing that is useful is the ability to define optional elements, by using a question mark. The 'ellipticalorbit' element in 'body' is optional: