"FSMs and Solo Gaming with Programmed Opponents" Topic

I wrote about using Finite State Machines (FSM) with solo miniatures gaming in an earlier post on my blog and it got a pretty good response. This is part of my series looking at different solo gaming mechanisms and how they can be applied. FSM are often used for computer game AIs (and many other computer applications that require tracking state) and provides you a way of structuring rules for a 'programmed opponent'. If you missed the original post you can find it here on my blog .

Building a programmed opponent can be a lot of work, but as stated in the new post:

"My goal has largely been to design an artificial opponent in such a way that much of the decision-making is taken away from the player and performed by a 'program'. If that program can be structured and standardized, then it might even be possible to develop several programs and trade them between players. The goal might not be so much to develop a programmed opponent that cannot be beaten as much as one that is both entertaining and challenging. (At this point I would settle for plausible.)"

For me, the concept of embedding personality into a programmed opponent to get a different game feel for a given scenario is exciting and something I would like to strive towards. My first effort at creating a concrete example uses the Saga miniatures rules with a Meso-American variant I am working on. Although the example is pretty detailed, and very specific to a rules set, I hope you can find something of use in it and it prompts some discussion. The program can be found here on my blog

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!

Great story! Reminds me of the Cruise Missile Strike Program story and unintended consequences,

I strongly suspect that I will have to tweak the Tlaxcaltec program quite a bit, especially with regards to which Saga abilities to fund, and their order of priority, based on whether the enemy is outside missile range, inside missile but outside charge range, or inside charge range.

Also, this is part one, which is the program for the force as a whole; I still have to develop the programs for the individual units as well.

I don't think I know that story (CMSP). Do tell …

During the first Gulf War (supposedly) the cruise missiles were programmed for their strike: Missile A hits Defense building. Missile B flies to Defense building, turns right and hits Ammo Bunker, etc. Unfortunately the scheduling software had A going before B so when B's targeting system looked for the Defense building landmark it could not find it … because it was already destroyed.

Coders were working furiously to fix the glitch before the next wave of cruise missiles flew … or so the legend goes!

:)

There was apparently a problem with the intercept logic for the Patriot. No one told it not to calculate an intercept below ground level. Led to the spectacular sight of a missile zooming in a (very) shallow arc over a major city, hitting the ground at a grazing angle, and bouncing down a major boulevard with the motor still burning …