Welcome back, thanks for reading the previous installments. Your patience is about to be rewarded.
Recall from Part 1 that, on a two-dimensional hex map, we began depicting layers of hexes stacked as atoms in the face centered cubic crystal structure (https://www.e-education.psu.edu/matse81/node/2133), that is, starting with one layer of close-packed “billiard balls”, we added one layer on top of that, with the “balls” centered where three of the first layer come together, and then a third layer on top of that one with its “balls” centered where neither of the other two layers had their balls centered. Like this.
Fig. 1, which is the Fig. 3 from Part 1. If this or any figure appears too small, your browser may let you right-click to view it in a new tab.
Letting each of these three differently-colored hex grids stand for a differently-centered layer of hexes, note that each 3-d hex-equivalent touches 3 spheres in the layer above it, 3 in the layer below, and 6 in its own layer, for a total of 12 nearest neighbors. A game counter occupying a hex on one layer, if capable of moving one space in any direction, could move that one space by doing one of three things:
1. Move to one of the 6 surrounding hexes in its current layer,
2. Move to one of the 3 hexes touching it in the layer above, or
3. Move to one of the 3 hexes touching it in the layer below.
Recall also that positioning a counter so as to clearly occupy one particular layer, on the figure above, is nigh impossible. But would it be possible to use a single hex grid so that counter positions are clearly seen? To be possible we would need to find 12 “nearest neighbor” hexes, in terms of center-to-center distance. One could pick a representative hex as the center and, drawing larger and larger circles around its center (it is hoped), arrive at a circle that surrounds the centers of exactly 12 nearby hexes. As in Figure 2.
Fig. 2, a successful encirclement of 12 light-green hex centers around one pink hex center.
As I hope Figure 2 plainly shows, this 2-d hex map location (far enough from the edge of course) inherently has 12 neighbors closer to its hex than any others! Given this, may we imagine that 6 of those are in the same horizontal plane as the hex at the center, 3 are in the plane above it and 3 in the plane below it? I think so: the six “adjacent” hexes can be interpreted as showing the alternating above and below locations, while the other six, nominally “2 hexes away” can be interpreted as showing the hexes in the same plane.
Since this may be hard to picture abstractly, let me show an example. You may be familiar with Avalon Hill’s Luftwaffe game, in which opposing players maneuver aircraft units over a map of mid-20th-century Germany.
Fig. 3, small sample of the Luftwaffe game map.
n this game, the map depicts surface locations and the features they contain that are significant to game play – in this case, the airfields used by the defending Luftwaffe planes and other bombardment targets to be either attacked or defended. The attacking aircraft occupy the hexes as they move and fight, representing that they are flying over the ground terrain. Defending aircraft in a hex with an airfield might be flying over it, or they might be on the ground refueling. Players have to use some kind of special code to know which.
Let’s try to make that task easier by representing the play area more fully as a three-layer arrangement. Let the center layer be the “flying above” altitude, where most airplanes can fly, and let’s draw it a sky blue color. Let the layer below that contain the ground installations and targets, as above. The third layer can represent a “high altitude” layer where few airplanes can fly, and likely not for very long when they do, and let’s draw that layer a darker blue. Our map might look something like Figure 4.
Fig. 4, quick and dirty transformation of the map seen in the previous figure.
Combat units in flight would mainly fly in the light blue hexes. The airfields are in hexes with the red flattened asterisks that, I suppose, look like runways. A German unit in such a hex would be understood as landed and refueling. When a German unit takes off, it can move into any one of the three light blue hexes adjacent to its airfield, that is, one of the three above it. It could not move right away to one of the dark blue hexes surrounding it because it would need to ascend through the light blue layer first.
Once aloft, a flying unit in a light blue hex has three different choices for movement:
1. Stay at its cruising altitude and move to one of the six nearest light-blue hexes, or
2. Move “down” to either land or strafe a target on one of the three ground-level hexes touching it, or
3. Move “up” to fly at high altitude, if the planes are capable, to one of the three dark blue hexes touching it. Once there, in turn, its next movement point can take it to either
_ a. one of the six nearest dark blue hexes, or
_ b. one of the three light-blue hexes below it.
I hope that illustration makes sense. Apologies for the ugly graphics work, but I don’t want to keep the readers (both of you) waiting while I take a year or more to make it look slick.
To try to clarify further, I’m adding an example of movement, just as ugly (and perhaps not legal; I’m not sure the 6 and 7 are movement allowances). Two air squadrons start together in the sky above Frankfurt, and end their move together in the sky above Stuttgart. The P-47 group, with more movement points, makes a side trip to strafe the Stuttgart airfield along the way.
Fig. 5, movement of a pair of Allied air squadrons.
I’ll cut it short for this episode. I don’t intend to publish a full 3-D rewrite of Luftwaffe. Try that yourself if so inclined. Another place in WWII to apply this mapping might be in a Pacific-theater naval game, where the surface ship layer would be in the middle, with a submarine layer below it and an aircraft layer above it. Land terrain might interrupt the uniform surface layer, and potentially the others too, with impassible land as well as rocks and reefs in the deep layer and high mountain peaks intruding into the air layer. Consider this another “try it yourself” suggestion.
Next time you’ll see some examples using Sci-fi space travel games, beginning with a modest proposal for improving Lynn Willis’ awesome Godsfire map. Your comments are welcome in the meantime, which I hope won't be too long.
We are space gamers. Read about them, discuss them.
- [+] Dice rolls
Part 3 – Problems in current 3D product offerings. Or: If it's good for 2D, it's good enough for 3D.
21 Dec 2021
Back to the main idea. We are space gamers. Games set in 3-dimensional space demand 3-dimensional maps. Some publishers have tried to meet the demand using the very natural technique of using a hex map to represent multiple layers of 3-dimensional locations. The hex maps used inherently show only 2 of the 3 dimensions, while the “height” dimension is tracked some other way.
Fig. 1, StarForce: Alpha Centauri map. image by Charles Picard
1974: With StarForce: Alpha Centauri, Simulations Publications Inc. (SPI) depicted all the then-known stars within 20 light-years of Earth mapped in three-dimensions because they knew 3D was the only realistic way to fit the stars together correctly: not only did the Sol-to-star distances have to be right, but so did the distances between the respective other stars. The hexes on that map are the usual SPI size, with printed row-column coordinates, each hex representing one light-year across. Each hex implicitly depicts up to 41 layers of altitude, with a non-printed “zulu” coordinate ranging from -20 to +20 ly. The stars pictured on the map do have their zulu printed (the stars don’t move) but the altitudes of moving units are written on paper and in secret (until it might matter), using one of SPI’s “si-move pad” sheets. Since the players had to write it there, might as well make the movement phase simultaneous and use the secrecy as a “fog of war” element.
Let’s say the view we have, on this printed map, is along the Z axis, and the hexes in the zulu=0 layer lie in the X-Y plane. Now imagine viewing the map from the side, along the X axis or Y axis. The fact that hexes are used is no longer apparent – all we’d see are straight lines where the lite-zulu boundaries are: those in the same X-Y plane are bounded by lines going in the Z direction, and those in adjacent planes, lines in the direction perpendicular to our view. Where there are perpendicular lines, we have squares (or rectangles), and therefore corners.
StarForce’s advanced game uses a tactical map for combat that is the same kind of map, but on smaller time and distance scales. The following illustration from the rulebook even shows a view like the one imagined above.
Fig. 2, Combat Cast pattern. Image by Ron K. All attacks are ranged combat, so being adjacent still doesn’t matter.
I think Redmond Simonsen knew there was a potential problem with this kind of map and chose the design to avoid it. Turns are 12 hours so combat over a distance of 1 ly (or √2 ly) on the strategic map is out of the question. He also invited Pythagoras to the party. Movement from one altitude to another involves using the Pythagorean theorem by way of table 7.61.
Fig. 3, True Distance Table (Abbreviated). One axis is the horizontal distance from source hex to destination hex; the other is the vertical difference between the layers containing the source and destination.
In this way, SPI avoided the adjacency issues encountered in Tactics:II by essentially designing around them.
Another game from the 1970s wasn't so clever at avoiding the corner problem, though the graphic design solution is even more attractive at first glance. 1976: Godsfire, designed by Lynn Willis and published by Metagaming Concepts, features a highly innovative way to depict a 3D region – the map is laid out in two of the three dimensions using a standard hex map, but the hexes are large enough to hold a spiral of smaller “hexes” on which a unit can be positioned, thus showing each of the 11 layers that a unit can occupy.
Fig. 4, part of the Godsfire strategic map. Image by Ron K.
The problem here is that adjacency matters for strategic combat. It’s boldly innovative, but whenever playing, one gets the sense that the geometry of the map is not allowing the action to be as realistic as it could be. Each cell has only eight face-adjacent cells (6 on the same level, one directly above and one directly below), but there are 12-other cells adjacent along a 1-dimensional side, effectively a "corner" having center-to-center distance of √2, or 1.414. On top of that, some units can “fire” a distance of 2 cells, and adjacency defined this way yields a firing range shaped more like a soup can than a sphere.
Metagaming and Willis used this method again with Microgame #13, Holy War in which Amtik’s universe is 7 hexes wide and, like Taco Bell’s bestselling burrito, 7 layers deep. Adjacency is not as much a problem in Holy War, since movement is mostly along warp lines (just 1 hex per turn otherwise), and as with StarForce: Alpha Centauri, ranged combat from one cell to another isn't possible.
More recently, the game Attack Vector: Tactical is worthy of mention. I don’t know many details, but from trying to read through the 7-page Bearing Tutorial PDF example, which adastragames.com makes available free, it became clear they are stacking layers of hexagons, using color-coded counters to indicate a ship’s height, and using a Pythagorean-based table to cross-reference horizontal & vertical distance components to obtain actual ship-to-ship distance. The counters in this game represent a single ship, but apparently are 3-d counters that show not only a ship’s position, but its facing (in one of 12 different directions) and to what angle the “top” of the ship has rotated from the vertical relative to the map. I have to admire them for attempting such a complete description of ship-to-ship space combat.
Fig. 5, Image by Jonathan “Gorno” Fashena. I have no explanation.
Given that such games are out there, why are they not played as much as ones that use just two dimensions for space? I think it could just be the difficult-to-articulate intuition described in Part I, where we figured out that 3-dimensional hex-cells should have 12 equally-adjacent neighbors - Six on the same level, three below, and three above - and no corner-adjacency issues. The question is, can we achieve this in practice?
Well the answer is yes, and I can’t wait to describe it to you in part 4.
- [+] Dice rolls
Wandering through the 2D wilderness
Have you ever wondered why so many wargames use hex grids on maps? Using square grids seems like the obvious choice, and is simpler to do. All it takes is to pull out a straightedge and draw horizontal and vertical lines on the map, and you’re done.
For that matter, why do we need a grid at all? The earliest wargames on a “sand table” had no grids. What they did have was units that could move at a certain speed over certain terrain. This translated into a distance each unit could move during its turn. From a given starting point, this means a unit could move to any point on the edge of a circle whose radius is that distance limit, centered on the starting point. Many miniatures games use similar rules today, I believe.
For a commercially-published game, this kind of system is hard to implement. People who buy a board game don’t expect to have to use a ruler or measuring tape every time they move a unit or measure a firing range limit. If they did, in a two-player game with no referee, disagreements about distance measurements are inevitable. Add in a variety of terrain (not all clear, but partly forests, hills and swamps where units can’t move as fast) and the problem just compounds.
Grids to the rescue. Why not try the simplest option, squares? Everyone is familiar with chess and checker boards, where squares work fine. Even actual armed services label their maps with north-south and east-west coordinates. So this is, in fact, what was done – note the game Tactics: II.
Fig. 1, portion of Tactics:II map showing square grid.
This grid choice seen in Figure 1 looks good. It even makes the board look like it might have come from West Point!
This is where the game must depart from the “sand table” experience. Units are not located by planting a flag: they are half-inch square counters, and the map squares are each, conveniently, a half-inch across. A unit in the game occupies one of the squares drawn on the map at any given time. The rules for moving units are correspondingly simple: pieces have a number of movement points representing their speed, which in game terms is the number of squares they can move each turn.
Here is where it gets interesting. On a “sand table”, a unit may be able to move 3 units of distance, perhaps inches, from its starting position, as shown in Figure 2.
Fig. 2, Unit at center may move to any position inside, or along, the outer edge of the black circle.
In terms of this map, though, such a unit has to move all, some or none of its “movement allowance” of 3 by moving from square to square. This might mean each move can go in one of four directions, across an edge of a square.
Fig. 3, Destination squares the unit may arrive at by spending 1, 2, or 3 “movement points.”
Figure 3 is drawn showing the movement distance from the center of one square to the center of each numbered square. Ideally, we’d want the figures drawn by the ring of “2” and “3” squares to resemble the circle seen in Fig. 2. But both rings just look like squares rotated 45°, something I find disappointing.
The “3” ring in particular should by simple geometry have 4 more members (labeled “(3)” in the figure). A single diagonal distance is the square root of two – nearly 1.414, so “2” makes sense for the first diagonal if you round up, but two of them add to nearly 2.818, which is clearly less than 3. The edge-of-square movement rule I’ve assumed puts these four squares in the “4 point” range, so we lose some simulation value unless we can juice the movement rules to account for the Pythagorean theorem. If we do that though, we must make sure our juiced movement rules account for terrain such as roads. These are the red lines on the Tactics: II map, which we’re ignoring for now, but which reduce movement cost when players agree to use them. Add to that complication the fact that movement allowances in Tactics:II are actually no less than 5, and we’d have a lot more juicing to do.
Since movement only across sides proves inadequate, let’s try something else. Instead of just allowing a movement point to get a unit across the edge of a square, let’s allow it to go across a corner too. This gives each move 8 possible directions instead of 4, so – closer to the ideal circle we want, right?
Fig. 4, Movement range “arcs” when diagonals are allowed.
Somehow this doesn’t look much better (Figure 4). The “2” and “3” rings still look like squares, only the squares are larger. More disappointment. But who cares what I think, what does the rule book say? The following figure efficiently shows the developer’s intent.
Fig. 5, Figure from Tactics: II rulebook showing correct movement.
This settles it (Figure 5): Diagonal movement is allowed, per the first step in both CORRECT and INCORRECT cases. Not only that, but squares diagonal from an enemy unit are considered “adjacent” to that unit, requiring the light-colored 7th division to stop at the location shown in the CORRECT portion of the figure and commit to an attack on the dark-colored 17th division. If other light units can move next to it from other angles, the dark unit could thus be attacked from up to eight adjacent squares. Eight EQUALLY ADJACENT squares. Four of those units are further from the center of the dark unit’s square by a factor of 1.414, but could attack at their full strength anyway.
Forget squares, use Hexes in 2D
Try playing this game a few times. If your mind works like mine, you’ll soon get irritated by what I call the “corner problem”, affecting both movement and combat. If only we could use some other geometric grid element on the map instead of squares, one that removes any corner confusion, instead letting adjacent sites only touch along their sides. Fortunately, such a grid element exists, and has come into heavy use in all kinds of simulation games.
Fig. 6, Enter the Hexagon.
As Figure 6 shows, movement in all directions looks effectively equal, not accounting for terrain, and adjacency on sides is the only option. No "corner problem" since no two hexes touch each other at any corner. Who (in the hobby) figured it out, and how? We may never know. It is easily illustrated by nature though. Find a bunch of ball bearings or marbles, anything round, and let them pack as closely as they can together on a flat surface, and you’ll see each one touches six others. Or picture the 15 balls of a billiard table racked in the triangular frame. Each ball not on the edge of the triangle touches exactly 6 other balls.
The bottom line is, a 2-dimensional wargame using a hex grid is effortless to play because you never have to wonder about corners. The “2” and “3” rings even look almost circular, even though one has to admit they’re actually larger hexagons.
You may ask then, what does this meditation on 2-D have to do with 3-D game maps? Are they afflicted with the corner problem? They shouldn’t be if they’re based on layers of hexagons, right?
More about that next time. Don’t get too far ahead of me!
By the way, does anybody know how to make the images look bigger? Several of my illustrations aren't as effective as I expected, though they're a lot bigger than that Darnigame icon. PM me or post in comments if you know how.
- [+] Dice rolls
We are space gamers. We enjoy playing wargames set in outer space.
There have been popular titles, both tactical (Star Fleet Battles and Mayday for example, along with several miniatures-based current titles) and strategic (Lensman, Stellar Conquest, Space Empires 4X). These all share one design shortcut in common: the ships are limited to navigate in a two-dimensional “space”.
We also are (or aspire to be) simulation gamers. Using 2-dimensional maps for 3-dimensional space is unsatisfying because we know better. The games may be fun and engaging – nothing wrong with Star Fleet Battles, or Stellar Conquest, or Warp War – but we know something fundamental is missing. Space is three-dimensional. Games set in space should let ships fly through 3-dimensional maps.
One day (years after studying Materials Science) I realized what might constitute a better kind of map. Just as the hexagon geometry emerges naturally in 2-D when circular objects are grouped together on a surface, its 3-D equivalent emerges naturally also when spheres are used and another layer of spheres is added to the first layer. Likewise when a third layer is added. As it turns out this is the way atoms of many metals stack in face centered cubic crystal structure, of which this page (https://www.e-education.psu.edu/matse81/node/2133) an excellent illustration.
Next, how can we represent this on a playable game surface for a board game? I immediately thought, start with a standard hex grid.
Fig. 1, what a standard hex grid may look like.
Next, I thought, add another color for the next “layer of balls” where they would be if the hexagons represented packed spheres.
Fig. 2. Green is good.
Naturally, yet another color for the next “layer of balls” packed on top of the green layer.
Fig. 3. Third layer of hexes.
A map like this shows all three varieties of stacked hex layers. If a fourth layer is added, it would occur directly over the white-bordered bottom layer, so there’s no need to draw any other hex borders. With this, we can now see how a unit can move from one layer to another. Starting in the bottom (white) layer, it can move to one of the three hexes in the second (green) layer right above it. From there, it can move to one of the three hexes in the third (orange) layer directly above it.
Fig 4 - Start; F. 5 -- Up 1 ; F. 6 - Up 2.
This is seen in figures 4-6 above. From the Figure 6 position, it can clearly continue moving. If it keeps in a straight line, it would move to the white-border hex above the orange hex. This would be in the “fourth layer,” which is 3 layers above the “first layer” thus also white-bordered. If the game volume has more than three layers, without some kind of altitude indicator (perhaps on an off-map record sheet, as in StarForce: Alpha Centauri?), this leads to ambiguity.
Of course in an actual game, there must be more than one counter, controlled by multiple players. When counters are part of a stack, or simply moving in a layer below another player’s unit...
Fig. 7. We have a problem. Or two.
I can see this getting out of hand quickly, especially if someone knocks a table leg or the wind blows and a stack falls over. Sorting out which hexes, and in which layers, the affected units should really be in, suddenly turns a fun space dogfight into a nightmare.
Surely there has to be a way to do this type of map in a playable way, right? This problem left me scratching my head for years. I even wondered, why does this bother me? Aren’t existing 3D solutions in existing games, such as Godsfire and StarForce good enough? I knew they weren’t but couldn’t put my finger on it.
Since then, I've worked through several details, and think I've found something that works. Next in this series: a meditation on a similar situation in two dimensions.
Until next time,
- [+] Dice rolls
This blog is mainly for me to publish articles that I wish I could have submitted to "The Space Gamer" to print. Unfortunately its editorial office closed long ago. There may be current periodicals to present them to (such as Ares Magazine), but the *geek.com community being what it is I think this medium may be the best way to reach my intended audience. Not to mention it lets us leverage hypertext, which is way better than footnotes
There will be at least three categories:
Reviews - descriptions of published games.
Variants - different ways to play with games and their components.
Big Ideas - concepts of general applicability to variants and to future games that may or may not be published.
Comments are welcome, even to this intro post. That should remove the need for a "Letters to the Editor" category.
I only discovered there were blogs within the *geek.com lately, so I don't know if this kind of blog is already being done by someone else. Please let me know if I should "go over there" if it is. If you would like to be a Contributor here, please let me know that too.
Let the adventure begin!
See what I mean?
- [+] Dice rolls