I''m at a point in my design document where I can take a break and start work on the technical aspect of my game. I decided my first step would be to determine how I would store tile data. What I am trying is new, to me at least, so I thought I''d run it through this topic because people seem to get intelligent answers here... Essentially, I want to store the graphical tile data in a single file. This should prove to be a more effective solution than creating a tileset file type for each map file, or combining the tileset data with the map file, etc. Using this method I can save disk space by abstracting the graphics from the map. The map file would then contain a table of indexes cooresponding to the tiles in the main tileset file. A value of 0 would mean the first tile, n - 1 the last tile, etc. Once the map has been loaded, the table would then be consulted and a "build" process would begin. This would entail converting the specified tiles within the tileset file to a DX7 surface. The actual implementation of this build process would include opening the tileset using file mapping, because it possesses the potential to become rather large. Then the table of indexes would be looped through...first seeking to the position of the tile within the file, then retrieving the raw bitmap data associated with it. Once all of the raw tile data has been collected, I can then create a DX7 surface, lock it, and plot the tiles to it. I''m hoping this will allow the tile data to be easily updated, or added to, by some sort of patch program. However, there is one limitation that is fairly obvious: tiles must be the same size...so I might have trouble adapting this to sprite graphics. Anyways, if you could take the time to point out any flaws or suggestions it would be appreciated. Hah Coe

Sounds good. Have you figured out if you are going to need to combine different tilesets. Let''s say you have two different mappers who''ve volunteered to do some mapping. Can they create new tiles? Are you going have just One set?

>>>>>
I''m hoping this will allow the tile data to be easily updated, or added to, by some sort of patch program. However, there is one limitation that is fairly obvious: tiles must be the same size...so I might have trouble adapting this to sprite graphics.
>>>>>>

For objects you might want to divide them up into different categories. The NPCs'' graphics on each map can be stored into the map files. Items like inventory would have their own data file. The question is: in the Map file or Separate Graphics data file?

I''m finishing work on my map editor and I''m going to be mailing it to two different guys who will probably make their own tiles(my editor includes a tile cutter). Hmmmm I better figure out what to do.

ZoomBoy
Developing a iso-tile 2D RPG with skills, weapons, and adventure. See my old Hex-Tile RPG GAME, character editor, diary, 3D Art resources at Check out my web-site

Hmm...that is something to consider. Indeed, if multiple people are buidling levels, and want the freedom to add their own tiles, then I would run across some problems. This doesn''t really harm what I''m trying to do, as I''m the only one developing. For a team scenario however, it might be a hassle to keep the main tileset file current, so to speak, for the builders.

It is a good point though, and if I ever take on team members I''ll do some thinking on the subject.

Hah Coe