Summary

To recapitulate, RBSs are split into three components:

• The rulebase is a big database storing all the rules.

• The working memory keeps track of the symbols representing the problem.

• The interpreter uses the rules to manipulate the symbols.

Interpreters can have three different inference mechanisms:

• Forward chaining works on a recognize-act cycle starting from the current state. This is a simpler and more common approach.

• Backward chaining works with a hypothesize–test cycle, starting from the theoretical end state. This is not quite as common, and slightly trickier to implement.

• Bidirectional approaches combine both forms of chaining together.

The biggest problem with RBSs is the acquisition of knowledge; experts are needed to create the rules. The process can be simplified with these policies:

• Separate the rulebase from the interpreting code, using a declarative approach.

• Allow the rules to interact with the system using procedural effectors and sensors.

RBSs are particularly well-suited to deductive problem solving. They can also handle reactive control very well, but tend to suffer in complexity when internal symbols are required—or when sequences of outputs need to be supported. In the next chapter, we'll apply RBSs in practice to create a wall-following behavior.

Practical Demo There's an example that bridges the gap between RBS theory in this chapter and the next on movement. Brutus is an animat with dog-like activities, capable of following players or stopping at their feet among others (a combination of steering behaviors). Each action is expressed as a C++ if() then statement, essentially a first-generation procedural expert system. Brutus can be found on the web site at http://AiGameDev.com/ with the other animats, in binary and source form.