Game Logic in XML Files

Question

I'm dealing with game dialogue files (conversation between player and non-playable-characters) where dialogue choices and their outcome depend on certain conditions and result in certain actions. Now, I could write a simple parser to handle some sort of language for specifying the pre and post-conditions, but a friend of mine suggested using XML. Conditions could be stored as attributes of a dialogue element and choices and actions are inner elements. I'd then use an eval function to parse these conditions and statements (I'm using Ruby to make this game). To make such an approach simpler, I could then write a simple GUI to manipulate these files without worrying about ugly XML.

But it strikes me as an odd choice to handle logic in XML files. My understanding is that XML files are for the storage and exchange of data, and I always read rants about how people overuse XML for all sorts of things it wasn't designed for. My friends responds by noting how XML IS used for everything, including XHTML and this bullet description language (which also illustrates some logic).

To be honest, using XML would simplify a lot of things for me. Writing a parser can be painful and time consuming, and my requirements are generally simple. But is it really okay or would I regret such a choice later?

For people interested in details, here's what a basic dialogue exchange might look like in an XML file:

<dialogue id="101" condition="!npc.carsFixed">   <message>Man, fix my car!</message>   <choices>     <choice condition="hero.carFixingSkill > 5" priority="7" id="Sure!">       <command>hero.carFixingSkills += 1</command>       <command>npc.carFixed = true</command>       <command>hero.playSmokeAnimation()</command>       <command>nextDialogue = 104</command>     </choice>     <choice condition="hero.carFixingSkill <= 5" id="I can't...">       <command>nextDialogue = 105</command>     </choice>     <choice id="Fix it yourself">       <command>npc.likesHero -= 1</command>     </choice>   </choices> </dialogue> 

The corresponding code if written in Ruby would be:

def dialogue101   if !npc.carsFixed     showMessage("Man, fix my car!")     choices = []     if hero.carFixingSkill > 5       choices.push(Choice.new("Sure!", 7))      else       choices.push(Choice.new("I can't"))     end     choices.push(Choice.new("Fix it yourself"))     choices = selectTopPriority(choices) if choices.size > 4     result = showChoices(choices)     case result     when "Sure"       hero.carFixingSkills += 1       npc.carFixed = true       hero.playSmokeAnimation       dialogue104     when "I can't"       dialogue105     when "Fix it yourself"       npc.likesHero -= 1     end   end end 

Stuff like likesHero and carFixingSkills are knowledge pieces player and NPCs can have, which would probably be stored in a hash in the real implementation. I find the dialogue file approach more flexible because I could make an editor to easily edit dialogue and conditions/actions, and because of the complex nature of game conversation trees. A scripting language like Ruby or Lua helps, but it'll require complex structures to handle to logic of such trees.

Back to the original question, is XML the right tool for the job or am I missing something?

Answer 1

Unless your game will have less than half a dozen unique dialogs, you should definitely put this information in some kind of data file. XML is a strong contender for the format. I don't speak Ruby, so it may not work in this case, but another option would be to define the dialog as data directly in Ruby code. (I know this would work pretty well in Lua, Python, and Javascript... I assume defining nested data structures is also easy in Ruby.)

We used XML files to define all the static data in Pirates of the Burning Sea, and it was a great way to go. Having a data format like this lets non-programmers control the data and frees up the programmers to work on features instead of data entry. Having those data files be text means that you can keep them under source control so you can tell when they change.