The following article, written by VPJ Arponen, originally appeared on The Players’ Aid blog earlier this week. To make sure that all of our GMT customers get to see this excellent article, we’re including it here in InsideGMT as well, with the permission and agreement of our friends at The Player’s Aid. We hope you enjoy the article!

---

A while ago Grant asked me to write about “bot” design for The Players’ Aid Blog and I eagerly jumped at the chance. Over the past two years or so, I’ve had the pleasure of spending some time designing solitaire play systems for a number of board games.

I began with the variant “bots” for the COIN Series game Volume III, A Distant Plain by Brian Train and Volko Ruhnke. These were published in early 2017 in C3i Magazine Nr. 30 produced by RBM Studio and Rodger B. MacGowan. Next came the FLN “bot” for the COIN Series Volume VII Colonial Twilight by Brian Train. This game is due to hit the shelves in the Summer of 2017. My latest design work is for the Axis “bot” for Hitler’s Reich by Mark McLaughlin. All three games are GMT Games publications.

As I began to write this guest spot, the text sprawled so much that it was decided to split it in two volumes. In this first volume, I want to discuss a number of topics pertaining to the COIN “bot” design. In the second, forthcoming installment, we’ll talk about the Hitler’s Reich “bot”.

Designing a COIN “Bot”

For me, the design work begins with getting to know the base game. When you get to know the game, particular do’s and don’ts begin to emerge for each faction.

For me this is a particularly exciting bit of the design process. I feel I’m deciphering the complexity that the designer has built into the design – and each COIN game works differently. The factions tend to interact on so many levels, some more overt and explicit than others, and all factions interact at once, making the overall picture really quite complex.

To give an example, in A Distant Plain, I spent a lot of time trying to get the Coalition “bot” behavior right with regard to the split personality that that faction has in the game. On the one hand, the Coalition has to set up, build, and maintain support – a task where it is hindered at least as much by the nominal ally, the Government, as by the insurgent factions. In regards to these goals, many crucial things can happens during the Coalition Air Lift and Surge special activities to set up and maintain support. It seems fair to say Surge is the key special activity in the Coalition’s palette.

On the other hand, sometimes the Coalition just has got to conduct some old fashioned Sweeps, Assaults and Air Strikes as well. Some added challenges come from the fact that the Coalition “bot” needs to pay special attention to the factions controlled by the player or players – after all, the players are the most intelligent and flexible, and therefore the most dangerous enemies. As a result, if you play against the Coalition “bot”, you might notice how the bot behaves quite differently depending on which faction or factions are player-controlled. There is quite a bit of customization like that needed for the Coalition “bot”, which to me was a moment of exciting discovery and development as well as a great balancing act.

Next in the design process, once I’ve established a basic idea of how a given faction might go about winning the game, I begin the painstaking process of nailing it down in the format provided by the flow chart that the solitaire player uses to process the non-player “bot” decisions. In a COIN game, often the factions must go through multi-turn processes to achieve particular objectives. Such multi-turn processes get implicitly built into the flowchart: a March action now can be used to set up the placement of a base in the course of a Rally at some later time in the game, to give a simple example.

From the design perspective, all this is a learning-by-doing process essentially, and only testing will tell you what ultimately works. Testing plays an important role in hopefully revealing some of the ways in which the player might be able to manipulate a “bot” faction. In the course of drawing up the FLN “bot” for the upcoming Colonial Twilight, I had some great fun with my gaming buddy and tireless playtester Matthias. He kept leading the poor FLN “bot” into all sorts of dark places and we had to walk it back out again and revise the flowchart.

As a result, however, the FLN “bot” grew pretty darn competent, especially in the short scenario upon which our testing efforts focused. We look forward to getting to hear the player’s reactions once the game gets published.

A further and perhaps a more salient aspect of “bot” design concerns sprinkling the “bot” behaviour with just the right amount of controlled randomness. The idea is to avoid designing the “bots” such that they always proceed along the same lines of action, always target the same set of spaces, and so on. Therefore, sometimes the specifications regarding space selection is left intentionally open to give the “bot” some room to expand into unanticipated yet still hopefully competent directions. An example of controlled randomness might be to give the “bot” the instruction to select randomly among spaces with two or more population as opposed to stipulating that the “bot” ought to select the highest available population spaces. A minor-looking tweak like that can make a big difference in having different games pan out in different ways.

What you’ve read about above are some thoughts on what the design process looks like from my perspective. I’ve had the good fortune of getting to peer over the shoulder as, recently, the master builder himself, Volko Ruhnke, has been putting together the bots for the next game in the COIN Series, Pendragon by Marc Gouyon-Rety. I’ve learned from Volko, as well as from the “botman” himself Örjan Ariander, and am learning more with each project I work on.

Do the “Bots” Have to Be So Complex?!

