Isometric Terrain Tiles:

The tiles of the X game are square, with four sides. However, to enhance the look of the game, the terrain tiles will be shown in isometric view. Isometric view is a 'side view' of the squares, so that the user is appearing to look straight at one of the 'corners' of the square. Also, the view is meant to be roughly 45 degrees to the surface, instead of 90 degrees straight down, so each terrain tile appears as a diamond which is wider than it is high.

The X game will mimic the terrain tiles of the Civilization II game. That is, the view at 45 degrees above the surface makes the squares appear as diamonds, with a width that is twice the height. In a true isometric view, the terrain tiles further from the "user's eye" would seem smaller; however, there is no attempt in this game to make the terrain tiles truly isometric. Instead, all terrain tiles will be the same size, regardless of their distance from the "user's eye".

Terrain Tile Size:

Terrain tiles will be drawn 64 pixels across and 32 pixels high. If the game allows zooming (magnification of the playing surface), then the graphics software will automatically resize the tiles, so only one size of tiles is needed. An example of some tiles appears in Figure 1.

Figure 1 - Terrain Tile Examples

Other Tiles:

Tiles can be used for terrain, or they can be used for other purposes. Terrain features, including resources and improvements (e.g. roads) can be displayed using tiles. Units and other player entities, such as colonies, can also be displayed via tiles. Animations can be displayed using a series of tiles. Non-terrain tiles are not restricted by the 64x32 terrain tile limit.

Tile Transparency and Source Color Keys:

Since the bitmap for a tile is a rectangle, but the tile itself is a diamond shape, there is an issue of how tiles can be drawn next to other tiles. If tiles are butted next to each other, their overlapping rectangles will overwrite a portion of the adjacent tile, no matter in what order they are drawn.

A solution to this problem is to use transparent bits in the tile bitmap. Certain bits are designated as 'transparent', which means that when the tile is copied (a blit operation, in Windows terminology) to the display, these transparent bits will not be copied. On the Windows platform, this is accomplished by designating a source color key. A source color key is a color that will not be transferred during a copy bit operation, thus preserving the colors already on the display.

By convention, a bitmap designates its first bit as the 'source color key'. Any time that color appears in the bitmap, it will not be copied onto the destination display surface. Usually, an unusual color is chosen, to stand out to the graphic designer, but any color NOT used in the actual image can be designated as the source color key.

Tiles and Bitmaps:

In this game, the graphics code is set up so that any number of graphic tiles can exist in a single bitmap file. Also, there may be multiple bitmap files used by the game. Each tile in the bitmap is designated by a numeric code, and its rectangle box in the bitmap.

Note that the bitmap does not need to contain just the tiles. It can contain other images or even text that is not used by the game, as an aid to the graphic designer. A grid can be used to ease the bitmap design, and odd-sized rectangles may be used. The tiles certainly do not have to be uniform in the bitmap file (of course, terrain tiles must still be 64x32 pixels).

Terrain Sequences:

Certain terrain tiles must follow predefined conventions in order to both ease the display programming task, and reduce the overall number of terrain tiles that must be drawn by the graphics designer. To understand the need for these conventions, consider the case of drawing a coastline. When designing the tile for a coastline, the graphics designer must consider the surrounding squares.

Before moving on, here is some terminology and convention. There are 8 surrounding squares to any non-mapboard edge square; by convention, we shall label them Northeast (NE), East (E), Southeast (SE), South (S), Southwest (SW), West (W), Northwest (NW), and North (N). Also by convention, these directions shall be numbered from NE=1 to N=9, going clockwise. The designation 0 will be used to specify 'no direction'; more on that later.

On our example of coastline squares, we must know not only that a particular tile contains coastline, but also the possible coastline contents of the surrounding squares. This knowledge is necessary because the coastline must 'line up' with the coastline of adjacent squares. Any of the surrounding 8 tiles will affect how the coastline must line up for a particular tile. From the degenerate case (no surrounding coastline; a one-square island) to the impossible case (all surrounding coastline; bizarre), the graphic designer must take all cases into consideration.

