The Solo Gamer's Bag of Tricks

On of my concerns with this blog is that I use specific rules or game systems to show concrete examples of how to using solo gaming mechanics that other authors allude to, but that those specific systems may not be of interest to the reader, and thus they skip the article. Or worse, they are interested in the subject, but because my example is so specific to a game system and its internal mechanics, they get little from it.

My first series of articles were about card (hand) management systems and rulesbases, and I used Memoir '44 as the game system to play out the example. My second series of articles were centered around Two Hour Wargames' reaction system (which many people say is a solo gaming system in and of itself) and later Mythic for decision making that the reaction system did not cover. I used Rally Round the King as the game system to play out the example. Finally we come to the current series on using finite state machines to program an opponent. For that I not only used Saga, but a fan (me) made variant using Mesoamericans. Talk about obscure!

My plea to readers last time was to let me know if, for all my desire to make solo ideas "concrete", the rules I choose to use get in the way of understanding how to apply the concepts to your rules of choice, how useful can it really be?

Well, the few comments I received (actually quite good, considering the average number of comments in most articles) indicated that, for at least the last example, it was not as bad as I thought:

I don't play Saga and wouldn't play Aztecs, etc., even if I did, but I still find your exercise with actual examples to be interesting and illuminating. Whether I will try anything like this myself is doubtful. – Fitz-Badger

Like Fitz-Badger I'm not sure if I will play saga but I like the exercise. – Sean

Although not interested in Saga, it *is* interesting reading the processes you go through developing and testing the FSM. – Shaun Travers

Which brings us to the comment and response that led to this post¹:

Me: The amount of work involved [in writing a programmed opponent using FSM] has made me think about solo systems, and whether or not something this complex is usable. I still think it is; it just cannot be your "I feel like a game right now" solo system. That means that you need a bag of tricks and you pull out the right trick for the situation.

Shaun Travers: Are you saying that the bag of tricks is for different rules, or that you don't think a solo system can be developed for a single rule system without a "bag of tricks" (or framework(s) for want of a different term) that is required to enable to play "programmable" solo?

I think that some tricks are rule-specific. For example, a method for hiding the cards available to your non-player opponent from you, the player, would not apply to a game system that does not use cards, or does use cards but does not require you to manage a hand. But other tricks are generic.

The most basic solo gaming mechanic is the one that helps the gamer decide how to make the most basic of decisions:

• How do I decide which unit to move? (Important for games in which not all units can move each turn.)
• How do I decide in what order units will act? (Important for games in which timing, reactions, and combinations play a part.)
• How do I decide if the unit will fire or move? (Important in action point games where doing one action precludes doing the other, or places modifiers on either action.)
• How do I decide if a unit will attack or defend? etc.

It is these decision making mechanisms – the ones that tell the player what to do in the non-player's stead – that I feel are the most important, and generally the hardest to implement well. So when I say "pull out the right trick for the situation", I am really referring to what decision making process will you use? Here are a few that have been discussed in the blog so far:

• Just Do It: Play each side to the best of your ability.
• Logic-Based, Chance Confirmed: Use a logical thought process to decide what is the most likely course of action, assign a probability to that decision, then use some chance element (e.g. dice, cards, etc.) to verify that the indicated choice was selected. Failure means repeating the process with the second most logical choice, and so on. This is exemplified by using Mythic as your decision-making tool.
• Reaction-Based: Develop charts that define decision points (e.g. enemy entered missile range, enemy entered charge range, enemy on flank, etc.) and use a chance element to determine which pre-defined choice is made to react to the event.
• Rule-Based: Develop a rules database of events that specify the exact action to be taken. Note that this can lead to a large number of conditions and exceptions, resulting in an IF-THEN-ELSE structure in order to get a more realistic response.
• State-Based: This is a variation on the Rules-Based method and is used for when complex actions, or a series of related actions, must occur. The IF-THEN-ELSE structure of the rules exists, but is generally better structured as changes in state allow rules to triggered when exiting states, entering new states, and when testing for triggers within a state.

What the above list also reflects is the level of complexity required for each method. Reading from top to bottom you can easily see that more preparation work is required to execute that method. Often, it also reflects the increasing amount of time taken by the method to play out the game. If I feel like a game and I have an hour to kill, I will probably use the "Just Do It" method, unless I have something already setup and the method won't add too much time to the amount of time the game normally takes to play.

