Designing (game) AI is about assembling many weak components together. The components provide functionality for each other and communicate together to collectively solve the problem. This set of nested components is known as an architecture.
These architectures are reactive when they are driven by sensory input, and decide on output actions deterministically. Such architectures are very common for systems that need to react in a timely fashion, whether to external requests or stimuli from the environment (for instance, robots and washing machines).
A component can be understood as a black box with a mystery AI technique inside. Alternatively, the component may be built as a subsystem of smaller components. Components interact with others via their interfaces, using inputs and outputs.
Internally, as mentioned previously, there is no theoretically difference between a deliberative component and a reactive component. This correspondence applies for the interfaces, too! Any deliberative planning component can be considered as reactive. All the necessary information is provided via the interfaces in the same fashion; only the underlying technology changes.
This is a tremendous advantage during the design phase, because the underlying implementation can be disregarded. Then, if a reactive technique is not suitable, a deliberative component can be inserted transparently.
Naturally, there are many ways to combine components together. This is the purpose of architectures, because they define the relationship between components. Figure 3.4 shows three example architectures with different internal organizations:
Figure 3.4. Three example architectures with different internal organizations. From left to right, monolithic, flat, and hierarchical architectures.
As an example of a hierarchical architecture for games, the brain may be built as a collection of behaviors (for instance, hunt, evade, patrol), which are components within the brain. Each behavior in turn may depend on components for moving and shooting. This is a three-level hierarchy.
In general, selecting the organization of an architecture is about problem complexity. Simple problems will manage with monolithic architecture, more sophisticated problems may need flat architectures, whereas hierarchical architectures can handle almost any problem by breaking it down. (Chapter 21, "Knowledge of the Problem," and Chapter 28, "Understanding the Solution," discuss these points further.)
Instead of thinking of an architecture as a combination of components (bottom-up), it can be understood in a top-down fashion: "How can this problem be split up?" This concept of decomposition is central to AI development in general.
There are many types of decompositions. The idea is to split the problem according to certain criteria—whichever proves the most appropriate for solving it! This applies equally well to software design as to the creation of game AI:
Naturally, the decomposition can happen on multiple levels using many different criteria. For example, the initial problem may be decomposed as behaviors, then each behavior may be expanded as different functionality, using different criteria known as a hybrid decomposition, as opposed to using one criteria throughout the architecture (or pure decomposition).
Behavioral decompositions are very appropriate for computer games. The functional decomposition is also used in this book, as we develop common abilities that can be reused by the nonplayer character (NPC) AI.
Given a set of subcomponents, how are they connected together? Specifically, how are all the outputs interpreted to form the output of the component itself? There are four different ways of doing this:
There are many different combinations of architectures. Figure 3.5 shows two common examples to illustrate the issue.
Figure 3.5. Two popular reactive architectures. On the left, the subsumption architecture with its horizontal layers. On the right, a voting system that combines the votes of four nested components.
The subsumption architecture is a behavior-based decomposition, using a flat organization with suppression on the outputs [Brooks86].
The system can be seen as a set of horizontal layers. The higher the layer, the greater the priority. Layers can thereby subsume the ones beneath by overriding their output. This architecture is explained further, and applied to deathmatch behaviors in Chapter 45, "Implementing Tactical Intelligence."
Voting systems generally use a functional decomposition, with a flat organization using combination to merge the outputs together. Chapter 25 uses a voting system for weapon selection.
The system can be interpreted as a set of distributed components that are all connected to a smaller component responsible for counting votes. The output with the most votes becomes the output for the global output.