Implementing Iso and Iso Hex Grids on Tiled Systems

From StoneHome


Note: I totally forgot about this, and never got around to finishing it. The old version, which also unfinished is still distinctly less unfinished, can be found here. One of these days I'll get around to finishing this version, which is distinctly less hard on the eyes, but today is not that day.

Image:8x8grid.gif
2D grid

Image:8x8gridiso.gif
Iso 2D grid

Contents

Isometric Grids are one of a variety of grid types available to a game designer. Whereas an isometric grid is a simple grid, and in terms of game rules offers no advantage over a traditional grid, isometric grids are frequently very easy and cheap to implement in console gaming hardware, and give a realistic image of three dimensional depth, which results in a better game experience. I treat them as a seperate topic than traditional grids because the code to get them up and running is significantly different; in terms of game design they have no impact.

This tutorial shows a cheap, simple way to implement a 2d isometric mapping system on hardware with support for square grids of characters (what most console gamers call tiled backgrounds.) This tutorial requires that the host machine support at least two such backgrounds, and that one of the backgrounds has priority over the other. Finally, this tutorial requires that the machine support transparent pixels (masked, alpha, whatever, just so long as we can draw see-through sections) on its background tiles. Most console game systems as far back as the SNES, Gameboy and Genesis fulfill these requirements; this is suitable for DS and Gameboy Advance development, for example. This can also be implemented very quickly with a blitter, so it's pretty good (though less super-double-good) for cellular phones (I have a Brew implementation around here somewhere.) Blitting, however, releases you from the 2:1 aspect ratio (and in fact the regular diamond) and allows other viewpoint distortions, so it can do some interesting stuff.

Making a tiling surface

Image:BasicIsogrid.gif
Simple iso 2D grid

What we want is a tiling surface. A tiling surface is a surface which can be extended ad infinitum in all directions of the local coordinate system. So, a tiling iso surface means we can do iso maps of any size, within machine limits. Once we have that layout, we need to be able to draw an arbitrary chunk of it to the screen, to represent the subset of the master map that's currently on-screen (we'll call it the Map Window.)

Fortunately, these layouts are pretty easy to cook up, once you see a pattern for them. Once that pattern is had, as we see to the right, we need to find a way to render it. For now, I'll assume the relatively common 8x8 grid size, which is appropriate to many console game systems. Because its limited size introduces peculiar and interesting challenges, I'll settle on the Gameboy Advance for a hardware spec. For those which need a quick refresher, that means our screen is 240x160 pixels, and that our tiles are 8x8 pixels, meaning that when aligned the screen is 30x20 tiles. We'll use two backgrounds constructed from tiles much like paint-by-number; one background is "in front of" the other. The data controlling the selection of tiles is stored in "maps", which are (for our current purposes) 32x32 grids of tiles. This leaves two remaining backgrounds for other use, including potential overlays or other semicomplex systems.

The Break-up

Image:BasicIsogridWithTilegrid.gif
2d tile breakup

The general pattern we want to accomplish, again shown to the right, allows us to break the isometric tiles up onto a square grid. A naïve but functional approach would be to call it quits here, and to draw two tiles for each intersection of grid types - grass above and water below, or whatever your tile types are - and just start painting. In certain cases, such as chess, where you only need 32 tiles (with the ability to flip tiles, only eight; with the ability to change palette, only one) to represent a board, that's a good idea.

However, for other game types, like strategy games, that approach has serious downsides. Flipping tiles in landscapes leads to obvious and ugly patternation, and palettes can't change a mountain into grass (using static to represent grass, desert and water is a bad idea; see the pixelling tutorials section for better answers.) Given that you need eight tiles to describe the outer edge of one floor type, then you want to keep the number of combinations you have to represent down. Given that the tiles aren't symmetrical, the number of combinations of tiles is the count of tiles squared, and you can't even eliminate mirrorings. Therefore, if you have just six floor types - say, plains, ocean, hills, mountain, forest and desert - then you need 6*6*8 = 288 tiles to store just the tiles to draw your backgrounds. Given that the GBA has enough space for only 2048 tiles total, and that you have to remove space for your maps from that number, you don't want to see such a big tile requirement. If you have 12 floor types - the previous list plus swamp, river, tundra, deep ocean, jungle and hedgerow - then the tile requirements shoot up to 1,152 tiles, more than half your available space. In short, exponential expansions are your enemy.

On a blitting system, this is all academic; just draw the width spans of each tile, and draw the tiles downwards to ensure correct Z-order.

Combining tiles on the fly

It's this combinatorial expansion described above which leads us to spend a second background. The only reason we need those combined tiles is so that corners fit together; if we were able to draw one corner on top of the other, we could pay for just the tiles rather than every tile combination, reducing this from an exponential growth to a linear growth.

In order to support painting tiles on top of one another cheaply, we rely on the average console system's hardware painting support for tiled layers. Initial simple attempts to draw isometrics often draw on two backgrounds much in the fashion of a checkerboard, with the red squares on one background and the black squares on the other background. For a flat board - a board with no three dimensional appearance - that's good enough. Unfortunately, with this simple system, only one color on the checkerboard may occlude (whichever is on the top of the two backgrounds.)

If we make one simple change, we can get free hardware support for minor occlusion of cells in order to mimic the effect of depth, without using extra hardware or having silly limitations like only every other tile. The impact this has, especially in the breaking of the visual appearance of the grid and borders, should not be underestimated.

Occlusion

Image:SingleOccludedIsoCell.gifImage:SingleOccludedIsoCellSplit.gif
One cell
Image:SingleOccludedIsoGrassCellNoBottom.gifImage:SingleOccludedIsoGrassCellNoBottomSplit.gif
Grass
Image:SingleOccludedIsoWaterCellNoBottom.gifImage:SingleOccludedIsoWaterCellNoBottomSplit.gif
Water
Image:SingleOccludedIsoForestCellNoBottom.gifImage:SingleOccludedIsoForestCellNoBottomSplit.gif
Forest
Examples
Image:BasicIsogridWithTilegridColoredForTopBottom-b.gif
Recolored for breakup
Image:BasicIsogridWithTilegridTopHalvesMarked-b.gif
Top layer
Image:BasicIsogridWithTilegridBottomHalvesMarked-b.gif
Bottom layer
Image:ExampleIsoGridTilesIsolated.gif
Some of the iso tile occlusions

The key to free occlusion is splitting the cells along the horizontal. That way, when you're forced to choose which goes above and which below, the question is between the top and bottom halves of a cell, and the answer is suddenly obvious. In these examples, an artist is able to paint parts of a tile above the left and right corners which will appear above the bottom corners of each of the nearby grid cells, giving the illusion of dimensionality. In fact, if the artist also paints in the bottom halves of the bottom cells, then it's safe to be missing parts of the top corners too, to simulate valleys or other gaps. Alternately, bottom portions of cells can easily be turned towards making isometric height tiles, isometric walls, or other neat toys.

The technique is free, so it's pretty cost-effective. That said, there is one problem: there's no empty space above a cell on the superior background, because the top tiles from the left and right neighbors are taking up that space (as in the diagram "Top layer" to the right.) That's why we have this funny baseball diamond shape, and why we can only extend occlusions above the side corners but not the top. (As you'll later see, the situation with hexagons is much more pleasant.)