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.

Figure 13.1. A hexgrid.


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[*] IntoBlocks LOS ThroughPrevents MotionImpedes MotionLabel
0000Open ground.
0001Rough ground.
0010Lake.
0011Nonsense value.
0100Nonsense value.
0101Hill.
0110Mesa? I never used this.
0111Nonsense value.
1000Depression (a “hole”).
1001Rough ground depression.
1010A lake in a hole? Useless.
1011Nonsense value.
1100Really high grass?
1101Trees.
1110Impassable forest.
1111Nonsense 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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.14.150.169