#### Archived

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

# Question on Tiling for RPG

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

## 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 on other sites
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 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 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 on other sites
How big were your levels, if I may ask?

##### 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 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 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 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 divisionyOffset = 6 / 4  = 1  // offsets are integers, so this will                      //   truncate to "1" not "1.5"//x1 = xOffset * spriteWidth//y1 = yOffset * spriteHeightx1 = 2 * 64 = 128y1 = 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 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.

1. 1
Rutin
26
2. 2
3. 3
4. 4
5. 5

• 9
• 13
• 19
• 14
• 9
• ### Forum Statistics

• Total Topics
632940
• Total Posts
3009328
• ### Who's Online (See full list)

There are no registered users currently online

×