Gming (Mal)Adaptive A.I.

Using DFAs, Flowcharts, and Counter Dices to emulate Adaptive A.I. in Sci-fi games.

Problem

It's Game Night. Black screens purr to life as paper is etched with dollar store lead. 

When last you met, this crew planed to board a derelict vessel manned by a rogue A.I. The only thoughts on its chips? Survive.

In between then and now, oodles of tricks and traps spilt from your pen onto the automaton's processors. But come game night, your machine devolved into a talking head for a tetanus filled fun house. 

There has to be some way of running an A.I. as an actually intelligent machine that's still fun to outsmart.

(A) Solution

Coincidentally, a noted Ennie Award winner is hosting a blog wagon about holes. Using some word association, we could have our new gameplay loop center around the players "poking holes" into the A.I.'s logic, and the A.I. adapting to it.  

(For the Zillenials in the rafters, Imagine the Mr. Freeze Boss Fight from Arkham City)

Of course, actually executing this without writing an actual line of code will be difficult. Luckily for you, the author happens to be an overachieving game dev that knows enough about Automata Theory to draw some funny looking state machines circles.

The Procedure

Prep - DFA Basics

Those who know anything about Automata Theory will recognize that this is essentially a DFA w/ some limited memory bolted on. For everyone else, if you've seen a flow chart, you'll be fine.

Stats

The Automata isn't just Code. It needs power to run, computational processors to make decisions, and data storage for memory. 

• Variables: A value stored in a designated die. Used in comparisons for Control Flow Statements 
• Processors/RAM: The die size used for Variables.
• Bottlenecked the Processors? Reduce max die size for all stored values by 1
• (d20 -> d12 -> d10 -> d8 -> d6 -> d4 -> 1)
• Power: How many Protocols can be Active at once. By default, the Automata has enough Power to run all Protocols. 
• Low Power?  Reduce Power by 1 and decide which Protocols are running. Can swap active Protocols every 10 * d4 minutes/ 1d4 dungeon turns. 
• 0 power means the A.I. is completely inactive 
• Data Storage/ROM: The number of dice to Allotted for Variables. The lowest value and highest values it can store is limited by the type of die. If 
• Data Leaks? Variable data corrupted, reroll all Variable dice.
• Out of Storage Space? All Variables are NAN (link)

Control Flow Statements (Diagrams | Description)

There are millions of ways to structure Protocols for your Automata, here are some common design patterns for you to use: 

 

 

Start State | The Starting point for an Automata's protocol

 

 

 

Transition State | A Protocol's state only progress from one state to another if the specified input is met. If no input is specified, the Protocol always transitions to the next state. 

 

 

 

 

Yes/No Check | The bread and butter of any Automata. If this statement is true, then continue down the yes branch. Otherwise, go down the no branch.

 

 

Do Until | A holding pattern that will continue until the requirement is satisfied. Usually a good idea to have an edge case to prevent infinite loops.

 

 

 

 

Range Check | Similar to the Yes/No Check, but for open ended questions with any range of desired values (The Yes/No Check is essentially a Range Check with 2 possible values). 

Warning: Improper Range Checks may lead to Error States.

 

 

 

Update Variable | Increment / Decrement any die Variables stored by the Automata.

 

 

 

 

Jump To (go to) | The Forbidden Statement. Only use if you know what you are doing, you're porting old Automata to modern systems, or you feel like making linguine.

 

 

 

 

Action State | The actual action your Automata will perform. Assuming there are no other arrows leading out of the Act State, the Program.

 

Error State | All Automata automatically jump to this state when an invalid input is used for a check or the Protocol runs into an infinite loop 

(note: meat compiler's judgement required)

 

Prep - Pre-Awakening

Initially, your A.I. is essentially a glorified manager for the mechanisms connected to its local network. In terms of level design, think of the A.I. as the brain, its area of influence as the body, and the various devices under its control as the blood cells. 

The procedure for building your Pre-Awakened A.I. is:

• Determine the primary responsibilities the AI was built for. What resources can it use to fulfill these responsibilities? 
• Assign each responsibility a Protocol, represented by an Automata that will be designed by you:
• Start with common actions with each responsibility. These will be your Action States.
• From the Protocol's Starting State, use Control Flow Statements to control when the A.I. will use specific Action States. 
• Write in plain English what you want the A.I. to do as a series of (conditional) steps.
• Note: Protocols can not use randomness or any Saves from the A.I. (for now) 
• Translate those steps into the provided Control Flow Statements examples.
• Technically speaking you could skip this and just use the written instructions. You might find it easier to track the Protocol's current state using diagrams (and tokens).
• For each Protocol:
• Go down each branch in the Protocol and try to find edge cases where the branch leads to an Error State. If you reached an Error State, tweak / overhaul checks as needed.
• Go to the next protocol
• Repeat until no flaws can be found, or you've checked each protocol 3 times.

Tip: For each check, imagine what possible input/action a player can could do to lead the Automata into an inappropriate Action State. Or use some sort of Oracle (link to die dream) to mimic erratic user behavior. 

• The A.I. is now self aware.

Prep - Post Awakening 

For its survival, your A.I's needs to be completely self sufficient. Similar to the last step, you (may) need to modify existing Protocols to answer the following:

• Where does it get its power?
• Where are its memory banks?
• Where are its processors?
• How does it maintain and repair itself? 
• How does it protect itself from cyber / physical threats? 
• What does it actually want? Usually this is related to how it originally became self aware.

However, keep in mind that:

• You can not remove anything in a Protocol created during the Pre-Awakening Step. 
• You can only change text in a Protocol written during the Pre-Awakened Step. 
• You may add any Control Flow Statements in-between existing States / Conditions
• Note: This includes conditional statements using Randomization / Saves from the A.I.

Remember to go through each Protocol one last time to root out any potential errors. Or don't if you want a very buggy A.I.

At the Table

Go through play as normal(link for running a dungeon), but when a (N)PC interacts with the AI or one of its sub systems, it runs through the most appropriate Protocol. 

However, when the AI is harmed/outsmarted due to a hole in its logic, modify the Protocol via the same limitations as the Post Awakening Step.

• Note: Worry about Fast Code over Good Code when it comes to playing at the table.