Loading and saving a tile based game in Java. XML or TXT?

Question

For some time I've been making a 2d tile based sim game, and it's going well! Thanks to this site and its kind people (You!), I have just finished the path-finding part of the game, which is fantastic! THANK YOU!... Anyway, to the question.

At present, the test level is hard-coded into the game. Clearly I need to re-work this. My idea was to have all variables in my Game class saved to a text file in various ways. I could also write the details of each level into a file to be loaded for a level. My question is, should I be using just a text file, or using XML? I understand what XML is basically, but I don't really know how I would use it in conjunction with JAVA, or why it's preferable or not over a plain text file. I had a bit of a google, and there are WHOLE books on XML and JAVA! I can't see I need to know EVERYTHING about how to use XML with JAVA to make this work, but I do need to know more than I do.

Thanks in advance for your help with this.

Edit: I will try several of the ideas here until I find the one that works the best, and then that will be chosen as the answer.

Edit: Chose xStream. Easy and simple!

Answer 1

For a 2D tile-based game, XML is probably overkill. XML is good for storing hierarchical data and/or marked-up text, but it sounds like you just need a way of encoding a 2D grid of tile settings, which is far easier to do with a plain old text file.

Just have each line be a row of tiles, and decide how many characters you want per tile (probably one or two would be fine). Then decide how to represent the objects in your 2D world with characters in the text file.

In SokoBean (a game I wrote over 10 years ago, so not what I'd call my best work, but whatever) I used text files like this one. In addition to being easier to parse than XML, you can also use a plain old text editor as a level editor.

Answer 2

You're using files for an internal purpose. The short answer is, as long as the file format fits your purpose, it's fine. You do want to do what you can to insure that the format is clear, as simple as possible, and extensible. The most important bit here is to extract the data reading and writing to a single point in the code that's responsible for reading and writing the file format.

The common formats are common because they're simple and well supported - you don't need to write special code to parse files (properties files, basically just a list of key-value pairs, and xml files -think of xml files as a way of writing arbitrarily deep nested dictionaries).