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.

Testing the Finite State Machine

Well, the two finite state machine (FSM) articles (part one and part two) got a pretty good reaction (in terms of page views), so I know it is not a complete bore! I finally got a chance to test out the Tlaxcaltec "program" I wrote about last time. The reason for the delay, other than because I have been gaming online in a tournament, is because I have been working furiously on the draft Saga battle boards for both the Aztecs and the Tlaxcaltecs so I could actually run a game of Saga. Of course, some of those changes also invalidated my program, so I had to go an make some changes to that.

For those of you out there that have had a computer software configuration problem, you know that the best way to find the root cause of the problem is to change one thing and then test, before changing another thing and testing, etc. If you change multiple things, and everything suddenly works, it is very hard to know which change actually fixed the issue. Of course, if all you care about is fixing the issue, it is not much of a problem.

Well, designing a programmed opponent is much like troubleshooting software issues. If you are mucking about with a lot of other things – oh, say, working with draft rules for Saga battle boards – it is hard to know which thing caused a success or a failure! I knew that my program was not complete and would need modification during the game – I have never been a "big up-front design" kind of programmer – but I tried to limit that as much as possible. Only where I made a blatant error did I fix it.

If you remember the program, I essentially wrote one for the non-player general (NPG), who makes the decisions of what Saga abilities to fund, and in what order to activate units. Here is a brief description of the program:

The program is for a four-point Tlaxcaltec force fighting a four-point Aztec force. Due to the limited number of points the bow-armed Warrior units would be operating without their "shield" units, and thus two abilities would not be of use at all.

The program is designed to consider whether: all enemy units are outside of all missile weapons ranges; no enemy units are within charge range, but at least one is within missile weapons range; or at least one unit is within charge range of a friendly unit. These three states define:

• The exact order in which Saga dice will be allocated to abilities
• The order, by troop type, in which units will be activated
• The allowable actions, by troop type

When in the "All outside of missile range" state, the NPG will build up the expensive, shooting-oriented abilities. When in the "One inside of missile range, all outside of charge range" state, those expensive abilities would be used against high-value targets while the more utilitarian shooting abilities, and the expensive melee abilities, get allocated. Finally, when in the "One inside of charge range" state, certain melee abilities get funded first, followed by certain shooting abilities, and finally the remaining melee and shooting abilities.

To start off, this model actually worked pretty well. I started funding the "expensive" abilities (uses the rarer symbols or multiple dice) and using them to effect during the Aztec approach. That said, this is when the first instance of "I changed too many variables" bit me. You see, I had been basing up more troops so I could have larger battles and more variety in troop selection, and I succeeded to the point that my game switched from four points to eight! Further, I was able to buy the shield troops, thus certain abilities I had downplayed in the program now became more important. Of course, wanting to get stuck in, I made a few changes to the program and off I went.

As I played the game I began to realize that my program was a little too rigid, especially when it came to movement. This was more a function of me being unfamiliar with how to use the Tlaxcaltecs properly than the program having a mechanical flaw. I had intentionally written a program that minimized movement. I was using a smaller table than normal (another unaccounted for variable change) with less depth to the deployment zone (yet another change), so I could start with enough distance between the two armies' start lines. Generally it is not a problem in Saga, as being up against your baseline has no negative effect (there are no "morale rolls" where falling back off the board removes the unit from play); in fact it has a somewhat positive one in that you can anchor your flank on "the edge of the world".

I would say that the program largely worked until the Aztecs started getting in among the Tlaxcaltecs (the non-player side). There was not enough of a program developed for that state to play adequately, much less provide a challenge. It was at that point that I started making decisions for the NPG and noting down my thinking process so I could update the program.

The Test Battle

This battle report will be a little different than most that I write up. This will be more of a snapshot of the game in progress, what event needs highlighting, and what impact it had on the program (during the game or in the future). It is not really meant for entertainment value. (Hence the reason I used an ugly game mat for the test.)

First is a picture of the deployment. The Tlaxcaltecs (the programmed side) is on the left and the Aztecs are on the right. The Aztecs have more troops as they downgraded one unit of Warriors to Levy.

The Tlaxcaltecs have their shield warriors in the forward units on the flanks; the bow warriors are immediately behind them. This combination of shield unit in front with bow unit in the rear allows the use of the Shielded Volley and Common Effort abilities. The first, a critical tactic, allows the bow unit to shoot through the shield unit in front. This is the primary way of protecting the bow units from enemy melee troops; hits occur on the forward unit, which has a higher armor value.

The Common Effort ability allows one unit to move its fatigue markers to another unit with 4" of it. This allows a shield unit to move its fatigue to the bow unit behind. As the bows are not in the front lines, they have more of an opportunity to rest, removing the fatigue marker.

Because the original concept for the program was to forego the shield-and-bow combination, these two abilities were de-emphasized. More importantly, because of the way the battle board was designed, certain other abilities were incompatible with using this shielded tactic. Thus funding those abilities does not make any sense. Put another way, your deployment would dictate which of two tactics were built into the battle boards. (Note that I see this as more of a design flaw with the battle board and not with the program. I will be looking at eliminating that problem before the next test of the program.)

In the center are the Tlaxcaltec elites. In front are two small (four figure) units of Jaguar Warriors. They are intentionally small in order to make them maneuverable surgical strike units. They also act as a screen for a larger (eight figure) Coyote Warrior unit wielding two-handed weapons and guarding the Warlord. This large unit is designed to destroy the unit guarding the enemy Warlord and slay (or capture) him. (As a programmed opponent, I am proud that they almost succeeded at it.)

This next picture shows the board when the Aztecs breached the "All outside of missile range" state.

