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!