Tiled level format...

You should use attributes more.

program="GulpRad Level Editor"
date="Wed 13.9.2006"
version="0.0.0.1">

I wouldn't use XML myself either - the only advantages I can see for it are that you can use an existing XML parser to load the data to some extend, and it's easier to change in a text editor.

iliak's format comes closer to what I'm using, although I did it a little more compact: the first so many bytes are simply binary numbers, with a strict specification of where the width, height, number of tiles and such values are placed. I also store the starting byte locations of the tileset data, tile data and entity/actor data. The tile data is binary as well, which is, at least theoretically, faster to handle and allows for a more compact file.

Having multiple blocks, one for the visual layer, another for the collision hull and another one for pickups isn't a bad choice if you ask me. Personally I would use some scripting part at the end of the file for the pickups, but that's because I'm more thinking towards items with specific properties and non-tile-restricted placement.
EDIT: You may want to check this thread I made a while ago. The scripting system I made for that prototype is a good example of what I mean.

Anyway, such choices depend a lot on what you want and need. If file size or loading speed isn't a big issue, and rapid development is instead, then go for XML or whatever other format you can think up on.

Although using XML for maps seems like a good idea, it's actually really difficult to manage. When you have multiple huge levels, it can get rather confusing to create manage and edit maps. A better idea might be to use an external map editing tool like Tile Studio or Mappy.

I implemented it into one of the projects I was working on and it worked quite nicely. You can see a screenshot of it on the right. If you click on it, you'll be taken to the journal post with another screenshot of me editing the level.

IF you're going to use XML (and I DON'T recommend it here), you've got the usage exactly backwards.

You want to collapse the tags by using using attributes for things like a version number etc. that could only be strings, and not contain any sub-tags. Meanwhile, you want individual tiles grouped together - array of structures rather than structure of arrays, you know, just like you would want in your code's data structures - and you want the structure of the XML document to reflect the structure of the map, creating dimension information implicitly rather than storing it explicitly (any kind of comma-separated data is a big warning sign).



Yes, it will be a lot of data that compresses stupidly well, but the zip will probably still be bigger than a properly designed custom (likely binary) format, and it's painful to look at, and it can't enforce rectangularity of the map (there's no way to write your XML schema that I can think of that would check for rectangularity). Which is why I don't recommend XML here at all.

Storing things in the order you have is reasonable, it's just totally not what XML is supposed to look like. If you had metadata (author etc.) that could actually get complex, and an already-designed binary format for the actual layer information, then you could consider using XML as a wrapper around the binary data, but that has some minor technical issues too (heaven help you if the text representation of your binary data just happens to contain the CDATA close tag).

EDIT: OK, I suppose you can enforce rectangularity by not insisting on exposing the whole structure in XML, but that's supposedly not how you're supposed to do things ;)

Anyway, I recently have been doing things in Python by making a file like this:

# The whole file is just one Python expression!{ 'CreatorName':'Riku-Juhani Niemelä / RetroGen',  'CreatingProgram':'GulpRad Level Editor',  'Date':'Wed 13.9.2006', # I could instead put a constructor call for a Date class  'Version':'0.0.0.1', # I could instead put a constructor call for a Version class  'Tiles': [    { 'PixelSize':(48, 48), 'FilmstripSize':(10, 2), 'File':'tiles1.jpg' },  ],  'Layers': [    { 'RowLength':20, 'Tiles': [        tile(1, 0, 0), tile(1, 0, 0), # continue with other 398 tiles      ]    }  ]}

It still has a fair amount of redundancy, but it's got more informative bracketing, *typed data*, and unbelievable ease of input (if you don't care about error checking, which you can always get to later):

level = eval(file('level.txt', 'rw').read())