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?
Comment on my binary map format
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.
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]
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]
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++
Rating++
Why do you need to define a size at all? Put the string in there and when parsing, read until you hit a null terminator. Maybe I'm missing something.
Quote:Original post by GroZZleR
Why do you need to define a size at all? Put the string in there and when parsing, read until you hit a null terminator. Maybe I'm missing something.
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...
- 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...
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..
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..
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.
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. ;)
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. ;)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement