Sign in to follow this  
  • entries
    28
  • comments
    110
  • views
    39405

BLACK I.C.E.

Sign in to follow this  
Poo Bear

306 views

-------------------------
Fost - Mr. Robot Art
-------------------------

Ghost Attack

Mr. Robot: Multiple particle effect powers
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.

Mr. Robot: Unistrike Launch Particle Effect


Mr. Robot: Self Destruct Energy Particle Effect


Mr. Robot: Self Destruct Particle Effect


Mr. Robot: Power Drain Land Particle Effect


Mr. Robot: Energy Drain Particle Effect


Mr. Robot: Power Drain Particle Effect


Mr. Robot: Firewall Particle Effect


Mr. Robot: Multi Strike Particle Effect


Mr. Robot: Misc Particle Effects


Mr. Robot: Misc Particle Effects 2


-------------------------
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.

ALL CDATA:

3000
red

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.

XML:





BLOCKFILE:

colorKeys
{
//This is a comment
key0 255,255,255,0
key1 255,255,255,100
}

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:
XMLPad Code Completion
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.

A top level container element which wraps all the information.
A element with setup information for the application (I'd probably put this in its own xml file with it's own DTD though).
A element, that contains multiple containers.
In addition, each instance of contains surface sub containers, and optionally an element.

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 rather than )
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 '' parameter:
static|Mercury-VSOP87|Venus-VSOP87|elliptical) #REQUIRED>

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:
ellipticalorbit?)>
Sign in to follow this  


8 Comments


Recommended Comments

Just read your whole Developer Journals - WOW!

Very interesting read, I loved it! Didn't see much on starscape, but both Mr Robot and War Angels looked really good, you and your team have done a great job - and given me the motivation required to get my arse in gear and work on my project!
Thanks :)

Share this comment


Link to comment
Firstly, on those shots - very nice stuff! I can't fault a single one of them. The XML stuff is some interesting content that got me thinking too. I probably slip into that unneccessary use category a bit, and the idea of block files made me think, "I should really think about what format is best first...".

So, all good content, and a very nice read!

Share this comment


Link to comment
It's interesting to see other Real World Developers starting to look seriously at XML for its strengths as a data representation method.

Right now at Egosoft we're doing a lot of work to accelerate our content-creation pipelines, and much of that involves creating more expressive and reliable data formats. XML is great because it nicely captures the hierarchical nature of just about everything we build, and the self-validation via a schema is just amazing. The Intellisense hints in VS2005 make data creation virtually mindless; the file format no longer gets in the way of the content design effort.

What I find most interesting isn't the use of XML in general (that's a pretty big trend already in all sectors of software, and often too much of a trend IMHO) but rather the specific decisions that different users come to about how to use it. For instance, all of our validation is done with XML Schemas instead of DTDs, which I personally find amazingly handy. (Plus, using XML to describe the validity of other XML is just a cool little self-referential gimmick that deeply appeals to my inner geek [smile]) We also explicitly forbid the use of CDATA and do everything as node attributes, which ends up producing much cleaner schemas for the particular data we're modelling.


I'd love to see some postmortem analysis of some of these decisions, especially the XML stuff. We're still quite early in the production cycle so there's a long way to go before we really know the full consequences of our choices; to some extent a lot of really good consequences have already arisen, but unfortunately I really can't go into detail.

Share this comment


Link to comment
I am again bottomlessly jealous of the quality of your art. You must someday detail what tools and people you use to do your art and animations.

Actually you probably have already, but I'm too much of a lazy SOB to check back and read it all.

Share this comment


Link to comment
Quote:
Original post by MrMeikel
Didn't see much on starscape

Starscape was out first project, and we finished it long before starting diaries (more's the pity - it would be fun to compare what we though then with what we think now). I did write up a post mortem for Starscape though.
Quote:
and given me the motivation required to get my arse in gear and work on my project!

Great! I'm always inspired most to work by seeing the works of others - so that's the nicest thing you could have said to me :) Good luck!
Quote:
Original post by ApochPiQ
all of our validation is done with XML Schemas instead of DTDs

Yes, I think anyone looking at DTDs should probably skip them and look into XML schemas instead - that's the way things are moving and you get more functionality out of it in any case.
Quote:
Original post by johnhattan
You must someday detail what tools and people you use to do your art and animations.

All Mr. Robot's art has been singlehandedly cerated by my colleague at Moonpod, Nick (Fost). He uses Photoshop and Wings3D pretty much exclusively, although we've been forced to use blender for animation. I think he's eyeing up one of the major packages once we finish Mr. Robot.
War Angels art is by Hamish - who pretty much is a one man show, also coding the game. I know he's been using cartography shop to edit his maps.

Share this comment


Link to comment
Quote:
Original post by MrMeikel
Didn't see much on starscape

Starscape was out first project, and we finished it long before starting diaries (more's the pity - it would be fun to compare what we though then with what we think now). I did write up a post mortem for Starscape though.
Quote:
and given me the motivation required to get my arse in gear and work on my project!

Great! I'm always inspired most to work by seeing the works of others - so that's the nicest thing you could have said to me :) Good luck!
Quote:
Original post by ApochPiQ
all of our validation is done with XML Schemas instead of DTDs

Yes, I think anyone looking at DTDs should probably skip them and look into XML schemas instead - that's the way things are moving and you get more functionality out of it in any case.
Quote:
Original post by johnhattan
You must someday detail what tools and people you use to do your art and animations.

All Mr. Robot's art has been singlehandedly cerated by my colleague at Moonpod, Nick (Fost). He uses Photoshop and Wings3D pretty much exclusively, although we've been forced to use blender for animation. I think he's eyeing up one of the major packages once we finish Mr. Robot.
War Angels art is by Hamish - who pretty much is a one man show, also coding the game. I know he's been using cartography shop to edit his maps.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now