Hey,
I’m going to write a tile-engine for an RPG i hope to make (w/ the SDL of
course), but I don’t know a whole lot about programming w/ files. I was
wondering what the best way to store the data to a file would be (this is
what i was thinking):
–MAPFILE-- //unique identifier-type-thing
x //# of rows and cols
map data goes here
I’m using a struct w/ three members for the tiles (x, y, and terrain type
(an enumerator)).
What’s x and y? Keep in mind that it’s hard to get the graphics to look good
if you’re playing with sub tile offsets… (Unless you’re using multilayer
maps with “sprite” style tiles for the top layers, of course - that’s when
you should use offsets to make things a lot more flexible.)
Would I want to store these in binary format, or just
write them as ASCII?
Depends on what kind of resolution (ie number of tiles/textures/whatever you
need to address), how big your maps are, what your average target systems is
and so on…
In general; ASCII formats are significantly bigger, but can help debugging a
little. For more complex things, (bordering to scripting, like in most newer
3D games), ASCII formats have the big advantage of not needing various custom
editors. They’re also more flexible and easier to keep compatible accross
versions, at least if you think some about the syntax.
However, large tiled maps aren’t much fun to edit in a text editor, so you
pretty much have to find or hack an editor anyway. As a result,
ASCII/binary doesn’t matter much. Further, as tiled maps are usually just
huge arrays of very simple structs, binary formats are easier to deal with
form the code perspective (no parsing; just load the raw data and dig in),
faster (again, no parsing).
(and what would be the best form for this)?
I’d probably go with something along the lines of a fixed size header with an
ID string and a version code (don’t forget that one!), map size etc, followed
an array of structs. The latter should preferably have some nice alignment,
and sensible field sizes. (Don’t try to squeeze things into little bit fields
and stuff right from the start. Count on changing things a few times…) If
you’re not terribly worried about file size, you can reserve space for
additional fields, so you don’t have to physically convert all map data every
time you need to add something to the format.
If you’re planning to build a massive set of complex tools around the file
format, one way to still keep things simple could be using two formats; one
simple “source” format (big, fixed size structs, lots of “reserved for future
use” fields etc) and one “compiled” format that the engine uses. That way,
you can limit the file format dependencies to the engine and the “compiler”,
and you can also have the “compiler” reorganize things in just about any way,
just to please the engine.
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Saturday 12 May 2001 00:37, Cameron Matheson wrote:
