• Advertisement

Archived

This topic is now archived and is closed to further replies.

Question on Tiling for RPG

This topic is 5714 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Okay... I admit I''m lost. Is it better, if one is building an RPG, to build small tiles and construct the map as a series of tile numbers in an array somewhere? Is it better to build one VERY LARGE MAP, break it up into a somewhat manageable section, and not use tiles at all? (If that is the case, how do you link the map to an isometric coordinate system for movement?) Is it better to build one very large map, and break it up into little tiny isometric tile pieces? Your help is VERY appreciated.

Share this post


Link to post
Share on other sites
Advertisement
The advantages of using small tiles.

(1) Less memory taken up for storage, on disk and in RAM.
(2) Reusability, A road is a road is a road.


There are probably more, but these are the two main ones. Using an array, vector etc to store indices into a graphics lookup table or list is a generaly accepted practice. It makes for drawing maps much easier, I''ve never had a talent for artwork .

,Jay

Share this post


Link to post
Share on other sites
Thanks for the reply.

What, then, is a good map tile size?

I keep seeing things on here and on JavaGaming.org something about tiles being no bigger than 256 by 256.

Also, if we assume the client''s screen is a viewport to a much larger map section, are we building an image, say, 1000 x 1000 and viewing only 640x640 of it, assuming that is the size of the game window?

Share this post


Link to post
Share on other sites
My rpg was 800x600 and used 20x20 tiles. They worked fine but seemed to small, because I would have to place each tile individually in my lev editor so it took a while.

Share this post


Link to post
Share on other sites
i always go for tile sizes of 32x32 or 64x64 (depending on if i want small or big ones)... they line up nice in a power-of-two sized bitmap, and it is easy to write the sprite indexing offset code.
but that''s just me.

Share this post


Link to post
Share on other sites
Krez,

Thanks for the suggestion; this morning I was talking with the artists and we decided to go for 64x64. Could you tell me a bit more about your sprite calculations, using a tile size like that?

Thanks,

Joe

Share this post


Link to post
Share on other sites
quote:
Original post by GergisKhan
Thanks for the reply.

What, then, is a good map tile size?

I keep seeing things on here and on JavaGaming.org something about tiles being no bigger than 256 by 256.

Also, if we assume the client''s screen is a viewport to a much larger map section, are we building an image, say, 1000 x 1000 and viewing only 640x640 of it, assuming that is the size of the game window?


Tile sizes any bigger than 256 and even 256 are rather large tiles. But it all depends on what you are trying to do.

As for the viewport question, that depends on how big your maps will be. Say you are in 16 bit, a 1000x1000x16 image is going to be approx 15MB. If resources aren''t going to be a big issue than drawing the map before hand and just blitting the viewport area from the map to the screen will work just fine and will be a bit faster. However, if resources are going to be a problem, like on most machines anyway, it would probably be better just to assemble the portion of the map that is viewable on screen. It''s a good deal slower, but won''t hog so many resources.



I know only that which I know, but I do not know what I know.

Share this post


Link to post
Share on other sites
quote:
Original post by GergisKhan
Thanks for the suggestion; this morning I was talking with the artists and we decided to go for 64x64. Could you tell me a bit more about your sprite calculations, using a tile size like that?

well, if you have a bunch of sprites in one bitmap, you will have to be able to find the right one when you want to draw it... say you have a 256x256 bitmap full of 64x64 sprites... that''s 16 sprites in a grid:
+---+---+---+---+
| 0 | 1 | 2 | 3 |
+---+---+---+---+
| 4 | 5 |(6)| 7 |
+---+---+---+---+
| 8 | 9 | 10| 11|
+---+---+---+---+
| 12| 13| 14| 15|
+---+---+---+---+

now say you want the 7th sprite (index=6, two across, one down). since you know the sprites are 64x64, the 7th one would be:

//xOffset = spriteIndex MOD spritesAcross - 1
//yOffset = spriteIndex / spritesAcross
xOffset = 6 % 4 = 2 // "mod" returns the remainder of division
yOffset = 6 / 4 = 1 // offsets are integers, so this will
// truncate to "1" not "1.5"
//x1 = xOffset * spriteWidth
//y1 = yOffset * spriteHeight
x1 = 2 * 64 = 128
y1 = 1 * 64 = 64

so, your 7th sprite''s upper-left coordinates are 128,64 (and the lower-right ones are the same plus 63). but, when you want to draw it somewhere, you just need the index of the sprite (in this case 6) and you can calculate where on the bitmap to "grab" the sprite graphic from. each tile in your MAP class just needs to store a pointer the the correct bitmap, and an index of 0 to 15.
this will work with any sized sprites (as long as they are all the same size as each other), even if the height and width don''t match (i.e. 22 x 36). i just find it easier to work with powers of 2 personally (when drawing the sprites, i can easily calculate where the "boundaries" are between sprites); this is just me though.
did that make sense?

--- krez (krezisback@aol.com)

Share this post


Link to post
Share on other sites
Another way to do this is if you''re making really huge maps is to use "chunks". Ultima VII did this to great effect - Ultima VII''s map is 24576 pixels by 24576 pixels - over 600 MILLION pixels. Yet the map only takes up just over a meg on disk.

