Re: OT: Tile maps

The posts in this thread should get you rolling just fine. My question is have you defined how "far" the character can see? Will it be single or multiplayer? How often will you be reloading a "map".

1) One you know how far a given character can "see", then you can use the suggestions from above to define the area. Personally I would define tile set types, (i.e desert, plain, castle, dungeon, etc..) as well as (pulling from Blizzard's StarCraft map editors vocabulary) doodads (trees, broken pillars, staircases/ramps, etc...). Then assign particular doodads to type set types. Ie Stairs_up-4.jpg belongs in desert, whereas Stairs_up-1.jpg belongs in the castle set. Then the char enters a castle scene. If you have say something along the lines of a bitmap describing what the area should look like, you can load the tileset, assign random tiles for the floors, walls, (could be multiple tiles for floor design, wall design, etc to display difference in terrain, think Final Fantasy 2 for SNES), sprinkle doodads across the non door/stairs/special bitmap offsets, all with simple method calls, and a tile set definition.

2) If you are gonna do multiplayer, then I'm not sure what types of optimizations are gonna be needed in terms of location/surroundings updating you are gonna have to do. (Im presently working on a text based MUD, which is along the same lines, but I dont have to deal with graphics, so if I come across some decent insights there I can msg you with the thoughts)

3) If you are reloading a map fairly regularly you might want to actually build once, via whatever method, and then store that do mem/disk, so that it gets paged in and out at once. As opposed to rebuilding every reload. I don't know what kind of constraints you are placing on yourself in terms of memory usage, wether you are implementing this on a PC/workstation type platform, or a emulator/specialized hardware platform. So with that in mind, I don't know what type of optimizations you can perform to minimize performance hits.

If you have defined a 64x64 grid, and use the tileset idea from above, and lets say the character can actually see 60x60, then you have a 4 tile buffer in any given direction. If the char were to move north, then the southern tiles simply move outside of your buffer reagion, and you randomly generate a new row of tiles across the northen buffer zone. This way you are only ever "paying" to create one row of tiles, as opposed to updating the entire "map" every move of the character. (I think this is filtering up from reading about how the original doom and wolfenstein games were thought up, and how to limit performance hits while creating a 3D world. While you aren't necessarily dealing with 3D, the benefits of implementing this way can be fairly substantial). If you prefer that they "see" 64x64, and can determine how long it takes to generate a line of tiles, you can alter your "offscreen" buffer to suit.

I hope this is at least somewhat helpful, and happy hacking :)

/* And the Creator, against his better judgement, wrote man.c */

Comment on Re: OT: Tile maps

Replies are listed 'Best First'.
Re: Re: OT: Tile maps by BUU (Prior) on Feb 14, 2003 at 16:47 UTC
If you have say something along the lines of a bitmap describing what the area should look like This is really my main problem. I don't have anything along the lines of a bitmap or anything else describing how my over all map looks. And I really have no clue as to how I could/should develop one. At the moment I'm kind of thinking about just defining tiles at the beginning of the map in a header, then just having a list, like: `##header## name: foo.map author: baz size: 250x300 tileset: forest 0=ground1.jpg 1=ground2.jpg 2=trees1.jpg 3=trees2.jpg //etc etc ##endheader## 0 0 0 0 1 1 1 0 0 0 1 2 2 3 3 2 3 3 //etc` [download] So first I would read the header (uh, some how), go through all of the 'terrain tile definitions' and generate an array with `array[0]=grass1.jpg` and so forth. That way i wouldn't have to do hash look ups on every tile. Then from there maybe I could apply further optimizations, such as chunking them into areas and having rows already generated off screen and so forth.	[reply] [d/l] [select]
Re: Re: Re: OT: Tile maps by Mr. Muskrat (Canon) on Feb 14, 2003 at 17:02 UTC
I was thinking more along the lines of a hash: my %map = ( name => 'foo.map', author => 'baz', width => 250, height => 300, tileset => 'forest', tiles => [ 'dirt1.jpg', # half dirt, half grass 'mud1.jpg', # half dirt, half mud 'grass1.jpg', # grass with a few shrubs 'trees1.jpg', # sparsely populated with trees and many + shrubs 'trees2.jpg', # moderatly populated with trees, less s +hrubs 'trees3.jpg', # heavily populated with trees, sparse s +hrubs 'stream1.jpg', # stream running north/south (variation +1) 'stream2.jpg', # stream running north/south (variation +2) 'stream3.jpg', # stream running northeast/southwest 'stream4.jpg', # stream starts in northeast but winds a +way to the west ], layout => [ [ 1 6 1 0 2 2 3 ], [ 1 7 1 0 2 3 3 ], [ 1 8 1 0 2 3 4 ], [ 6 1 0 2 3 4 5 ], [ 7 1 0 2 3 4 5 ], [ 9 1 0 2 3 4 5 ], [ 1 0 2 3 4 5 5 ], [ 0 2 3 4 5 5 5 ], ], ); [download]	[reply] [d/l]
Re3: OT: Tile maps by dragonchild (Archbishop) on Feb 14, 2003 at 16:59 UTC
I would go about describing in English how it is you should be able to describe your map. For example, is there going to be a hard-coded set of N areas each with a set 16x16 tiles? Or, are you going to be more dynamic (allowing a player to build a city, thus changing the tile)? Obviously, the solution is different in each case. Once you've determined the parameters for what your map-description needs to be able to do, then the solution should be relatively obvious. Almost always, design is driven by requirements concerns. More than that, it's often discovered as a logical conclusion from the requirements. Sometimes, the only logical conclusion from the requirements. If you're casting about for a good design, make sure your requirements are solid first. If they're not (and they usually won't be), fixing them will help solve your design problems. ------ We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.	[reply]
Re: Re: Re: OT: Tile maps by l2kashe (Deacon) on Feb 14, 2003 at 17:31 UTC
Again talking about your area of "view", and tilesets. Lets say you define a 100x100 area as being forest. Heres what I am thinking. Now what you can do with this is start testing if present_pos <= some_val_from_next_area then start mapping that area before they actually encounter it. Also with this approach you can generate "random" dungeons of differing sizes to explore, and they should all have a slightly different look and feel, depending on how many tiles you add to each tileset. Also you can gen an area once, print out the map to a file, then tweak to add doors, etc via a simple editor which you can create to work with this data structure. Then save again, in edited form. That way if you have say a main castle, which is pivitol in your quest, all that needs to be done, is to map the def to tiles, and print, as opposed to generating the area then mapping then printing. {l2kashe}.o O ( maybe even do the mapping via the editor to avoid the mapping cost completly at run time?) Hope this helps and that the readmore tag works like I hope it does :P Read more... (2 kB)	[reply] [d/l]