Sunday, March 3, 2013

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 eventuality1, 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.

1 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!


  1. Thanks for the thorough and thoughtful article! (alliteration, ha)
    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. Like you mentioned as a possibility, your articles on this showed me it's probably not something I would invest the time in for my own gaming, and you saved me from wondering about that.

  2. Good post. Like Fitz-Badger I'm not sure if I will play saga but I like the exercise. I need to go back and review the various solo titles I have and see what I can incorporate. I also should probably revisit FSM's viv a vis RRtK. I don't seem to recall you hitting on that yet when you were talking about that in reference to your programmed opponent. Perhaps another blog search is in order.

  3. Dale,

    Although not interested in Saga, it *is* interesting reading the processes you go through developing and testing the FSM. And everytime you post, I think about doing my own FSM for ancient rules like RRTK. 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. All I have to do is stop catching up on reading stuff and write something down! It will come in useful for my historical battle replays, and I can test it out via them, so it will not be wasted.

  4. Well thanks for the honesty (regarding Saga). I am a bit obsessed with it at the moment, along with Pre-Columbian Mesoamerican warfare.

    The amount of work involved 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.

  5. Really, you are obsessed with Saga at the moment? No one would have guessed :-)

    The amount of work is daunting, and it shows even with the work you have done with Saga. Which is why I have written nothing down on my TSM. It does involve a lot of work, and seems to be fairly rules specific. There may be ways to make it more generic, but that seems like even *more* work.

    Keep up the posts on the Saga TSM (and other solo mechanisms) - it is fascinating.

    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?