Title: Building the Hexes

The board is composed of hexes which, in turn, are composed of colored areas. The design of the hex will be considered first (this includes the colored areas) and then the construction of hexes into a board will be considered in the next article.

/|\     / \
/ | \   /   \
/  L  \ /\   /\
|  | |  |  \ /  |
|--| |--|   X   |
|  | |  |  / \  |
\  T  / \/   \/
\ | /   \   /
\|/\   /\ /
|  \ /  |
|   Y   |
|   |   |
\  |  /
\ | /
\|/

As shown above, the Swamp game board is composed of hexes. In an effort to make it easy for Francis to print diagrams of the hexes, the article will use the notation above to show hexes. Each hex is broken down into 3, 4, or 5 colored areas. A hex with 5 colored areas is in the top left of Figure 1. A hex with 4 colored areas is in the top right of Figure 1. A hex with 3 colored areas is in the bottom center of Figure 1. One of the first requirements of the hex design will be to print out hexes in this fashion so that board diagrams can be printed for this article, but also so that users without graphical screens can still play the game.

In addition it will be necessary to show what color is in each region (don't worry, graphics guys, this is C++, so we can modify the classes to handle wonderful graphics when the time comes). The possible colors are brown (B) which represents dirt, green (G) which represents lily pads, and blue (U) which represents water. Placing these colors into Figure 1 at random, yields Figure 2.

/|\     /B\
/G|B\   /   \
/  L  \ /\   /\
|  | |  |  \ /  |
|--|B|--|G  X  U|
|  | |  |  / \  |
\  T  /B\/   \/
\B|G/   \   /
\|/\   /\B/
|  \ /  |
|   Y   |
|   |   |
\  |  /
\B|G/
\|/

Each of the colored sections covers only a portion of a hex. The position of the colored portion of a hex relative to the rest of the hex needs to be established. This information will be necessary so that when hexes are placed together it is possible to determine which colored areas are adjacent to one another. In the current implementation of a hex, a colored area can occupy 1/3 of a side, ½ of a side, an entire side, or the center.

In order to establish where the colored area is located on a hex, it is necessary to know how many possible colored areas exist and what portion of any given side contains that colored area. To allow discussion to continue, consider Figure 3 which shows the colored portion of each hex labeled with a number.

/|\     /1\
/1|2\   /   \
/  L  \ /\   /\
|  | |  |  \ /  |
|--|5|--|4  X  2|
|  | |  |  / \  |
\  T  /1\/   \/
\4|3/   \   /
\|/\   /\3/
|  \ /  |
|   Y   |
|   |   |
\  |  /
\3|2/
\|/

It is also necessary to establish some sort of internal orientation for the hex. This is necessary because the hex can be rotated to any direction when placed into the game board, but should have some internal absolute reckoning for determining the different parts of a hex.

Because of my background in games like Dungeons and Dragons, I default to compass directions. Thus, the sides of a hex would be related to compass directions as shown in Figure 4.

/ \
NW /   \ NE
/     \
|       |
W |   N   | E
|       |
\     /
SW \   / SE
\ /

In addition the external orientation of this hex is denoted in the center of Figure 4. Thus the hex as a whole is pointing North. The corners of the hex are also associated with directions for determining the external orientation. Thus, a hex with the N corner equating to North on the board would have a North external orientation. A hex with the NE corner of the hex pointing toward North on the board would have a NE external orientation.

While this particular choice of nomenclature is not strictly necessary for the implementation, it is going to be very important to be able to talk about the nature of a hex consistently throughout the rest of this article and those to follow. Thus the need to make this nomenclature a requirement.

Now that we have an internal representation for the orientation of a hex, it is possible to discuss the positions of the colored areas. For this implementation of the hex, the division of a hex into colored areas is fixed (this is to say that every 3 color hex has the 3 colors in the same relative positions).

As an example, colored area 2 in a hex with 3 color sections has 1/3 of the NE side, all of the E side, and all of the SE side.

Since the hexes will be side-by-side on the board, it is important to say what color area is found on what portion of a side. Thus, a hex needs to be able to return the colored portion associated with a given portion of a side.

In order for the distribution of colored spaces to be properly maintained, each type of hex must have an established ratio of colors for the colored spaces. Putting the colors in BUG order (Brown, Blue, Green), the ratios are shown in Table 1.

There are other requirements of the hex, but these requirements will be addressed as other objects within the game are spelled out. For now, this is a strong starting point from which to develop the hex.

Now that the requirements for the hex have been completed, it is time to consider how to design a C++ entity that will handle those requirements. An initial observation is that there are three variants on the hex (based on the number of colored sections), so the hex class itself will be built upon by the hex3, hex4, and hex5 classes.

The first step is to identify the requirements which are common to all types of hex, and incorporate those into the Hex parent class. While the listing in Listing 1 actual shows an implementation of the design, it is intended to capture all of the design steps talked about here. The implementation of the class Hex will almost undoubtedly change, but it is worth showing as a listing to allow discussion without excessive graphics.

All hexes will have an external orientation as described in requirements 7 and 8. In Listing 1 this is accomplished with an enumerated type. All hexes need to have a function allowing display as described in requirement 1. In Listing 1 this is shown as the virtual function, draw_hex. All hexes should have a number of colored areas which range between 3 and 5. It seems inelegant to store the number of colored areas directly in the hex. Hmmm…but wait, each hex HAS A set of colored areas. It seems that it is going to be necessary to develop a colored area object at this point.

typedef enum external_orientation { 
  ENorth = 0, ENorthEast, ESouthEast, ESouth,
  ESouthWest, ENorthWest } EXTERNAL_ORIENTATION;
class hex {
private:
  EXTERNAL_ORIENTATION ext_face;
public:
  int virtual draw_hex();
};

The colored areas can only be one of three colors according to requirement 3. This is handled, again, with an enumerated type as shown in Listing 2. Requirement 4 describes that each color needs to be printed using a single letter representation, so a function needs to exist to perform this display, draw_color. Each colored area touches sides (and/or the center) of the hex. Thus, there needs to be a way to denote the sides of the hex and this is given by requirement 6. Listing 2 has another enumerated type to handle the sides of the hex.

Since it is possible that the color only extends along a portion of the side, then the portion of the side along which the color extends needs to be included as well. There are many different ways to handle the storage of this data, but for now it will just be a map as shown in Listing 2, sides_touched. In keeping with requirement 10, it is necessary for the colored area to determine if it is touching a certain portion of a given side, so the function, touching_side(), is included in Listing 2.

The definition of the class is incomplete, but it encompasses the requirements discussed so far and that is the intent. A more complete version of the class will need to be developed at detailed design.

typedef enum hex_color { 
  Brown = 0, Green, Blue }HEX_COLOR;
Typedef enum hex_sides { 
  W_side = 0,
  NW_side,
  NE_side, E_side, SE_side, SW_side,
  Center_side } HEX_SIDES;
class colored_area {
private:
  HEX_COLOR color;
  std::map<HEX_SIDES, float> sides_touched;
public:
  int draw_color();
  boolean touching_side(HEX_SIDES side, float portion);
};

Now that the colored area is defined, it is possible to continue on with the design of the hex.

Since it is necessary for a hex to determine the color associated with a given portion of a given side (requirement 10), then it is necessary to add another function to the hex class. The function, get_color(), shown in Listing 3 handles this requirement.

It is not, however, possible to perform this function without being able to take a side represented in external format and being able to convert it to internal format. This process is handled by externtointern() and the reverse interntoextern(). Both of these functions are shown in Listing 3 as well.

According to Requirement 11, it is necessary for the ratio of colors within a hex to meet a specification. Thus, as colors are assigned to the colored areas within a hex, these colors need to be assigned in a regular way which adheres to the specification. Color assignment within a hex is handled by the function build_colors() which is a virtual function within the hex class. This means that each derived hex needs to implement the function based on the appropriate ratios.

class hex {
private:
  EXTERNAL_ORIENTATION ext_face;
  int color_count;
  HEX_SIDES& externtointern(HEX_SIDES side);
  HEX_SIDES& interntoextern(HEX_SIDES side);
  boolean virtual build_colors();
public:
  int virtual draw_hex(); 
  colored_area& virtual get_color(
      HEX_SIDES extern_side, float portion);
};

At this point it is possible to add the colored area class to the hexes. Since the number of colored areas changes depending on the type of hex, hexes which contain a colored area will have to be derived from the hex class. This allows the appropriate number of colored areas to be explicitly stored. An example of this type of derivation is shown for a three color hex in Listing 4.

class hex3 : public hex {
private:
  colored_area colors[3];
  boolean build_colors();
public:
  int draw_hex();
  colored_area& get_color(HEX_SIDES extern_side, 
              float portion);
};

At this point design (considering only what the hexes need of themselves) has been started. The next step will be a detailed design which fills out the loose definitions given in the listings and generates algorithms for the functions which have been conceived so far. I guess you know what is coming next…

The homework for this issue is to flesh out the loose definitions into full definitions (although not implementations, yet, so don't get too hung up on whether a std::map function has sufficient performance to be used) and generate the algorithms for the functions that have been defined so far. Yes, the implementation of a hex will change (it should be obvious, for example, that there will need to be an indicator for whether a colored area is occupied by an animal), but this will be an iterative development process.

The ratio of colors within a board were determined after extensive play testing of a wide variety of board configurations. There has been no mathematical verification that these ratios represent an optimal ratio, however, this configuration has done quite well within play tests and "feels" right. Anyone want to figure out how to mathematically calculate the ideal (most fair from any starting position) ratio?