Rule-Based Systems

Rule-based systems have a common structure consisting of two

parts: a database containing knowledge available to the AI and a
set of if–then rules. Rules can examine the database to
determine if their “if” condition is met. Rules that have their
conditions met are said to trigger. A triggered rule may be
selected to fire, whereupon its “then” component is executed.
The Problem
• We’ll build a rule-based decision making system with many
of the features typical of rule-based systems in traditional
AI. Our specification is quite complex and likely to be more
flexible than is required for many games. Any simpler,
however, and it is likely that state machines or decision
trees would be a simpler way to achieve the same effect.
• In this section we’ll survey some of the properties shared
by many rule-based system implementations.
• Each property will be supported in the following algorithm.
We’re going to introduce the contents of the database and
rules using a very loose syntax. It is intended to illustrate
the principles only. The following sections suggest a
structure for each component that can be implemented.
DatabaseMatching
• The “if” condition of the rule is matched against the database; a
successful match triggers the rule.
• The condition, normally called a pattern, typically consists of facts
identical to those in the database, combined with Boolean
operators such as AND, OR, and NOT.
• Suppose we have a database containing information about the
health of the soldiers in a fire team, for example. At one point in
time the database contains the following information:
Captain’s health is 51
Johnson’s health is 38
Sale’s health is 42
Whisker’s health is 15
• Whisker, the communications specialist, needs to be relieved
of her radio when her health drops to zero. We might use a
rule that triggers when it sees a pattern such as:
Whisker: health = 0
• Of course, the rule should only trigger if Whisker still has the
radio. So, first we need to add the appropriate information to
the database. The database now contains the following
information:
Captain’s health is 51
Johnson’s health is 38
Sale’s health is 42
Whisker’s health is 15
Radio is held by Whisker
• Now our rule can use a Boolean operator. The pattern becomes: Whisker’s
health is 0 AND Radio is held by Whisker
• In practice we’d want more flexibility with the patterns that we can match.
In our example, we want to relieve Whisker if she is very hurt, not just if
she’s dead. So the pattern should match a range:
Whisker’s health < 15 AND Radio is held by Whisker

• So far we’re on familiar ground. It is similar to the kind of tests we

made for triggering a state transition or for making a decision in a
decision tree.
• To improve the flexibility of the system, it would be useful to add wild
cards to the matching. We would like to be able to say, for example,
Anyone’s health < 15
and have this match if there was anyone in the database with health
less than 15. Similarly, we could say,
Anyone’s health < 15 AND Anyone’s health > 45
to make sure there was also someone who is healthy (may be we want
the healthy person to carry the weak one, for example).
Condition–Action Rules
• A condition–action rule causes a character to carry out some
action as a result of finding a match in the database.
• The action will normally be run outside of the rule-based
system, although rules can be written that directly modify the
state of the game.
• Continuing our fire team example, we could have a rule that
states:
IF Whisker’s health is 0 AND Radio is held by Whisker THEN
Sale: pick up the radio
• If the pattern matches, and the rule fires, then the rule-based
system tells the game that Sale should pick up the radio.
• This doesn’t directly change the information in the database.
We can’t assume that Sale can actually pick up the radio.
Whisker may have fallen from a cliff with no safe way to get
down. Sale’s action can fail in many different ways, and the
database should only contain knowledge about the state of the
game. (In practice, it is sometimes beneficial to let the
database contain the beliefs of the AI, in which case resulting
actions are more likely to fail.)

• Picking up the radio is a game action: the rule-based system

acting as a decision maker chooses to carry out the action. The
game gets to decide whether the action succeeds, and updates
the database if it does.
Database Rewriting Rules
• There are other situations in which the results of a rule can
be incorporated directly into the database.
• In the AI for a fighter pilot, we might have a database with
the following contents:
1500 kg fuel remaining
100 km from base
enemies sighted: Enemy 42, Enemy 21
currently patroling
• The first three elements, fuel, distance to base, and sighted
enemies, are all controlled by the game code. They refer to
properties of the state of the game and can only be
changed by the AI scheduling actions. The last two items,
however, are specific to the AI and don’t have any meaning
to the rest of the game.
• Suppose we want a rule that changes the goal of the pilot from
“patrol zone” to “attack” if an enemy is sighted. In this case we
don’t need to ask the game code to schedule a “change goal”
action; we could use a rule that says something like:
IF number of sighted enemies > 0 and currently patroling
THEN remove(currently patroling) add(attack first sighted
enemy)
• The remove function removes a piece of data from the
database, and the add function adds a new one. If we didn’t
remove the first piece of data, we would be left with a database
containing both patrol zone and attack goals. In some cases this
might be the right thing to do (so the pilot can go back to
patroling when the intruder is destroyed, for example).
• We would like to be able to combine both kinds of effects: those
that request actions to be carried out by the game and those
that manipulate the database. We would also like to execute
arbitrary code as the result of a rule firing, for extra flexibility.
Forward and Backward Chaining
• The rule-based system we’ve described so far, and the only one we’ve
seen used in production code for games, is known as “forward
chaining.” It starts with a known database of information and
repeatedly applies rules that change the database contents (either
directly or by changing the state of the game through character
action).
• Discussions of rule-based systems in other areas of AI will mention
backward chaining. Backward chaining starts with a given piece of
knowledge, the kind that might be found in the database. This piece of
data is the goal. The system then tries to work out a series of rule
firings that would lead from the current database contents to the goal.
It typically does this by working backward, looking at the THEN
components of rules to see if any could generate the goal. If it finds
rules that can generate the goal, it then tries to work out how the
conditions of those rules might be met, which might involve looking at
the THEN component of other rules, and so on, until all the conditions
are found in the database.