2D Level File Format
Author
I'm making a 2D tile-based RTS engine. Right now, I'm still designing the classes and how I'm going to put this together. One of my questions so far is, which was is best to store the level data?
My plan was to use an XML document and layout different tiles and triggers, spawn points, etc. I know that this can be done in different ways, maybe less readable and far less bulky. Yet, this seems to be a simple, easy-to-do, easily extensible, and supported method.
What do you guys think? Is there a better way to do this than laying out the level data in an XML format?
You will probably end up writing a map editor anyways, so it's probably better to write your own binary file format. The size difference is pretty big, especially if your game will be downloaded. It's not really that challenging; just choose a format and stick to it. (That's assuming you know how to do file IO.)
i agree, make a map editor. its not as hard as you think and the payoff is far worth it.
I wouldn't spend a lot of up-front time on saving and loading data. If you can just save and load the data as simple text, then do that. The last thing you want is to be spending all your time coming up with a file format. Try to design your saving and loading so that you can switch to a better format later.
As far as XML goes, I like using it to save and load data. I have spent some time writing support functions, so now it is pretty simple for me to implement code to load and save data as XML.
As far as the map editor argument goes, there isn't any reason why the map editor can't load and save the XML data. So, that is actually a reason for using XML.
As far as bulkiness goes, you can always compress the XML file (using zlib, for example).
As far as XML goes, I like using it to save and load data. I have spent some time writing support functions, so now it is pretty simple for me to implement code to load and save data as XML.
As far as the map editor argument goes, there isn't any reason why the map editor can't load and save the XML data. So, that is actually a reason for using XML.
As far as bulkiness goes, you can always compress the XML file (using zlib, for example).
Author
Thanks for the input. I am going to make a map editor. It's too difficult coding levels by hand, as I've found out from past experience. My interest comes in choosing to easily lay out the data in XML or some other format. The reason why I'd like to use XML is it's flexibility. I can easily add on more data that I originally didn't plan on without writing a lot more code. It comes virtually pre-parsed and is visually pleasing to the eye.
The main drawback that I see, as nagromo mentioned, is the file size. If the game gets downloaded, compression I guess could handle the larger parts of it. The larger parts of the game would be the image data, seeing as those don't get compressed nearly as much as text files do.
I do know file I/O, or at least the basics of it. However, for an XML format, I could use a library such as TinyXML, which handles all the file I/O internally. For most of my earlier projects, they were basic enough where I could use cin to parse everything. Albiet, this method sucks wang and I wouldn't be using that for a project such as this.
The main drawback that I see, as nagromo mentioned, is the file size. If the game gets downloaded, compression I guess could handle the larger parts of it. The larger parts of the game would be the image data, seeing as those don't get compressed nearly as much as text files do.
I do know file I/O, or at least the basics of it. However, for an XML format, I could use a library such as TinyXML, which handles all the file I/O internally. For most of my earlier projects, they were basic enough where I could use cin to parse everything. Albiet, this method sucks wang and I wouldn't be using that for a project such as this.
A simple map format ain't hard.
A header with ID, mapsize (aka tile count), object count, tile data (size of one tile times tile count) and then object data (size of one object times object count).
Much more advanced formats can also be done, but that was just a quick overview of a simple map format.
I think it's fun to come up with a new file format in each game, and it's not hard at all. You just write down what you need, and then make the needed structures and then a file format (preferable in binary, because that loads a lot faster).
If you've got a map editor (or making/want to make one), then you don't have to be able to edit the file data, and therefore also gets the speed at load-time when making it binary.
Also, the size problem is huge with text formats (just an example):
1 map in text: 23 MB
1 map in binary: 1 MB
Most people don't want another Space Invaders in 2D to fill 15 MB, where the map files contains the 14 MB ;) Well, that would be a lot of maps, but again, it's just an example.
A header with ID, mapsize (aka tile count), object count, tile data (size of one tile times tile count) and then object data (size of one object times object count).
Much more advanced formats can also be done, but that was just a quick overview of a simple map format.
I think it's fun to come up with a new file format in each game, and it's not hard at all. You just write down what you need, and then make the needed structures and then a file format (preferable in binary, because that loads a lot faster).
If you've got a map editor (or making/want to make one), then you don't have to be able to edit the file data, and therefore also gets the speed at load-time when making it binary.
Also, the size problem is huge with text formats (just an example):
1 map in text: 23 MB
1 map in binary: 1 MB
Most people don't want another Space Invaders in 2D to fill 15 MB, where the map files contains the 14 MB ;) Well, that would be a lot of maps, but again, it's just an example.
Author
So true. I'll have to layout it out on paper. For the most part, right now, in the early stages of my work, I want something simple and extensible. Depending on how I design, the binary format would be a lot better for speed and size. Distribution-wise, compression programs could take care of the text-based levels. I'm just worried about performance. Thanks for the input.
I'd still say XML would be good. If you understand XML it's much easier to work with and as stated before is easily extensible. For distrubtion, you'd be compressing any way, so that's not a factor. As far as performance you can just use a loading screen.
Author
I wonder if it would make a very large difference in time loading the XML file as versus a binary file. With today's hardware, I would imagine that it would be negligable in terms of processing.
Quote:Original post by Tarviathun
I wonder if it would make a very large difference in time loading the XML file as versus a binary file. With today's hardware, I would imagine that it would be negligable in terms of processing.
For any decent amount of data then there is definatly a big difference ... but if your loading time goes from 1 second to 5 seconds then although its a huge increase nobody would care. Developing your game useing XML with a lib like tinyXML will be pure joy - you can change the fileformat any time with relative ease, you can also add extra data or comments into the file without it messing things up and it will also be alot easier to update your old levels when you change the format (try changing a binary file to a new format and you'll know what i'm talking about). There are heaps of other benifits of working with text files over binary and the only real drawback is loading speed. For one of my own projects I wrote the whole thing useing xml and then at the last minute wrote a simple console app that converted the xml files into binary files - then ingame i could load either the xml or binary versions. Once my app was completed with the xml version it only took an afternoon to add the binary version - but having the xml during development was great. So I would suggest sticking with the xml files for pure ease of use, then later if you want/need it you can easily add a binary loader without much hassel.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement