Sign in to follow this  
john_t

2D map file syntax

Recommended Posts

john_t    122
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 this post


Link to post
Share on other sites
Colin Jeanne    1114
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 this post


Link to post
Share on other sites
john_t    122
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 this post


Link to post
Share on other sites
roger_hq    116
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 this post


Link to post
Share on other sites
OrangyTang    1298
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 this post


Link to post
Share on other sites
Inmate2993    222
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 this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
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 this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
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 this post


Link to post
Share on other sites
Scarfy    122
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this