:strip_icc()/pic3452580.png)
This diary is an excerpt of a paper released in issue 1 of The Game & Puzzle Design Journal.
1. Introduction
I will present a combinatorial abstract strategy game and its derived puzzles, focusing on how "keeping it simple" revealed unexpected problems and how these were tackled, while finding interesting design techniques along the way.
I describe my design goal first, instead of following an exploratory process, and how the mechanisms, components, and victory condition naturally followed. This process shows how design constraints can lead to the discovery of interesting mathematical properties and new combinations of components and mechanisms. Finally, the game is transformed into a puzzle, which turns out to be as interesting as the game itself.
:strip_icc()/pic1415761.jpg)
Figure 1: The Heptalion set
2. History
I designed Heptalion in 2011 and published it through my company nestorgames in 2012. The published set is shown in Figure 1 above. A version for Android smartphones was released in 2014. A short description of the game:
Heptalion: Players draw an equal number of tiles from the bag at random, then place them face up for all to see. Players take turns placing one of their tiles on the board, face down, to cover a pair of symbols that match the two symbols on the tile. The last player to move wins.
Heptalion has its roots in 2010, when another of my games — Hippos & Crocodiles — was rivaling the sales of my most successful game, Adaptoid. Hippos & Crocodiles (Figure 2) is very simple. Players take turns placing one of their animal-shaped tiles, either a hippopotamus or a crocodile, onto the board until one player cannot make a legal move, thereby losing the game.
Realizing that the complexity of a game is not correlated with its market success, I decided to design another game that was even simpler than Hippos & Crocodiles to see whether its success could be reproduced. This time, though, I wanted to focus on the parents, them being the ones who buy the game and have to play with their kids, but have no time to play it themselves. I wanted to create a game that was easy and quick to learn and play, mistake-proof, short and replayable.
With these objectives in mind, the first step was to create a list of design goals, consisting of a set of obvious design problems and potential solutions.
:strip_icc()/pic527944.jpg)
Figure 2: Hippos & Crocodiles
3. Design Problems
The following list describes the design problems I faced when creating Heptalion and their solutions:
1. Problem: Steep learning curve and resistance to change on behalf of players.
Solution: Use an already existing and well-known game component (e.g., cards, pawns, dice, etc.) so that players feel comfortable with it.
2. Problem: Too many rules force players to check the rulebook frequently and also may lead to misinterpretation and conflict.
Solution: Move the rules to the components, in a "poka-yoke" approach, so that mistakes and misinterpretations are almost impossible.
Poka-yoke is a Japanese term that means "mistake-proofing", and it refers to any mechanism in a manufacturing process that helps an equipment operator avoid (yokeru) mistakes (poka) by drawing attention to human errors as they occur. More broadly, the term can refer to any behavior-shaping constraint designed into a process to prevent incorrect operation by the user.
3. Problem: Game length may scare young players and parents.
Solution: Keep the number of turns low (around 10–15), as well as the duration of each turn, to avoid "analysis paralysis".
4. Problem: Be able to accommodate several players.
Solution: Make it multiplayer without extending the duration of the game through a finite number of pieces shared among all players.
5. Problem: The set should be affordable.
Solution: Use a small and cheap to manufacture set of components.
6. Problem: Allow a high degree of replayability, so the players get value for money.
Solution: Random set-up based on a combinatorial distribution of the components.
7. Problem: Games that are easy to make at home lose sales.
Solution: Use components that are not usually found at home.
Note that item #7 is not a design problem as much as a business problem. However, I have to take such considerations into account when designing since I am also the publisher. Many amateur game designers seem to ignore such issues when designing their own games, even though they can be very important to publishers.
4. Problem-Solving Process
This section describes the problem solving process used to tackle the problems listed above. The key to most of these was to find a magical game component that:
* is widely known (solves problem #1),
* does not have many parts (solves problem #5),
* is sufficiently complex (solves problem #6), and
* is hard to replicate if customized (solves problem #7).
A standard dominoes set satisfies these criteria nicely. A set of standard dominoes has 28 tiles, showing all possible pairs of numbers from 0 to 6. Although a larger set could have been used for my game, 28 tiles proved to be sufficient. One tile per turn gives each player 14 turns in a two-player game, which solves problem #3.
For a four-player game, each player has only seven turns. This is a bit small, but the game nature encourages players to play several games in a row, which is a desirable feature in games, showing that the game is appealing and replayable.
Thus, problem #4 was partially solved. In order to fully solve it, I released an expansion pack called Octalion that uses a larger board and increases the number of tiles to 36 (so that each player has nine turns in a four-player game).
Octalion also solves problem #7 as a set of 36 dominoes is non-standard and thus difficult to find. The design hurdles seemed to be dropping quickly so far, except for problem #2; trying to solve it was like trying to open a matryoshka or babushka doll, in which solving each layer just revealed further problems to the solved.
I then focused on the victory condition, which for me is the meaning of a game and the most important part of the rules. The components are the tools that the players use to achieve the goal.
I decided to use the same victory condition as Hippos & Crocodiles and many other successful tile placement games: The last player able to make a move wins. This is a very powerful victory condition as it does not need to be checked every turn (as with a checkmate in chess) and avoids the need for scoring; the game simply ends when it is not possible to play anymore.
It made sense that players would start with the tiles split amongst themselves, which is simpler than players needing to draw a tile each turn or keep track of the number of tiles in hand, etc.
Players would take turns placing a tile on the board only where it could fit (which feels natural), but they must be forced to choose from several places to fit them (as otherwise the game would be boring).
The ideal board would fit all tiles and allow each tile to be placed in several different places. Each move should eliminate some other potential moves so that the number of legal moves reduces and the game converges to a result that is not trivially predictable. Moreover, the shape of the board must be roughly rectangular to fit an A4 sheet as this is the size of the boards that I print.
A 28-tile set of dominoes contains 56 half-tiles (i.e., squares) in total, so I first tried using a 7x8 grid of 56 squares for the game board. This proportion roughly matched the shape of an A4 sheet, with some room for the game title, but there was a problem.
A 7x8 grid has the desired 56 squares, but it has (6x8) + (7x7) = 97 pairs of orthogonally adjacent squares, as shown in Figure 3. These represent the places that double-square domino tiles can be placed, but in order to have the same number of available placements for each tile (for a balanced distribution), this total should be a multiple of 28.
:strip_icc()/pic3452376.png)
Figure 3: The 97 adjacent pairs on the 7x8 grid
The nearest multiples of 28 are 3x28 = 84 and 4x28 = 112. Since 7x8 allows the maximum number of paired squares, it is impossible to reach 112 with 56 squares, hence 84 pairs became the target number. The problem can now be stated as:
Find an orthogonal grid shape with 56 squares and exactly 84 adjacent pairs.
Having no idea what shape such a grid might take, I started with a 7x8 rectangle and began moving squares around. Moving a border square to another place on the perimeter (except corners) reduces the number of pairs by two (-3 for the removal and +1 for the placement), as shown in Figure 4.
:strip_icc()/pic3452384.png)
Figure 4: Moving a border square to a side subtracts two pairs overall
But it's not possible to reach an even number by repeatedly subtracting 2 from an odd number, so I then tried the corners. Moving a corner square to another place on the perimeter (except corners) reduces the number of pairs by one (-2 for the removal and +1 for the placement), as shown in Figure 5.
:strip_icc()/pic3452385.png)
Figure 5: Moving a corner square to a side subtracts one pair overall
This meant that 13 squares would have to be moved to reach the target number of 84 pairs — but there was a faster and more flexible way; moving inner squares to the perimeter reduces the number of pairs by three with each movement (-4 for the removal and +1 for the placement), as shown in Figure 6.
:strip_icc()/pic3452386.png)
Figure 6: Moving an inner square to a side subtracts three pairs overall
Furthermore, removing a square adjacent to a hole and moving it to the perimeter reduces the number of pairs by two (-3 for the removal and +1 for the placement), as shown in Figure 7, which is conveniently an even number.
:strip_icc()/pic3452389.png)
Figure 7: Moving a square adjacent to a hole to a side subtracts two pairs overall
Playing around with these square movements for a few days, I came across the diamond shape shown in Figure 8. This shape was perfect; it was symmetrical, appealing, had 84 pairs and 56 squares, and worked well within an A4 page ratio.
:strip_icc()/pic3452390.png)
Figure 8: The diamond
However, finding the right shape was only part of the solution, and the actual distribution of symbols within this shape posed a new problem:
Find a distribution of numbers 0–6 within the diamond shape such that each occurs exactly eight times, and each pair of numbers (28 in total) occurs exactly three times (3 x 28 = 84).
This new problem was a hard one for a nonprogrammer, and brute force enumeration would be too time consuming, so it had to be attacked from a different perspective. I looked for simpler patterns that might occur in a valid distribution, hoping that this easier task would allow me to build the board.
The breakthrough came when I considered the A-A tiles that contain matching numbers: 0–0, 1–1, 2–2, etc. We want each A-A tile to have three possible placements, the same as any other tile, and it turns out that this can be achieved efficiently if each number occurs in one of the patterns shown in Figure 9.
:strip_icc()/pic3452391.png)
Figure 9: Tetrominoes with three adjacent pairs
These shapes, called tetrominoes, are used in many games and puzzles, such as the well-known LITS puzzle from Japanese publisher Nikoli. Note that this set includes only tetrominoes with exactly three adjacent cell pairings and excludes the fifth 2x2 tetromino with four adjacent cell pairings; the fewer the better in this case.
The trick was to then place seven of these tetromino patterns inside the diamond grid, then number the corresponding grid cells accordingly.
:strip_icc()/pic3452392.png)
Figure 10: A solution for the diamond board
After a few hours' work with the help of a spreadsheet, I found the final distribution shown in Figure 10. The numbers were replaced by colored symbols (Figure 11), and after playtesting, the game was ready for release. It has since proven popular with players and does not show any obvious first or second player advantage.
:strip_icc()/pic3452398.png)
Figure 11: The final board
5. Other Solutions
Shortly after releasing Heptalion, Mark Tilford and Grant Fikes used computer analysis to find other valid distributions for the diamond shape as well as other shapes with valid distributions. Two of these, shown in Figures 12 and 13, have since been released as expansions for the game.
:strip_icc()/pic3452565.png)
Figure 12: Fikes' board
:strip_icc()/pic3452568.png)
Figure 13: Tilford's board (with the "n" representing nestorgames)
6. Android Puzzle App
A few months later, Kris J. Wolff (designer of Pilus) proposed developing an Android version of Heptalion. Kris had previously developed an Android app for my game RED, but that app lacked something important: a set of puzzles.
We therefore included some puzzles in the Heptalion app. The rules for the Heptalion puzzle emerged naturally from the board game. The aim is to place a subset of the Heptalion pieces, according to the game's rules, to exactly cover a predetermined board shape. This is different from the board game as all pieces in the solvers' hand must be placed in order to complete each challenge.
Figure 14: A medium difficulty Android puzzle
The app creates challenges involving 3-19 randomly placed pieces such that each challenge has a unique solution. Since not all pieces are included in a challenge, there are usually some unplayable adjacent board spaces, and this adds a new twist in the deduction process for the player. The algorithm for creating challenges is described in Appendix A.
The difficulty of each challenge is estimated as the product of the number of ways each piece can be placed in the initial challenge. For example, the challenge shown in Figure 14 has a difficulty score of 983,040, which makes it of medium difficulty.
Heptalion puzzles are designed with some pieces being removed in order to have unique solutions and increase their degree of deducibility.
7. Conclusion
In finding a board of the appropriate shape and size for a certain set of tiles, acting under a certain set of constraints, I had to solve a number of design problems in order to achieve the game that I wanted. This diary describes the design steps that led to my game Heptalion and the associated Android puzzle app.
I believe that the techniques discovered along the way — the application of poka-yoke to board game design; the use of maths to tweak the board shape and define the exact subproblems to be solved, and so on — will help with the development of future games.
Néstor Romeral Andrés
Appendix A: Puzzle Generation
This Appendix describes Kris J. Wolff's algorithm for creating unique Heptalion puzzles in his Android app for the game.
1. Start with an imaginary 11x11 board.
2. Choose between 3 and 19 pieces to use. The most interesting and difficult puzzles seem to be those with 17 out of the 28 available.
3. Place a piece in a random location.
4. Place each other piece in a random location, such that its two squares each touch at least two squares on pieces already placed. This avoids single square protrusions which would have trivial instantiations.
5. Run through all possible ways to place the chosen pieces on the board. If more than one solution exists, discard and restart.
6. Check that each piece has more than one valid placement (as otherwise its placement is trivial). If any pieces have only one valid placement, then discard and restart.
7. Each level is given a "difficulty" rating, which is calculated as follows: Start with difficulty=1, then for each piece multiply the difficulty by its number of valid placements.
Special thanks to Cameron Browne and Russ Williams for revisions.
:strip_icc()/pic3491804.jpg)
/pic3157131.jpg)
:strip_icc()/pic3490430.png)
/pic1094805.jpg)
:strip_icc()/pic3474863.jpg)
