You could make your own archive file. You should be able to find libraries that let you easily create a zip (or tar/gz) archive of a set of files. That would give you an easy way of keeping an associated set of images, map file, and tiles.lst file together, and you could check the collection for consistency, too.

That said, I would rethink how your images and the tiles.lst file are organized. It sounds like you're only storing one tile per image? o_O

Normally "objects" are referred to as "sprites", and they would be kept all together on one (or a few) "sprite sheet" images; tiles, meanwhile, would be packed together in a grid on a single "tile sheet" image. Then you would have data specified like:

Tile file: tiles.pngTile width: 16Tile height: 16Tiles across image: 16Tiles down image: 10# Then if a tile ID in the range 0 to 159 inclusive is requested, it would be# taken from the appropriate region of the tiles.png image.Tile file: tiles2.png# etc. The second tile sheet specified in your configuration file would# represent tiles with IDs 160 to whatever, and so on.Sprite file: sprites.pngSprite name: Hero_stand_right coords: 0 0 18 29# And you would go on specifying a name and the rect (bounding box) of each# sprite represented by the file.

I am deliberately writing this in a vague and hopefully language-agnostic way ;)

Quote:Original post by Frequency
I've made a map editor before that used tiles, but I'm about to embark on something reasonably complex so I'd like to see if there is a smoother way of doing things. The old way I used was to have the map editor read a file called "tiles.lst" that had on each line a string that was the name of an image file, the ID number of the tile, and whether it was an 'object' (not aligned to grid) or 'terrain' (tiles in a map). This worked - the map editor saved the ID of the tile, and the main app opened up tiles.lst and loaded the image associated with it - but it seems sort of ugly and breakable. Is there a better way to do this? Things that spring to mind:

Embed the image data in the map file - but this means multiple maps using the same tiles uses lots more space than is necessary.
Create a table at the beginning of the map file saying "ID 0 = suchnsuch.bmp" which the main app will store and then use to load and render the map. This seems promising; ID numbers could be generated on the fly, too, so 1st kind of tile placed on a blank map is ID 0, 2nd kind of tile is ID 1, etc, but this introduces complications when re-editing a map twice.
Something else entirely?

Thanks for reading.

If your tiles are all the same size you could have them all be on one big file.
(2D grid of tiles with coordinate blocks being the tile ID)
Objects could too if they all use similar rectangles (possibly a second file if they are a different size from the tiles).

Of course if your objects have animations of different lengths it might be easier to keep them in their own files.

Quote:Original post by Frequency

"stonish.png",ter,0
"dirt.png",ter,1
"tundra.png",ter,2
"water.png",ter,3
"grass.png",ter,4
"groundtile.png",ter,5
"stoneground2.png",ter,6
"yuckymarble.png",ter,7
"pillar.png",obj,8
"magnaball.png",obj,9
The format should be pretty easy to follow.

Quote:If your tiles are all the same size you could have them all be on one big file.
(2D grid of tiles with coordinate blocks being the tile ID)

Not a bad idea at all - I would prefer if it were easier for the end user (and me, I guess) to use but realistically this might be the best option.

EDIT: Actually, Zahlman sort of already said that and I just didn't comprehend it right. Sorry if I'm frustrating.
However, you say "Then you would have data specified like: [file stuff here]", where would that go? Just sort of metadata about tiles that would go in a file separate from the map and the tile sheet?

If its static data, then a data array could be used (internal to program)

If its changeable data (static structure) then it could be .CSV or .XML format
or stored as binary data (and modified by an editor which imports/exports)

Quote:Original post by Frequency

Quote:Original post by Zahlman
You could make your own archive file. You should be able to find libraries that let you easily create a zip (or tar/gz) archive of a set of files. That would give you an easy way of keeping an associated set of images, map file, and tiles.lst file together, and you could check the collection for consistency, too.

Interesting, but even compressed I still shudder at the thought of having 6 copies of "street_left.bmp" because 6 of my included maps use it!

Then don't have them. There's no reason you can't put all the maps in the same archive. Call it a "project" file or something. Actually, that's just what Tile Studio does - it makes .tsp "tile studio project" files. But TS doesn't have the foresight to make it be a renamed .zip that would let you get at the individual components :(

Quote:
That said, I would rethink how your images and the tiles.lst file are organized. It sounds like you're only storing one tile per image? o_O

Given the "o_O" I'm guessing you think I've done something extremely stupid...I think I've only done something silly. Here is the tiles.lst for the map editor I made for a failed project in the past:
"stonish.png",ter,0
"dirt.png",ter,1
"tundra.png",ter,2
"water.png",ter,3
"grass.png",ter,4
"groundtile.png",ter,5
"stoneground2.png",ter,6
"yuckymarble.png",ter,7
"pillar.png",obj,8
"magnaball.png",obj,9
The format should be pretty easy to follow.

Yeah, that's exactly it. You would instead make a single file with the first 8 textures (since they're aligned to grid and "tile-sized", they're all the same size, right? So they should pack nicely into a little 2x4 rectangle), and then you give the attributes of the tile*s* stored in that image. So that the editor knows how much of each image represents each tile.

Quote:

Quote:Normally "objects" are referred to as "sprites", and they would be kept all together on one (or a few) "sprite sheet" images; tiles, meanwhile, would be packed together in a grid on a single "tile sheet" image. Then you would have data specified like:

So far I've only made one project which touched animation; for that I used (as an example) "playercharacterwalk.ani" which listed image files to be displayed in sequence along with how many milliseconds each frame would be displayed, like:
"mypcwalkf1.png" 200
"mypcwalkf2.png" 250
for a simple animation. I'm guessing this isn't the recommended way to do it either - I know of sprite sheets - but I guess I was too stupid or lazy to use 'em. I think the framework I've built would support it though so maybe I should to save myself some trouble later.

Doesn't matter: if it's not a tile, it's a sprite in these systems. It just might not be an *animated* sprite. :) Because they're things that aren't tile-sized and grid-aligned, you can't take the above shortcut to defining where they are on an image, so you go and specify the coordinates for each of them.

So in our case, if the different tiles are 16x16 each, and we pack them into a 64x32 tilesheet; and the two sprites (objects) are 20x25 and get put onto a 40x25 spritesheet; we could make a file like (emulating the old format):


"tiles.png", 16, 16, 4, 2
----
"sprites.png", 2
"pillar", 0, 0, 20, 25
"magnaball", 20, 0, 20, 25


The idea being that IDs are implicit (since they were sequential before anyway): 0..7 are tiles, and then the sprite section of the file follows, and IDs 8 and 9 are assigned to the sprites. Tiles don't really need to be "named", but it is often convenient for your sprites to have names (rather than IDs). You might not want to keep this information around after loading, but you could for example build a mapping of sprite names to sprite IDs, and consult it when loading animations so that you read in a list of names but store a list of ID numbers.

Quote:

Quote:If your tiles are all the same size you could have them all be on one big file.
(2D grid of tiles with coordinate blocks being the tile ID)

Not a bad idea at all - I would prefer if it were easier for the end user (and me, I guess) to use but realistically this might be the best option.

EDIT: Actually, Zahlman sort of already said that and I just didn't comprehend it right. Sorry if I'm frustrating.
However, you say "Then you would have data specified like: [file stuff here]", where would that go? Just sort of metadata about tiles that would go in a file separate from the map and the tile sheet?

Yeah, my thinking is that it would go in a file that replaces the current tiles.lst. Of course the exact format is up to you, and depends on what language and tools you are using.