I intentionally used a game mat with hexes for the test so that I could go back and clearly see how far away units were from one another without having to photograph rulers on the table. This allows you to clearly see something not anticipated when I re-wrote the program to account for the shield-and-bow combination: the bows were a full three inches behind the front of the shield units. Given the bow's 12" range, the 3" set-back for the bows, and the enemy's 6" move, the enemy would never hit the "One inside of missile range, all outside of charge range" state!

Needless to say, this error created quite a bit of havoc with the program. It meant I went from funding shooting abilities to needing melee abilities. This was when sometimes, as a solo gamer, you need to cheat to help your opponent. I rearranged some dice and kept on. But it pointed out something very important regarding the abilities that I selected for the battle board, so it was a useful lesson after all.

Here is where my "Counter Charge" in the program kicked in. One of the Jaguar Knights "flying columns" darted out between an Aztec Eagle Knights unit and a Jaguar Knights unit in order to attempt the capture of my Warlord. They lost that melee, however. (A Warlord doesn't wear a green parrot suit on the battlefield without being able to kick some serious ass, after all! )

The Aztec Jaguar Knights then came to the rescue of their Warlord, but again the Tlaxcaltec "Counter Charge" kicked in.

The Coyote Knights and the Tlaxcaltec Warlord charged in and slew the Aztec Jaguar Knights, leaving the Aztec Warlord exposed and alone.

They had even captured a prisoner in the battle. (Although I accidentally put the wrong figure in the shot. That is a Tlaxcaltec Coyote Knight!) The Aztecs, however, had played a dirty trick (i.e. a Saga ability) and left the Tlaxcaltecs near exhaustion.

As a side note, Exhaustion has a definite game effect in Saga. Units that are exhausted fight with half the number of attack dice and cannot move or shoot until they rest. Warlords and elite warriors reach Exhaustion at four fatigue markers; the picture above shows them at three markers each (it was quickly at four markers, making them both Exhausted, and thus very vulnerable).

The picture above shows that the Aztecs were poised to capture the exhausted Tlaxcaltec Warlord. All they needed to do was kill off the remaining two Coyote Knight bodyguards. A volley from the atlatls and a sacrifice charge by some Aztec warriors quickly accomplish that task.

Now to go charge in for the capture. The Aztec Warlord calls forth his Eagle Knights…

But the program had wisely funded the ability Show of Strength when it had the opportunity. The Aztecs are forced to abort the charge and withdraw.

Lest you think that somehow this was pulled off as a surprise, it was not. One player is allowed to see what his opponent has allocated dice to at any time, so I knew it was coming. As the Aztec player I made the play in order to strip the ability. As it uses a Rare symbol to fund it, the NPG would have to roll another Rare next turn to be able to thwart me again.

As it turned out, the NPG did roll another Rare and did in fact thwart another attempt to capture the enemy Warlord. After that play I had run out of turns in the scenario, so the NPG played to a minor loss. Trust me, I was fine with that for a first foray.

Lessons Learned

Clearly I should have played both draft battle boards prior to this test. This would have given me a better idea of the strengths and weaknesses of the Tlaxcaltecs and been able to write a better program. I had written the original program with a vague concept of the forces that would be used, that no longer held true when game time come, and an understanding that the Tlaxcaltecs would "play something like the Welsh do", which was totally incorrect.

Second, you should make sure that you are not in a "pushing lead around" mood when you start. If you use this method you need to be in a program writing mood when you start your solo game. If you want to actually game, you will rush the program writing process. It takes work to write a program down as you really need to think about your decision making process and put it to paper.

Further, it takes more effort during the game than if you simply "played both sides to the best of your ability". First, you are walking through a program, which takes time. Second, you will never foresee every eventuality¹, so there are times when you need to stop and add to the program. Don't fall into the trap that somehow you will remember the decision points that you did not think about (there will be a lot of them) and you will also remember your thought process so you can replicate your decisions later. It won't happen.

So, all of this begs the question: is it worth all of the effort? My hope is to re-write the program, send it to someone else, and they get a good game out of it. I think that might be a little problematic, considering that I am using two very specific, fan-made factions for a game that, although is currently popular (in terms of buzz), is not very widely played. Now a program for Space Marines™using the Warhammer 40,000 Sixth Edition rules – that would be another matter entirely. But I did what I did, and it provided a good, maybe even slightly surprising game for me because it forced me to take actions I might not have normally taken, especially as I had written the program to be more passive in the opening moves and more aggressive in melee, than I thought that I had.

It looks like it is time to look at my "AI Programming for Games" book again and see what I can incorporate next. I am not abandoning FSMs; it is just that this blog is about exploring ideas and trying to make them concrete. That is something I complain about with solo gaming books on the market; they are just a bunch of random, disconnected ideas with few examples of how to really use them. I hope that I have given you enough depth in these three articles to give you something to try, or at the very least, helped you determine whether this might be your cup of tea. Let me know either way.

---

¹ TMP user emckinney had the comment: "The big battles scenes in the Lord of the Rings movies used CGI soldiers for the big battles (no surprise). A program that was run for each soldier determined his behavior. If the enemy as far away and the soldier had lots of friends around, he charged the enemy. If the soldier was close to lots of enemies, he fell back. (There was a formula driving all of this.)

When the ran the battle scene for the first time, the two armies charged each other … then, just before contact they all pulled back. Then they charged, but pulled back before contact. they kept pulsing like this, as the programmers watched in horror. Turned out that they needed to do quite a bit of tuning of the weighting of the variables!"

Hey, if they can't anticipate this behavior, no reason I can't flub it up too!