in reply to Map Storage For Game

when I was making tile based games, 'twas all the rage to read in simple text files composed of single characters which determined terrain type.

for instance,

Key

  1. mountain
  2. forest
  3. swamp
  4. impassable ocean
and then have the file look like (for a 5x5 map) 
ddddd
dbaad
dcabd
dabbd
ddddd
that tells you which bitmap to place where, see? this doesn't work for most 3d games, of course.

Replies are listed 'Best First'.
Re: Re: Map Storage For Game
by mr_mischief (Monsignor) on Oct 24, 2001 at 18:48 UTC
    I've actually toyed with a game system using two values per tile. One is the elevation, and the other the type of ground cover.

    0-9 elevations

    r=rocky, f=forest, g=grassy, w=water, etc.

    This allows for a slightly more complex computation for movement, as movement is normally slower uphill than down, and a game engine could even use the map to figure trajectory differences for missile weapons to nearby tiles and things like that.

    As for using a DB instead of a flat file of keeping it all in memory, I was planning on putting regions encoded like the above into the database, and pulling entire regions from the database into memory when needed, so say you could have a 16-by-16 or 32-by-32 region that gets pulled out when someone is within a certain number of tiles from it, or when someone actually enters it if the game doesn't allow multi-tile vision (depends on style of game and granularity of land areas depicted by the tiles).

    I've worked quite a bit in this area, and I'm always happy to talk about it. I may even be interested in joining a project if that's an option. Perl is a good language for this type of game because of the ease of manipulating the data structures in different ways.

[reply]

In Section Meditations