They did this by creating "chunks" which are effectively supertiles of a certain terrain type. For instance, they could create a forest "chunk", which would be a 512x512-pixel area of trees, rocks, and grass, and then tile that chunk over and over to create a large forested area. They did the same thing for other large, repetitive areas - deserts, mountains, oceans, etc. It was almost like a compression algorithm.

Of course, towns, castles and other varied terrain won''t "chunk" as well, but it''s still a great way to make big, incredibly detailed maps that don''t take up tons of disk space.

Share this post


Link to post
Share on other sites
Not to be anal Daishi, but a 1000x1000x16bit image is actually 16000000 bits in size and hence 2000000 bytes in size, which is only about 1.9 MB of memory. Still pretty big though.

And GergisKhan, as already stated, tiles are often rather small. The largest I''ve seen used is 64x64; I prefer 32x32. Maps on the other hand can get huge. For something like a world map, it''s not at all uncommon to have the map be larger than 100 tiles square. If that''s the case, drawing it all to an offscreen buffer would be a 6400 pixel square bitmap in your case. That would be almost 10 MB of bitmap there.

So that''s why the best idea is the one already mentioned: have an array of tile numbers and then draw only the tiles visible on screen. So at 800x600, you''d draw a subsection of... err... 12.5 tiles across by 9.375 tiles down...

Hmm... well, you''ll probably want to split that extra few pixels up so you see equal parts of the fringe rows at the top and bottom and equal parts of the fringe colums at the sides...

-Auron

Share this post


Link to post
Share on other sites
You can find info on tilemaps under articles and resources, You have square (or rectangular), ISO (diamond), and Hex.

ISO and Hex are often used for Civ and strategy type games. Square and rectangular tile are used for top-down and side-scrollers mostly. Although this is not a rule, just an observation.

Another good point to remember of the use of fringe tiles, these are tiles that when layed over other base tiles give the appearance of a terrain transition. They are also called transition tiles for that reason. Eg. a grass tile is overlayed with a south facing sandy beach for a grass to water transition in that direction.


A quick tip on optimization:

Multiple and Integer (no remainder) Divide can be replaced with bitshifting for powers of two. Modulus can be replaced with bitwise and again only for powers of two.


Var % 32 Var & 31 //mod, first 4 bits only
Var * 32 Var << 5 //I hope I've remember which
(int) Var / 32 Var >> 5 //way round these go.



,Jay

[edited by - Jason Zelos on June 28, 2002 4:37:16 PM]

Share this post


Link to post
Share on other sites
A big thank you to all who posted; these tips are like gold.

I''ve talked to the artists and they seem to agree. Since they want to preskew to give the illusion of depth I don''t have to worry about using an isometric map and can simply go to horizontal coordinates.

Auron, your comments are very appreciated: for the reasons specified our viewport is 512 x 512 so as to make the math binary, and thus allow for 64x64 tiles to be drawn and therefore bitshifted as needed for drawing.

Sounds to me like the whole map is loaded in memory during load time, even if it is just 32 bits of info per tile; from there one indexes the tile to be drawn. I wonder whether or not other people have chunked a huge map into "zones" so as to only have say 10MB of map loaded at a time, and what one does about the zone-to-zone crossings.... but perhaps that isn''t something to worry about just yet?

Share this post


Link to post
Share on other sites
I use a map divided down into fairly small 8x8 visual tile chunks. Each tile is 32x32 pixels. So each map chunk is 256x256 pixels, kept that size to make it easy to use as a texture.
Because I have a variable zoom level, I keep anywhere from a 3x3 chunk area to a 6x6 chunk area in memory at a given time.
Now that''s for static data only.
My dynamic data is kept at a smaller resolution, but in larger chunks. So each map chunk is 8x8 visual tiles, but 16x16 walkable tiles, i.e. each 32x32 pixel tile has four places a character can stand on. The dynamic area is divided into 64x64 tile areas, or basically covers four map chunks. Each dynamic area is a linked list of changeable objects in that 64 x 64 tile area. Every time an object moves it may have to leave one dynamic zone and enter another (remove from list, add to list).
My world is 1600x1600 visual tiles, 3200x3200 walkable tiles,
there are 200x200 static chunks and 100x100 dynamic lists
My static map file has all the chunk data. The start of the file contains a list of where each chunk is in the file, the position of each chunk is not constants because I also store a variable linked list of static objects in each chunk, things such as trees, rocks, etc...

anyway, it works well for me.

luck,
-mat























mat williams
Lead Programmer, Designer
Zero Sum Software
www.zero-sum.com

Share this post


Link to post
Share on other sites
quote:
Original post by BadmanX
Another way to do this is if you''re making really huge maps is to use "chunks". Ultima VII did this to great effect - Ultima VII''s map is 24576 pixels by 24576 pixels - over 600 MILLION pixels. Yet the map only takes up just over a meg on disk.



Heh, the Scrolling Game Development Kit can do this without chunking and get it in well under 1 MB (Assuming 32x32-pixel tiles). It does this by having a very low overhead on tiles -- 1 byte per tile.

Share this post


Link to post
Share on other sites

  • Advertisement