A stated goal of mine has always been to develop a programmed opponent, such that it was rich enough – and understandable – that I could send the "program" to someone else and they could use it to play a solo game. If a framework were developed on how to "encode" a programmed opponent, then each of us could create our own opponents and literally trade them on an exchange. As some of us would write a more cautious and defensive opponent, while others would naturally write a more bold and aggressive one, we could have a variety of different personalities to fight that are not "like us".

Of course, to get to that point, you have to define a mechanic for decision making that is rich enough to make the program enjoyable (and hopefully challenging), but also make it simple enough that most people interested in this concept would be willing to write their own. That means it cannot take a lot of work. Solo gamers would rather be gaming and painting than planning.

I also should probably revisit FSM's viv a vis RRtK. – Sean

And everytime you post, I think about doing my own FSM for ancient rules like RRTK. – Shaun Travers

Hmmmm… There seems to be a trend here.

Shaun made one more comment I would like to address:

Since your last post, I have been thinking more on orders. Saga uses the dice for orders, but games like RRTK have implicit rather than explicit orders. But if you use the Army tactics, you are implying orders. Eg left flank attack implies Attack orders for left flank and support orders for centre and likely defend orders for right flank. WRG 6th had a good description of simple orders so need to look them up. With orders and unit type, I think I can generate FSMs for units. – Shaun Travers

Saga uses dice for activations and "buffs". The dice still do not tell you what to do when the unit is activated. It is simply a means of simulating command and control problems. The same with "army tactics": what does "attack left" and "support center" mean when it comes to determining if a unit should move, how far should it move, and whether it should move in formation with other units?

Games like BattleLore provide a great example of the consequences of those decisions, for example. BattleLore uses the concept of unit support, whereby a unit is "supported" if it has two friendly units adjacent to it. If a unit is supported, it can ignore one morale result. So, if the player gets a command card that allows two units to move, and the three units are currently in a mutually-supporting formation (i.e. all three units count as "supported" and all each of the three units count the other two as their support), the questions become:

• Should you move and break formation?
• If so, which two units should you move?
• How should you move?

There might be a legitimate reason to break formation: the enemy is exposed and vulnerable to quick elimination; you can quickly attack and re-gain formation before the enemy can effectively respond, etc. But none of the systems Shaun mentioned (army tactic, pre-defined orders, reaction charts) tell the player the answers to the above questions; they simply provide more data points to consider when making the decision.

What the exercise with Saga taught me is that it is more important to look at combinations of actions, rather than the action of individual units. What the player needs is a program to define a course of action more than whether Unit X should move 4" or 6", and directly straight ahead or 22º to the right.

So, this means that in practice the player can actually use a combination of decision making processes to game solo. You can use one method to tell you what course of action the non-player general is taking, for example by using a rules database, another for units in critical positions, such as a reaction-based system when the enemy is within charge range (think of them as Immediate Action Drills, like infantry going into square in the face of cavalry), and a third method still for units not in critical positions, like Just Do It. So each "trick" might not only be dictated by the game system used, how much preparation time you are willing to spend, and your current mood, but it might be used depending upon the circumstances within a game. This is especially true if you are using complex systems for decision making. Some of the mundane details just cannot be forecast and requires that you rely to a certain extent on the player interpreting intent. Otherwise your rules database, condition statements, decision trees, or finite state machines will be so complex that you cannot complete them.

Having put a lot of effort into DBA Solo (DBAS) in the past, I know that developing something generic results in two things: a lot more work; and generic results. I think a framework for a generic programmed opponent is a starting point, but you take that – whatever it is: rules database, reaction charts, states – and you use it as the basis for writing a scenario-specific implementation. Copy-and-paste programming, if you will. Eventually your generic programmed opponent will have a "attacker" variant, "defender" variant, "defending a hill ridge" variant, "attacking a town" variant, etc.

So, who is up for developing a framework with me for a programmed opponent in Rally Round the King? If you really are interested, I could set up a small forum, like I did for my Dale's Wargames blog, and we can continue the dialogue there, publishing interim results here.

---

¹ I prefer not to have a dialogue in the comments section.