This one gets asked a lot about the COIN “bots” in particular, so I thought I’d write about my view on this issue.

Some years ago, when I was having my first forays into the COIN Series, I was absolutely ecstatic to discover that each game in the series came with a full blown solitaire system allowing a gaming experience that pretty damn closely resembles the base game among humans.

How do the COIN “bots” manage that? It’s because these “bots” are a little bit intelligent.

In a COIN “bot”, the intelligence comes from the fact that the “bot”, so to speak, monitors the board state and makes decisions based on that monitoring. If you look at a COIN “bot” flowchart, you’ll see it’s structured around a set of questions – something like, does a given faction have so many pieces available, or could a given action, taken right now, produce such and such a result. The questions, therefore, as it were, monitor what are supposed to be the essential features of the board state in what comes to the “bot” action selection. Once a particular action gets selected, a host of “if something, then something” type of clauses further refine the execution of the chosen action.

The result is a “bot” that with a few rules exceptions, plays the game like a human player would – only not always quite as creatively and flexibly as a human player.

In some ways, most COIN games resemble chess: you’ve got to be thinking a few turns ahead and strategically place your pieces such that you enable some critical actions of your own while you prevent your enemies from undertaking actions that damage you. It is my view that the “bots” only manage to provide the superb solitaire experience that they do, because they are intelligent enough to deal with this chess-like quality of the game. Without such an ability, the solo play would not be the same.

Intelligence, by the way, is not a given in solitaire design. In fact, many if not most of the more popular solitaire engines are not intelligent, but rather based on something you might call calculated randomness. Games like D-Day at Omaha Beach by John Butterfield (Decision Games), or Mound Builders by Ben Madison and Wes Erni (Victory Point Games), involve a deck of enemy action cards: you reveal a random card and execute the instructions printed on it.

The solitaire challenge here builds upon the deck being designed such that, even with the random order that the cards come out in, the human player has more than his or her hands full trying to contain what the cards throw the player’s way. Similarly, Joel Toppen’s excellent Navajo Wars and Comancheria (GMT Games) build upon an enemy action display that churns out random-ish actions at the player.

The solitaire systems in many popular so-called “Euro-games” build upon randomly reducing the options available to the human player. In a game like that, the solitaire system randomly removes tiles, cards or other tokens from the market place from which the player is about to purchase his or her next asset. Similarly, the system randomly builds stuff in the spaces in which the player could next attempt to build, and so on.

I do not wish to pretend that running a COIN “bot” is a breeze. Frankly, it is not, especially if your point of comparison is a solitaire “Euro-game”. Which takes me to my next topic.

Understanding “Bot”

If you like as an innovation, in my “bot” design work, I’ve sought to alleviate the “processing stress” placed upon the human player by devising what is intended as a more straightforward and logically more explicit notation for laying out the flowcharts. As a fan of the series, I had had my own struggles with the interpretation and processing of the flowcharts.

As the first step, my notation distinguishes two different types of priority already on the level of formatting the flowcharts: sequential and nested or tie breaker clauses. In the previously published flowcharts, oftentimes, this distinction is implicit and has required interpretation by the player to make it explicit.

The sequential priorities are numbered (1., 2., and so on) and are to be executed to their fullest possible extent before you move on to the next sequential priority. A simple example might be:

1. Rally at all friendly Bases
2. Rally in all spaces with already existing own Guerrillas

The nested or tie breaker priorities, by contrast, are ordered by letters (a, b, c, and so on) and work just as the name says: they break ties within the sequential priorities. An example would be:

1. Rally at all friendly Bases:

(a) at highest Population

(b) where least of Guerrillas

Here the tie breaker clauses (a, b) offer further criteria for prioritizing some Rally spaces over others: from among all spaces with friendly Bases you select first those with the highest population, and if further refinement of the selection resolution is needed, you select spaces with the least Guerrillas. If desired, the tie breakers can quickly, and at a relatively low printing space cost (always a problem on these 1-pager flowcharts) introduce a lot of depth to the design.

I’ve found that laying out the flowcharts like that speeds up solo play by minimizing the need to interpret what the flowchart is trying to say. I’ve also found that my own “bot” design process becomes more structured when I think about the doings of the “bots” in terms of these two categories of statements. From what I’ve seen in terms of feedback on the new flowchart formatting, the gamers have also received this innovation well.

In the next volume in this series, we’ll take a look at the Hitler’s Reich “bot” design.

---

Articles in this Series: Part 1  Part 2

---

Vesa “Vez” Arponen is a Finn currently residing and working in academic research in Germany. Whenever he is not playing a historical consim with his group, he is an avid solo gamer and has contributed a few solitaire system designs to the hobby, most recently to Hitler’s Reich and the COIN Series Vol. VII Colonial Twilight.