# 2D map file syntax

This topic is 4800 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I know this question has come up before, but I've haven't really been able to get a good answer from any of the threads that show up on this topic. What I'm looking for is a good file syntax for storing a map for a 2D, tiled game. I've been playing around with a couple of ideas, neither of which really appeal to me. The data I store in the file will be loaded into a structure that looks like this:
struct Tile {
size_t x, y;
char* graphic;
int bitflags;
}


One idea I've tried is to adopt a pseudo C++ syntax, and provide all the data through text, something like this:
tile {
graphic = "FOREST.TREE"
posx = 5
posy = 5
extras = ... (whatever)
}


This has an obvious disadvantage that if my map is, say, 20x20 tiles I would need 400 entries, all of this length, and a 20x20 map is a very moderate size. Another possibility I've toyed with is this:
WIDTH = 5
HEIGHT = 5

define T "FOREST.TREE"
define P "FOREST.PATH"

TTPTT
TTPTT
TTTPT
TTPTT
TTPTT


I like this because it stores the position of tiles implicitly, cutting down on filesize. However, this format is limited to about 26 tile types (one for each letter). Also, I have no way to store "extra" data this way; I would probably have to store extras (like sprite footprints, or treasure chests) as I stored information in my first example, specifying coordinates and data. A third possibility I've heard is to use binary I/O: I've never worked with this, although I'll gladly learn it if I'm told its the best way. However, one short-term problem I could see with this solution is that it would be difficult to edit a binary file without a map editor, which would probably be a lot of extra work to write. This isn't insurmountable (I'll probably have to write a map editor at some point anyway) but I'd prefer not to have to design an editor at the same time I'm trying to design a file structure. Does anyone have an opinion on which idea is better (or, better yet, a better idea)?

##### Share on other sites
You could use XML. Since there are a number of XML libraries available (like TinyXML) it would save you from having to write as much code as you would if you were to adopt the pseudo-C++ format.

However, using XML would suffer from the same problem as the pseudo-C++ format, too many entries. In both formats it's also difficult to see how the changes you make to the file affect the map as a whole while in your second format (which unfortunately doesnt store all the information you need) does quite well.

Personally, I would bite the bullet and design a map editor. It will make editing maps for you much easier even if it is a lot of work in the beginning.

##### Share on other sites
Thanks for the response; I feared that creating a map editor would be the way to go. That being said, what would be the easiest way to go about creating this editor. Most of my experience has been with strict C++, and I would hate to try to program stuff like scrollbars and input boxes without some sort of library. I have a little experience with Visual Basic and it seems like a possible option since this looks to be a RAD project. Or should I look into learning something like MFC--this might allow me to write allow me to preserve a lot of the code I've already written for loading and rendering tiles/sprites since I could (presumably?) just stick the MFC code on top of my already written classes?

##### Share on other sites
I've used the 2nd option you suggest with a dungeon romp game I once made in college, in which a single character indicates what type of tile you are using and so forth. While this will of course work, it isn't very extensible. For instance, if you want several things going on in a tile, you either have to have several instances of the map for the different types of elements that can be in each tile. This of course breaks down because lets say you have one map for floor tiles, such as

TTTPTTPTT
TTTTPTPTT
TTTTTPTTT
TTTTTPTTT
TTTTPPPTT

For trees and path. Now, how about a monster?

.........
.........
.........
.........
......M..

And objects (treasure, items, etc) ?

...I.....
.........
.........
.....T...
.........

This quickly breaks down because you will have too many maps to parse. Your idea for key-value pairs with item and location is better. But I find this approach in general flawed because its not very extensible or scalable.

The last game I wrote I used a strategy similar to your first idea, in which I enumerate the tile, and list all the extras or "objects" that are in that tile, such as enemies, background objects, etc. This approach works very well, and I haven't had any problems with it.

I didn't go the XML route, but I certainly could have. It makes your flat text file more human readable, but beyond that, if you have a set file format, it won't gain you anything (other than ease of parsing if you use a pre-made XML parser, which I would highly recommend). So using XML in combination with your tile structure format seems logical.

I hand-edited flat text files for a long time while developing my last game, and found it to be VERY tedious. Whatever strategy you end up using (character blocks, tile descriptions, XML entities), I would highly recommend taking the time to write a level editor before/during writing the game itself. It will make you think about how you structure your map data, and will make creating levels much, much simpler and much faster. I wasted so many hours manually editing tiles in my level files. I wrote my level editor in MFC, but then again at the time I knew MFC and it wasn't too much of a big deal. MFC can be quite a bear sometimes, but it will help you develop a GUI level editor with (relative) ease.

##### Share on other sites
Don't worry too much about file size. Worst case you end up with something huge - then you just write a converter that changes to a binary format for use when you actually distribute the game. Text based (XML is good) is great during development because you can easily hand alter it and tends to be robust when you add extra data to your file format. Even if you do a map editor (I do) its still good to have an xml based file.

##### Share on other sites
Theres a Java tile editor called "tiled", amazingly enough, that outputs in xml, where the map data is either a table, or a base64 string, depending on what you pick. I found its plenty easy to yoink the base64 string and put it in my own data file (a lua script file to be exact), and then drop that data file into a zip package file and load it from there using the miniunzip contrib that came with zlib.

Sounds complicated, but it all works out.

##### Share on other sites
You could switch from a single character map to a numeric map.

00 00 00 01 01 01
00 00 01 01 01 00
...

If you run out of space( i.e. hit 99 ), just add more permitted digits to the format.

I liked your code / pseudo code of
#define T "Forest.Tree"

##### Share on other sites
Test Map //map name
5 //map width
3 //map height

@setTileID 0 tiles\rock
@setTileID 1 tiles\grass
@setTileID 2 tiles\trees

0,1,0,1,0
2,0,1,0,1
2,2,0,1,0

@setObjectID 0 items\gold
@setObjectID 1 monsters\orc

@placeObject 0, 3, 2
@placeObject 1, 3, 2
@placeObject 1, 3, 3
@placeObject player\spawn, 0, 0

##### Share on other sites
For Blob Wars : Metal Blob Solid I saved map data as,

0 0 0 0 1 0 0 2 0 0 0 3
0 1 1 2 0 0 2 0 1 2 0 4
...

The numbers would refer to an image in an image index. Because the map was saved as a 2D array for chars it meant I could use numbers between 0 and 255 for the tile indexes. This was more than enough.

The type of tile would be assumed. So,

0 would be air
1 would be water
2 would be slime
3 would be lava
4 - 100 would be solid tiles
etc..

Next, objects would be stored in the same map file,

ITEM 100 320 256 "Key Card" RedKeyCard

The first parameter would tell the map loader this is an Item
The second parameter would define the type of item
The third would be the x coordinate on the map
The fouth would be the y coordinate on the map
The fifth would be the name of the object
The sixth would be the sprite name

Using a format like this would mean you can edit your map items easily in a text editor and also understand what they are. It's also quite scalable.

1. 1
2. 2
JoeJ
20
3. 3
4. 4
frob
11
5. 5

• 13
• 17
• 13
• 20
• 13
• ### Forum Statistics

• Total Topics
632191
• Total Posts
3004661

×