I've been trying to decide how to handle saving game data. At first I was using plaintext which is quick and straight forward but also very, very ugly. I wanted to delve into the world of XML to save data since although it is a bit slower since it has to run through an XML parser (albeit custom built) but definitely the more elegant of the two. Also, since XML can be ported so easily it could, with very little effort, have a second life in a completely different form, ie. a graphical game instead of textual.

So the argument comes down to quick and dirty or elegant and portable. Which would you choose, or have you found to be successful?

I'm working on an XML game engine at the moment ^_-.. I'm allowing as much as possible ( objects/object traits, map layout, hopefully objectives [ basically everything except binary graphics and sound ] ) to be defined and linked up using XML.. In this case; the XML becomes a sort of 'pseudo source code' and it's thus important for it to be structured and easily interpretable at a glance. The interface should be elegant, the implementation should be quick ( and optionally dirty ); and both should be as portable as possible. In my case, a part of the interface is the structured input..

But if you're just considering save games; as in a player's postition and status in the game at any given point in time; you may WANT to keep those files unreadable - otherwise you'll encourage cheating =P.

Certainly don't worry about time-taken-to-load when considering an option; whether you're opening the game and loading in resources based on an XML manifest, or reading in a players position to re-enter the game :- the load time will usually be a one-off; which becomes irrelevant when compared to optimizations you can make elsewhere; say in the game cycle; physics engine, AI, redraw code, or anything else that has to be done repeatadly..

It might even be faster if you use a good XML parser ( I'd advise looking at an existing one rather than custom building, Apache's Xerces project is very full featured, and pretty stable, and quite fast ); than interpreting a custom file format; which may end up developing a complicated structure out of neccessity rather than any forward planning...

In our first year of Computer Science (High School) we wrote a few games as end of year projects using XMLs to store information and save info.

We loved the flexibility and structure XMLs gave us but ran into problems in maintenance the next year after Java had released 1.5.0 and rewrote it's XML handling functions.

I would tell you to go with XMLs but keep in mind that the way your language handles XMLs can change, the way it handles text won't.

If you're storing data only your game will need to interact with and requires no outside programs or users to be able to read the data, then I would stick with a standard text file. The only data I would store in XML is stuff that wouldn't be harmed by the user changing the data, such as name of the player, key bindings, or other stuff that's commonly find in other game INI files.

If you'd used standard APIs for XML handling you'd have had no trouble...

But to the topic.
What you use depends totally on what you're storing.
If it's simple flat data, a properties/ini file is the way to go.
If it's hierarchical (or likely to become so in the future) XML is called for.
If performance is paramount (hardly ever when reading files) a binary format storing entire structs is the way to go.
For games running on servers in a distributed environment, use a relational or object-relational database server.