However, doing a little math will show the daunting task faced the graphic designer who wants to cover all possibilities. The number of combinations for a given coastline tile is 2 to the eighth power (each of the surrounding tiles is either coastline, or not) = 256 combinations. One possibility is to design 256 different squares (actually, 255, minus the impossible case discussed earlier). Although this solution would probably lead to some very nice looking and random coastlines, it would probably be too prohibitive a task.

Terrain Sequences - The 32 Frame Case:

One solution to the 'coastline' problem above is to design 'pieces' of tiles. Instead of a whole tile, each of the tiles in this sequence contains only ¼ of a tile. The tile is broken into 4 tiles, each a smaller diamond (see Figure 2). Drawing a whole tile consists of taking 4 of the ¼ tiles and drawing them in the right position to make a whole tile.

Figure 2 - 32 Frame Case

The ¼ tiles are each cover the possible cases of 3 surrounding sides. For example, the upper ¼ tile covers the cases of coastline/non-coastline of the surrounding NW, N, and NE tiles. Given three variables (e.g. NW, N, NE) with two possibilities (coast/non-coast), there are 8 variations (frames) for each ¼ tile. Since there are 1 ¼ tile positions, we must draw a total of 32 tiles (thus, the name '32 Frame Case'). We have reduced the total number of tiles that need to be drawn by ¼ (32 instead of 256), but increased the drawing tile by 4.

Terrain Sequences - The 16 Frame Case:

Some types of terrain are additions to an existing terrain; for example, mountains, forest, or hills that sit on top of a terrain tile. Regular terrain tiles are used as a 'base', and the additional terrain (e.g. forest) is then drawn on top of that base. We'll call these additional terrain types 'terrain features'.

If there were only one tile that represented one of these terrain feature, regardless of surrounding tiles, the terrain would look artificial. A group of adjacent mountain squares would look like a bunch of individual mountains; hardly a 'natural' looking terrain.

To solve this problem, different terrain feature tiles are drawn depending on the surrounding terrain. To reduce the number of cases, however, only 4 of the 8 surrounding squares are considered (NE, SE, SW, NW). This compromises still leads to some natural looking terrains.

In this case, there are 16 frames; 4 surrounding tiles with two possibilities = 2**4 = 16. In the example of forest squares, the graphic designer must draw 16 different tiles, each with a different assumption as to the surrounding squares and their forest content. For an example, see Figure 3. The top two rows in figure 3 show the connections from the square to the adjacent squares. The bottom two rows show an example (rivers) of terrain tiles that exhibit this connectivity.

Figure 3 - 16 Frame Case

Terrain Sequences - The 9 Frame Case:

Another type of terrain sequence occurs when creating map features such as connecting roads (we'll call these connecting features). As with the 32 Frame Case, there are 256 different sequences for showing a road in a square, and connecting to any of the 8 adjacent squares. However, instead of using 32 frames, we can get away with only 9 frames and still get realistic looking connecting features. We can do this by overlaying multiple tiles from the 9 frame sequence to match the connections needed for that tile. For example, if a square contains a road that connects to the NE and SE directions, the NE and SE tile of the 9 frame sequence are overlapped to get the necessary effect.

The 9 tiles in this sequence consist of the cases: 0) no surrounding connections, 1) NE, 2) E, 3) SE, 4) S, 5) SW, 6) W, 7) NW, 8) N. Note that the numeric sequencing is done so that the game software can refer to the tiles via a number, and even just the first number in a sequence. Two examples (roads and railroads) are shown in Figure 4.

Figure 4 - Two Examples of 9 Frame Cases

Color Palettes:

Almost certainly, the game graphics will exist in more than one bitmap file. Whether these files are palettized, 256 color bitmaps, or non-palettized and converted to 256 colors, there is an absolute requirement for a single unified color palette. It is best to agree upon and create a palette before starting any of the graphics, as it is very difficult to merge two or more palettes after the art is done. Therefore, the first graphics task should be to create a universal 256 color palette, with enough variation in the chosen colors to fit the 'mood' of the game.