sponsors gamedev.net search:

XML in games In my opinion, XML could be a valuable technology in games. It may not seem so, but I'll give a couple of applied examples. Adventure games It's not too hard to describe adventure game worlds in XML. For example: <object id="theBox" name="box" onLook="string:look_full"> <string id="look_empty">It's a box. It's empty.</string> <string id="look_full">It's a box. I think there's something in it.</string> <object id="theBall" name="ball" onLook="It's a ball." onPickup="do: set theBox:onLook string:look_empty; get theBall /> </object> So I've got a box, with a ball inside it, on the screen. I point at the box; the graphics have defined that rectangle as referencing object 'theBox,' so the game looks up the object 'theBox' and gets the 'name' attribute, so while I'm pointing the word 'box' appears on the screen. I've fudged together a pseudo-scripting language as an example... I click 'Look at' and then click on the box. The game looks up the 'onLook' attribute, and reads what it says. Normally, it would just print the value out literally, but because it begins with 'string:', it looks up the string "look_full" (part of the 'theBox' object), and displays it. "It's a box. I think there's something in it." I click 'Pick up' and then click on the ball, that I can see in the box. The game looks up the 'onPickup' attribute, and because it starts with 'do:' it executes the command shown on my cunning adventure-game VM. The value of the 'onLook' attribute of theBox gets set to "string:look_empty", and the game "get"s the ball - something which I predefined as a command. If I then look again at the box, the string "look_empty" is looked up, so I get "It's a box. It's empty." Bear in mind that all the script engine work is done by my game engine; XML doesn't do that for you, it just allows you to store the relevant information in a simple way. It's easily represented with a few classes (and I mean, two or three), and can be serialised efficiently (for saving/loading games - the entire world can be saved just by recursively writing out each element with all children). It's also excellent for testing or creating; you can edit the world state in Notepad and test the effects, rather than having to play with a hex editor or compile with custom-built tools. Saved/Loaded games Talking of saving/loading games, there's an entire application right there. <npc class="hairy_monster" health="50"/> <box class="water" state="full"> <npc class="shark" health="74"/> </box> So, we've got a hairy_monster, a volume of water (which is full, as opposed to drained), containing a shark. The only disadvantage of using XML as a format for saved games is that it might be a little <I>too</I> easy to read... you might not want people editing their saved games. However, in that case, all you need to do is encrypt/decrypt the file before/after you use it. Asset management <folder alias="models" loc="game/media/models"> <file type="model" name="player_front" loc="player/pfront.mdl"/> <file type="model" name="player_hand" loc="player/phand.mdl"/> <folder alias="weapon_models" loc="weapons"> <file type="model" name="shotgun" loc="shotgun/shotgun.mdl"/> <file type="model" name="shotgun_inhand" loc="shotgun/shot_hnd.mdl"/> </folder> <pack loc="miscmdl.pak"> <folder alias="gibs" loc="gibs"> <file type="model" name="gib_1" loc="gib1.mdl"/> </folder> </pack> </folder> And so on and so on. The above code describes a simple layout of a few files on disk and in a .PAK file (or whatever you want to use, maybe ZIP files, maybe your own equivalent). It'd be brilliant for virtual file systems; perhaps as a packing list (to ensure that the whole package is present, or by adding checksums to each item to check that it hasn't been tampered with), or information about files to load at start-up. In my game code, I could call 'LoadModel("shotgun")' and it'd be able to look up the "model" "shotgun" (located at "shotgun/shotgun.mdl" inside folder "weapons" inside folder "game/media/models", making a grand total of "game/media/models/weapons/shotgun/shotgun.mdl"). If you happen to move all your assets around, you don't really want to be changing all your code. Not to mention the fact that this method gives you the capability to change things on the fly - you could change the "loc" of the "models" folder to "games/models" if you discover that you've been configured to use the old models, for example. It also lets you look at the files you've got without accessing the hard disk; if I want to spawn a random gib, I can just pick a random child from "gibs" and load it, without having to check through the directory itself. Conclusion I hope I've set your mind off a little bit. These are only a few examples; but quite frankly, it appears to me that XML can be applied to, well, anything. You can describe structures or interfaces in it; <dword name="dwWidth"> could be useful sometime. You can use items to reference other items (as I demonstrated with the adventure game example). Heck, you can do anything. Next time, I'll look at how we actually use XML in code - I'll show you how to use a particular XML parser, expat (http://expat.sf.net/), to read the XML data in and get it into a tree structure, and then I'll show you how to write it back out again. I wonder why I write all my articles at 2:30am... and then revise them at 3:00am... :D Richard Fine (a.k.a. Superpig) rfine@lycos.com, or catch me in the forums or on #gamedev. Happy coding. :)

Contents   XML 101   XML in Games   Printable version   Discuss this article