XML format for game data

Question

I want to create an XML format in which I will define data objects for a game I am currently working on.

The base idea is that I will have Elements which can be combined in other Elements, Items or Spells.

A primal element is an element which is directly available. If an element is not primal then in order to create it, it must be combined from other elements so it will have a recipe definition (list of components required to combine in order to create the specific entity).

Items and Spells also need to have a recipe.

As of now I created the sample XML:

<TechTree>

    <ElementDefinitions>
        <Element name="Fire" primal="true"/>
        <Element name="Earth" primal="true"/>
        <Element name="Nature" primal="true"/>
        <Element name="Mana" primal="true"/>

        <Element name="Lava">
            <Component>Fire</Component>
            <Component>Fire</Component>
            <Component>Earth</Component>
        </Element>

        <Element name="Grass">
            <Component>Nature</Component>
            <Component>Mana</Component>
            <Component>Earth</Component>        
        </Element>

    </ElementDefinitions>

    <ItemDefinitions>
        <Item name="ManaPotion">
            <Component>Mana</Component>
            <Component>Grass</Component>
            <Component>Nature</Component>
        </Item>
    </ItemDefinitions>

    <SpellDefinitions>
        <Spell name="FireSpell">
            <Component>Fire</Component>
            <Component>Fire</Component>
            <Component>Mana</Component>
        </Spell>

        <Spell name="HealingSpell">
            <Component>Nature</Component>
            <Component>Nature</Component>
            <Component>Mana</Component>
        </Spell>

        <Spell name="MoltenArmor" selection="ordered">
            <Component>Lava</Component>
            <Component>Nature</Component>
            <Component>Mana</Component>
        </Spell>

        <Spell name="RestoreMana">
            <Component>Mana</Component>
            <Component>Mana</Component>
            <Component>Mana</Component>
        </Spell>

    </SpellDefinitions>

</TechTree>

As of now there aren't too many attributes, but in the future the entities will have all kind of attributes (damage, effect, usable conditions etc) so I need to have a format that would allow me to extend, for instance, all items but not spells or elements.

I will enforce with an XML schema that components used in the recipe must be already defined. So writing Air as a component without firstly defining it will yield an error.

Although as of now all recipes have 3 elements in the future I might decide to create some with a different number.

I would greatly appreciate feedback or tips on how can I improve the format.

Answer 1

XML based configuration structures often tend to change during the development-cycle of the product. It is good to plan ahead, but you should also expect to run in to something that needs a format change.

First though, the structure you have for your XML appears clean, and good. The presentation you have is good and neat. That makes it nice to review.

There are some suggestions I have that will help you though.

1. Use Attributes. Atributes are a convenient storage system, and don't have the same white-space uncertainties as element content. I would convert all your current text-based values to attributes (and I would also incorporate the quantity as suggested by Pimgd):

   <Spell name="RestoreMana">
       <Component item="Mana" quantity="10" />
   </Spell>
   

2. Use references that are unique and not related to the name. I would consider using the attribute name 'id' because that has some advantages:

   <ElementDefinitions>
       <Element id="elem-fire" name="Fire" primal="true"/>
       <Element id="elem-earth" name="Earth" primal="true"/>
       <Element id="elem-nature" name="Nature" primal="true"/>
       <Element id="elem-mana" name="Mana" primal="true"/>
   
       <Element id="elem-lava" name="Lava">
           <Component ref="elem-fire" quantity="2" />
           <Component ref="elem-earth" />
       </Element>
   
       <Element id="elem-grass" name="Grass">
           <Component ref="elem-nature" />
           ......
       </Element>
   
   </ElementDefinitions>
   
   ....
   
       <Item id="item-manapotion" name="ManaPotion">
           <Component ref="elem-Mana" />
           .....
       </Item>
   

The advantages of these changes is that each element has a unique ID that will help resolve looking for things in potentially multiple places. Additionally, having a reference that is independent of the display name allows you to change properties of the data in a single place, without having to redo many places in your code. For example, you could possibly have multi-language support directly in the XML with something like:

    <ElementDefinitions>
        <Element id="elem-fire" name="Fire" name_fr="Feu" name_de="Feuer" primal="true"/>
        ...

Answer 2

I'd wrap the <Component>s in a <Components> tag. Maybe you want to add more attributes to spells later. In fact, I'd probably make <ItemComponents> and <SpellComponents>.

I'm also thinking you might be better off here and there by using some sort of "quantity". Lets say a spell had 10 components (for some arbitrary game design reason)...

    <Spell name="RestoreMana">
        <Component>Mana</Component>
        <Component>Mana</Component>
        <Component>Mana</Component>
        <Component>Mana</Component>
        <Component>Mana</Component>
        <Component>Mana</Component>
        <Component>Mana</Component>
        <Component>Mana</Component>
        <Component>Mana</Component>
        <Component>Mana</Component>
    </Spell>

or

    <Spell name="RestoreMana">
        <Component quantity="10">Mana</Component>
    </Spell>

I like the second one more, it's smaller. Plus, I don't wanna be the one who has to check if the balancing is done right by counting whether this spell has 10 components via a process which includes manually counting lines.

From this point, however, you can go pretty much everywhere. Future proofing your schema is hard without fully knowing what data it will have to support, so I'd focus on getting the domain model right and then looking at the xml schema again.