Map

The first sub-problem was the map representation. This problem had two components: terrain representation and hexgrid computation. A hexgrid is commonly used in wargames because it allows more precise directional alignment of units and doesn't have the problems with corners that a rectgrid (such as is used on a chessboard) imposes. A hexgrid looks like what's shown in Figure 13.1.

13.1. A hexgrid.

graphics/13fig01.gif

Each hex in the hexgrid can contain terrain of some type: trees, hills, depressions, rivers, lakes, open ground, etc. After much wasted effort trying to computationally define all these terrain elements, I realized my error, an error that is fundamental to all game design: I was thinking in terms of data, not process. That is, I was so busy thinking about what terrain is that I failed to think in terms of what it does. If we think about terrain in terms of its operational properties, it really is quite simple. All terrain has just four basic properties:

  • It can block the line of sight into its hex.

  • It can block the line of sight through its hex.

  • It can prevent motion into its hex.

  • It can impede motion into its hex.

I treated all four properties as binary, so with just four bits of information, I could record everything I needed to know about a hex. Thus, what I was previously calling a plain hex is really just a hex whose terrain value is, in binary terms, just 0000. It doesn't block the line of sight, prevent motion, or impede motion. A lake hex has a binary value of 0010; it can prevent motion into its hex, but otherwise is just like a plain hex. Trees are a little trickier: They have a binary terrain value of 1101, because they block the line of sight both into and through the hex, as well as impeding (but not preventing motion).

You might wonder why there's a difference between blocking the line of sight into a hex and blocking the line of sight through a hex. The difference becomes apparent when you consider a hill hex as compared with a tree hex. A hill hex has a binary terrain value of 0101: it blocks the line of sight through its hex, but not into it, and it impedes but does not prevent motion into it. Imagine a tank climbing onto a hill hex. It can climb the hill, but it slows down doing so, because the hill is steep. More important, once on top of the hill, it can see far and can also be seen from afar. The line of sight can be traced into the hill hex. However, if the tank is behind the hill, then it cannot be seen; the hill blocks the line of sight through the hex (but not into it!).

Now, imagine the same tank in a tree hex. The trees block the line of sight through the hex just like the hill blocks the line of sight. A tank hiding behind a tree hex cannot be seen. But the trees also block the line of sight into the tree hex; a tank hiding in the trees cannot be seen. What's important here is that the tank can see out of the trees but cannot be seen. That's tactically valuable, which is why so many tanks spend so much time lurking around in the trees.

This system thus permits sixteen different types of terrain, some of which are nonsensical:

Blocks LOS[*] Into

Blocks LOS Through

Prevents Motion

Impedes Motion

Label

0

0

0

0

Open ground.

0

0

0

1

Rough ground.

0

0

1

0

Lake.

0

0

1

1

Nonsense value.

0

1

0

0

Nonsense value.

0

1

0

1

Hill.

0

1

1

0

Mesa? I never used this.

0

1

1

1

Nonsense value.

1

0

0

0

Depression (a "hole").

1

0

0

1

Rough ground depression.

1

0

1

0

A lake in a hole? Useless.

1

0

1

1

Nonsense value.

1

1

0

0

Really high grass?

1

1

0

1

Trees.

1

1

1

0

Impassable forest.

1

1

1

1

Nonsense value.

[*] LOS = Line of sight

You will note that five of these values are nonsense values and four more are silly or useless. Thus, more than half of my values are wasted; I could have gotten away with using only three bits of data. However, deciphering all these values would have been more trouble than it was worth; I stuck with this simple scheme because it was easy to compute with.



Chris Crawford on Game Design
Chris Crawford on Game Design
ISBN: 0131460994
EAN: 2147483647
Year: 2006
Pages: 248

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net