[Bjorn]

Some of you hanging around the #indie-rpg channel already know I've been working on saving my maps in XML format. I really like the flexibility of XML and the fact that it is text based and easily understandable on looking at it. And this being the first time I ever used XML in an application, it was a good learning experience.

I'll give an example of what my map format currently looks like:

[LeoDraco]

You could always describe in the layer tag a "base" attribute, which is the normal base tile of map. (I.e. the predominant tile.) Then each tile definition would just store an offset from the corner of the map, and/or the index/name schema you're using now. Sure, for really detailed maps (ones in which there is not a definable "base"), you wouldn't save much space, but it might cut down some of your map sizes.
_________________
"...LeoDraco is a pompus git..." -- Mandrake

[Bjorn]

Yeah, the offset idea certainly decreases the size of the big sewers map. Most of our other maps use the space rather well though, so it would make things worse in those cases.

I have been thinking about first storing the names of the tile bitmaps, giving them numbers, and then referring to those numbers instead of using their name all the time. That would decrease the size of the raw data a bit, though it would probably increase the size of the zipped version. :-)

I might introduce the base attribute on the layer element, and having it be the default tile for tiles without a name. Then I'd need to do <tile name=""/> for real empty tiles though. And I'd need to figure out what the dominant tile is.

At the moment, I think neither of these optimizations are really worth it. They save space at the cost of complexity, and just zipping up the data will be the best size reduction you can get already.

[ThousandKnives]

I use XML files for map data. In fact, for almost all data. But I find the idea of using XML for storing map grids kind of goofy. I use a binary file for that. Using XML is a fairly needless repetition of a large amount of data. The more different tiles start appearing on a map the less the zip compression helps. Same with the "default tile" value - it is of little use once your maps get complicated and have a large number of different tiles.

The primary benefit for XML I find is for storing and editing "structured" data like that for items, spells, enemies, objects, and scripts (I don't like having any such game data hard-coded into my program). Every piece of data for these items has a default value for every tag so that a child only has to be included when the value is non-default. So maps consist of 2 parallel files, one for the grid data and one for pretty much all other information (map name, default background music & graphic effects, objects, scripts, etc).

As for needing an XML library, I don't know about that. I wrote my own DOM XML parser in a few hours. Its extremely easy (at least in C). I could have spend as much time fumbling around trying to find an XML library and learn how to use it as I did just writing my own and knowing inherently how to use it. Obviously it has no XSL support, etc. -but I don't see any need for that much functionality.

[Bjorn]

Ok, thanks a lot for your input! I agree that the tile data is rather a big bunch of data and thinking about it, it would have been good to use a tight binary format for the tile block, while using XML for additional properties of the map and information about the objects present on the map. The only downside that I can think of is that you can't have two people edit the tiles of a map at the same time, but then the need for this hasn't ever come up yet. :-)

libxml2 was a very quick and easy way to start saving and loading XML, faster and more reliable than anything I could have done myself, and with more features for anything I might want to do in the future.

[janus]

You should look at how Ika represents its maps. It's far more elegant than using plain XML like you're doing - still human-readable and editable in notepad, but much more compact and easier to load. It's all open source too, so it should be easy to learn from.

[Bjorn]

Their setup looks like Scheme or Lisp, and it's nice, but in my opinion there is no big difference with using XML, and I'd actually prefer XML because it's a standard, its widespread use and the many libs and tools available for it.

The one interesting thing they do, is storing the raw map tile data in a compressed text-based format (not editable by hand though) and embedded into the map file. I like this approach above storing it as a seperate file, and it could be done this way with XML too.

An example of what I looked at:

[ThousandKnives]

That is certainly do-able. The problem with embedding your data in your XML/etc file, is that is that your data isn't really in binary that way, and you lose certain values, like those for the ASCII characters < and >. That is, you may intend it as binary data but it is still considered ASCII by your XML parser. So certain numeric value have to be eliminated. Obviously with a custom file parser you could store the length of the data as a property and ignore such characters in that portion of the file, but now your files have lost their XML compliance. So you would have to sacrifice those values and figure out ways to handle them in order to keep them out of your files.

[DrunkenCoder]

Or you could just use Base64 encoding like many other applications like e-mail does.
_________________
If there's life after death there is no death, if there's no death we never live. | ENTP

[white_door]

Repeating massive amount of tile data is not ever going to be a problem if you are going to be compressing your xml files. Although I don't use xml for my map files, I do use a very similar text format. (I should really convert it to xml sometime) Like yourself, I use full text names for each tile. And in fact, I found that I ended up with smaller map sizes, than I did when I was using a binary format. (both compressed) The fact is my text format seemed to compress better. And since I store the files compressed.. and only decompress when the map loads.. the files stay tiny.

Okay you might lose some of the human readablity of it, due to the fact you have a ton of tiles to read past... but there are still other advantages to using a xml format or something like it, the primary one being flexibility, another being debugging.

Its much easier to expand or change a xml format, and 90% of the time you can still read your old maps with the same loader, this means you don't have to rush in to converting all your maps everytime there is a change, and if something goes wrong in the new format.. you don't have to then convert them back.

Okay you could do some of that with a good binary format, but you would end up with something like a binary form of xml anyway. And for sure using a binary format makes debuging a map file loaders or savers harder, you can't just go and read a map file to see what it is outputing or loading.

Anyway its just my opinion on the matter, but I think you should stick to your first format aboce.

[Bjorn]

[Mandrake]

I've used this before....not a huge fna of how Ika does things. Mainly becuase it extends itself using Python rather than extending Python. Anyway- XML data is great. It compresses, it's human readable, and it's portable. I've got a short XML parser/generator I created awhile ago that works wonders.

Anyway- the nice thing about XML is you could also easily creat an XML compiler/compresser/encrypter for hiding game information....it's also very easy to patch an XML file or create a patch system (much like doom wad's)
_________________
"Well, last time I flicked on a lighter, I'm pretty sure I didn't create a black hole."-
Xmark

http://pauljessup.com

[omega_alpha]

XML is an excellent form for saving all kinds of program configuration data. I've used it for a plugin I wrote to save user configuration data as an alternative to the Windows directly. XML is highly portable and a basic parser is fairly simple to write. But I think its usability for game maps depends on the size and complexity of the map data to be saved. If the maps are large and complex than perhaps a simpler format could save room so that ultimately those who download your game can do so much faster.