Sign in to follow this  

Comment on my binary map format

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've been working on my tile engine, and I created a map format. Tell me what you think, or if there's anything missing.
int namesize - number of characters in map name
char name[mapsizew] - name of map
int x- number of tiles x-axis
int y- number of tiles y-axis
int bgmsize - number of characters in bgm name
char bgm[bgmsize] - name of starting background music .mid, .wav, .ogg, or .mp3  
                    file or NULL
int numberofevents - number of events that can happen
Tileset tileset - actual tileset object, contains one BMP
__________________________________
Events events[numberofevents] - the actual events are added to the event stack                 
                                here.
__________________________________
__________________________________
Tile tiles[x][y] - actual tiles are read in here through a while loop based on  
                   earlier variables intx and inty, and events are read in
__________________________________
What do you think? Any suggestions?

Share this post


Link to post
Share on other sites
Couple o' suggestions:
Give the character names a fixed length at say a 100 or so instead of having it defined. I doubt that it is going to too important to have an individual length for each name.
What are events?
For the tiles, I'd have a one dimensional array of those Tile structures that states it's x, y, width, height, etc... You might just want the total number of tiles instead of the x-axis tiles and y-axis tiles.

EDIT: Thanks!

[Edited by - deadimp on January 16, 2005 7:39:37 PM]

Share this post


Link to post
Share on other sites
Good suggestion involving the name. Events are just functions that are called when a condition is met, like "Invoked", "Stepped on", "Pushed", etc. I will also take your advice involving the tiles; that would make it much easier. Thanks!

Rating++

Share this post


Link to post
Share on other sites
A few quick ideas.

- Like suggested, just give your strings a fixed length. It's easier to manage and doesn't make too much of a difference anyways, unless you know they'll vary from a few characters to 30k of text or something. ;)

- Depending on how you handle resources, you could just give them an ID and refer to that. It would be easier to handle than a string in some instance. Of course, this is based on assumptions on your resource system.

- You should make tilesets external to your maps so you could reuse them without storing them twice. That is, assuming tilesets will be reused.

- I'd store events after the map data. That's when you start having variable-length stuff, so it'd be easier to get the (mosty) fixed-length data out of the way first. No reason, frankly; it just sounds more "right" to me like that. :)

- You should refer to tiles by an ID. If you have only 256 tiles in your tileset a single byte is all that's necessary, which is very little. Otherwise, it's hardly likely you'd need more than a word (65,536 unique tiles).

In my map system, I have a header, a map layer, a map data layer (ie, which tiles can be walked through, tile behavior... usually encoded as a series of flags in a byte to save space), then an object layer with sprites and associated events. Seems to work pretty good that way. :)

Edit: In response to the above link, why not just read the length at runtime? Not trying to spark off a new discussion in this thread, but wouldn't it be simpler to just count the bytes read before the terminator (ie, \0) instead of storing it in the file? Mind you, that's a matter of size vs. speed of execution and on a very small and possibly unimportant scale...

Share this post


Link to post
Share on other sites
you might also want to put a "validation header" at the top of your map.

basically, the first line you write to the file would be "XYZQBR".

then, when reading in a map file, you read in the first line. if it is not "XYZQBR", then, it is not a valid map file. this helps so when your user tries opening a text file or some random file in the map editor (or game even), your editor has a way to detect it is not a valid map file, other then attempting to parse the file itself..

Share this post


Link to post
Share on other sites
Those all sound like good suggestions. Special thanks to RuneLancer, that's a great idea. I should actually have three layers: ground, object, and that 'secret layer'. Rate++s to all.

Share this post


Link to post
Share on other sites
That's roughly how I did my maps too. I had a ground layer, an object layer, then some additional stuff depending on what I needed (ie, sprite layer, for instance). I also tried to make my tilesets seperate for both layers, which made it easier to fit 256 tiles in either set and thus using a singly byte per tile.

If you're concerned about space, you should do some kind of run-length encoding. For instance, anytime the tile ID '255' is found, the next two numbers will be the real tile ID and how often to repeat it. A ground layer will often have a lot of repeating tiles as part of walls (ie, the black stuff where the player can't walk) or the ground itself. An object layer will probably have quite a bit of empty space where there are no objects to be drawn.

This makes something as simple as the above very worthwhile if you have many big maps, though only worry about that sort of thing after you get around to making the maps and seeing for yourself if it's that big a deal. Writing a quick little program to load your maps and write them back to disk after read and compressing the tile section wouldn't be too hard then, and your work wouldn't be in vain. ;)

Share this post


Link to post
Share on other sites

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

If you intended to correct an error in the post then please contact us.

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