I am considering using xml to populate a list of crafting recipes, but i have no experience with it. Instead of having a huge method that creates each recipe and puts it into a list, i would like to read from an xml file to make adding items and recipes easier. Is this a viable solution? Or is there another way/method that can make adding recipes and items to a list easier?

I use a datafile to define my recipes, its a fairly simple thing to have as long item types can be reference by some kind of id.

For example for me the "Item" class only defines the item type (e.g. I only have 1 Item instance for my iron bar item, and every iron bar in the world references that single instance). There are other, possibly cleaner ways, the main point in this situation is it gave me an easy "const Item *getItemByName(const std::string &name)" for console commands and data file loading.

class ItemStack
{
public:
    const Item *item;
    unsigned quantity;
    /**Exact meaning, default value, etc. is defined by virtual methods on Item.
     * e.g. for a tool this might be durability (and I also prevent non-new tools
     * from being stacked).
     */
    unsigned metadata;
};
class Recipe
{
    std::vector<ItemStack> inputs;
    ItemStack output;
    ...
};
List<Recipe> recipes;

<recipes>
    <recipe>
        <input item="log" quantity="1" />
        <output item="plank" quantity="1" />
    </recipe>
    <recipe>
        <input item="iron" quantity="1" />
        <input item="plank" quantity="1" />
        <output item="pickaxe-iron" quantity="1" />
    </recipe>
    <recipe>
        <input item="lead" quantity="1" />
        <input item="gunpowder" quantity="1" />
        <output item="bullet" quantity="100" />
    </recipe>
</recipes>

XML is a perfectly valid way to load structured data from a file on disk. There should be several libraries for your chosen language (if it isn't built-in) that can do the gruntwork of loading the XML file into a basic structure that you can iterate over to create your crafting data.

Is there a specific hurdle you're having trouble with in using XML?

Im using c# and xna. I know that i can read from an xml file, but i have no idea how. and the only hurdle i have is the motivation to learn it :p i just wanted to figure out if it would benefit me in the long run when i have up to 100 recipes.

Each recipe consists of a list of items needed, the output of the recipe which is a single item, and a string name for the recipe. Each item in the list of items has a parameter ItemCount which determines how many of each item is required to create the output.

I think sync has the right idea. All i would have to do it figure out how to store each recipe from the xml file into my list of recipes properly

XML is a perfectly viable way of doing this, especially since there are drop-in libraries (or built-in functionality) for every serious programming language, which make parsing the file a matter of a dozen lines of code.

However...

The same is true for other formats such as e.g. JSON which are arguably easier and less redundant (I only named JSON, other people will prefer something different). For example, there is no such thing as wondering whether or not to make some value an attribute or put it in between the tags. So, while I'm not suggesting that you don't use XML, I'd recommend that since you don't have any experience yet, you should at least look around. Looking doesn't cost you. Maybe you find something different that turns out easier for you (or more pleasing to your personal taste), and it has just about the same level of library support.

That said, I've used XML for decades although I dislike it, simply because I'm used to it (as is virtually everybody I know or have ever worked with). Back in the old days when XML came up, you would often still write the HTML for your website by hand, and XML was "kind of" just the same. So you already knew everything you needed, more or less. Which of course led to everybody yelling out "oh cool". Turned out it wasn't quite that cool, even though it was used everywhere (especially in the Java world), but although there exist better stuff, it remains usable. At least, for things like a datafile that you parse once (I wouldn't for example use it for RPC like the Java guys do, simply because it's waaaayyyyy too much data to be put on the wire).

I like using ini or json over xml. They are much easier to edit. Also, some languages (python, for instance) come with buildin support for them.

yeah, go for the easiest format. e.g. for my recipes they are actually currently just 1 recipe per line as space separated values, because it let me read the recipes directly from an std::ifstream with basically no messing around (and at the time, the project did not have any ini/xml/json support).

I strongly recommend avoiding JSON.

The syntax for JSON results in pains when trying to merge two content authors' changes to the same file, which are problems that XML, YAML, and so on (mostly) avoid. JSON has mandatory commas between array and object elements but also disallows trailing commas, meaning that two commits that both add an item to a list or object will never ever merge automatically or cleanly and requires careful attention and fiddling.

Tools first. "Easy to read text" is in no way important compared to "usability with tools." If the only way you have of specifying new content is by opening up Notepad, you've failed. Text formats are used often in game dev because of the ease of merging changes (e.g. usability with the SCM tools), not because it lets you skip out on developing proper tools.

XML is also supported directly by C#, the language the author mentions, whereas JSON is not. (Pedantic: .NET includes libraries for reading XML, but you have to go third party for JSON)

I second Sean's points about JSON as well, adding on that the XML toolbase is much more mature and allows external validation via XSD specifications. Plus I find XML more readable, but that's just me.

Heck, JSON doesn't even allow comments (in the spec).

I think JSON makes a decent interop format between programs where you don't want the wordiness of XML and validation is less of an issue, but for something I'm going to edit by hand (at least at first) I think XML wins out.

To get slightly back on topic - there are some decent examples on stack overflow for reading XML using C# which should give you a good place to start from.