xna - What is a good way to store tilemap data?

I'm developing a 2D platformer with some uni friends. We've based it upon the XNA Platformer Starter Kit which uses .txt files to store the tile map. While this is simple it does not give us enough control and flexibility with level design. Some examples: for multiple layers of content multiple files are required, each object is fixed onto the grid, doesn't allow for rotation of objects, limited number of characters etc. So I'm doing some research into how to store the level data and map file.

This concerns only the file system storage of the tile maps, not the data structure to be used by the game while it is running. The tile map is loaded into a 2D array, so this question is about which source to fill the array from.

Reasoning for DB: From my perspective I see less redundancy of data using a database to store the tile data. Tiles in the same x,y position with the same characteristics can be reused from level to level. It seems like it would simple enough to write a method to retrieve all the tiles that are used in a particular level from the database.

Reasoning for JSON/XML: Visually editable files, changes can be tracked via SVN a lot easier. But there is repeated content.

Do either have any drawbacks (load times, access times, memory etc) compared to the other? And what is commonly used in the industry?

Currently the file looks like this:

....................
....................
....................
....................
....................
....................
....................
.........GGG........
.........###........

....................
....GGG.......GGG...
....###.......###...
....................
.1................X.
####################

1 - Player start point, X - Level Exit, . - Empty space, # - Platform, G - Gem

Answer

So reading through your updated question, it seems you're most concerned about "redundant data" on disk, with some secondary concerns about load times and what the industry uses.

First off, why are you worried about redundant data? Even for a bloated format like XML, it would be pretty trivial to implement compression and get the size of your levels down. You're more likely to take up space with textures or sounds than your level data.

Second, a binary format is more than likely going to load faster than a text-based one that you have to parse. Doubly so if you can just drop it in memory and have your data structures just there. However, there are some downsides to that. For one, binary files are next to impossible to debug (especially for content creation people). You can't diff or version them. But they will be smaller, and load faster.

What some engines do (and what I consider an ideal situation) is implement two loading paths. For development, you use a text-based format of some kind. It really doesn't matter which specific format you use, as long as you use a library that's solid. For release, you switch to loading a binary (smaller, faster loading, possibly stripped of debug entities) version. Your tools to edit the levels spit out both. It's a lot more work than just one file format, but you can kind of get the best of both worlds.

All that being said, I think you're jumping the gun a bit.

Step one to these problems is always describe the problem you're running in to thoroughly. If you know what data you need, then you know what data you need to store. From there it's a testable optimization question.

If you have a use case to test against, then you can test a few different methods of storing/loading data to measure for whatever you consider to be important (loading time, memory usage, disk size, etc.). Without knowing any of that, it's hard to be more specific.