Repository navigation
BOD
The initial decomposition is a set of steps. Executing them correctly is not critical, since the main development strategy includes correcting assumptions from this stage of the process. Nevertheless, good work at this stage greatly facilitates the rest of the process.
- Specify at a high level what the agent is intended to do.
- Describe likely activities in terms of sequences of actions. These sequences are the the basis of the initial reactive plans.
- Identify an initial list of sensory and action primitives from the previous list of actions.
- Identify the state necessary to enable the described primitives and drives. Cluster related state elements and their dependent primitives into specifications for behaviors. This is the basis of the behavior library.
- Identify and prioritize goals or drives that the agent may need to attend to. This describes the initial roots for the reactive plan hierarchy (described below).
- Select a first behavior to implement.
A critical part of the BOD methodology is the set of rules for revising the specifications. The fundamental design principle is when in doubt, favor simplicity. A primitive is preferred to an action sequence, a sequence to a competence. Similarly, control state is preferred to learned state, specialized learning to general purpose learning or planning. Given this bias, heuristics are then used to indicate when a simple element should be exchanged for a more complex one.
A guiding principle in all software engineering is to reduce redundancy. If a particular plan or behavior can be reused, it should be. As in OOD, if only part of a plan or a primitive action can be used, then a change in decomposition is called for. In the case of the action primitive, the primitive should be decomposed into two or more primitives, and the original action replaced by a plan element, probably an action pattern. The new plan element should have the same name and functionality as the original action. This allows established plans to continue operating with only minimal change.
If a sequence sometimes needs to contain a cycle, or often does not need some of its elements to fire, then it is really a competence, not an action pattern. If a competence is actually deterministic, if it nearly always actually executes a fixed path through its elements, then it should be simplified into a sequence.
Competences are really the basic level of operation for reactive plans, and learning to write and debug them may take time. Here are two indications provided by competences that the specification of an agent needs to be redesigned:
- Complex Triggers: reactive plan elements should not require long or complex triggers. Perception should be handled at the behavior level; it should be a skill. Thus a large number of triggers may indicate the requirement for a new behavior or a new method on an existing behavior to appropriately categorize the context for firing the competence elements. Whether a new behavior or simply a new method is called for is determined by whether or not more state is needed to make that categorization: new state generally implies a new behavior.
- Too Many Elements: Competences usually need no more than 5 to 7 elements, they may contain fewer. Sometimes competences get cluttered (and triggers complicated) because they actually contain two different solutions to the same problem. In this case, the competence should be split. If the two paths lead all the way to the goal, then the competence is really two siblings which should be discriminated between at the level of the current competence's parent. If the dual pathway is only for part of the competence, then the original competence should contain two children.
Effectively every step of the competence but the highest priority one is a subgoal. If there is more than one way to achieve that subgoal, trying to express both of them in the same competence can split attention resources and lead to dithering or `trigger-flipping' (where two plan elements serve only to activate each other's precondition). The purpose of a competence is to focus attention on one solution at a time.
The heart of the BOD strategy is rapid prototyping. If one approach is too much trouble or is giving debugging problems, try another. It is important to remember that programmers' experiences are the key selective pressures in BOD for keeping the agent simple. BOD provides at least two paths to simplicity and clarity: modularity and hierarchical reactive plans. Using cyclic development and some trial and error, the programmer should determine which path is best for a particular problem (5,30). This is also why modularity and maintainability are key to BOD: programmers are to be encouraged to change the architecture of an agent when they find a better solution. Such changes should be easy to make. Further, they should be transparent, or at least easy to follow and understand, if another programmer encounters them.
Further heuristics, particularly with respect to prioritization and scheduling in drive collections can be found elsewhere (8). In the next section, I will instead give an example of the most fundamental revision, trading off complexity in plans for that in behaviors.
The heart of the BOD methodology is an iterative development process:
- Select a part of the specification to implement next.
- Extend the agent with that implementation:
- code behaviors and reactive plans, and
- test and debug that code.
- Revise the current specification.
BOD's iterative development cycle can be thought of as sort of a hand-cranked version of the Expectation Maximization (EM) algorithm (15). The first step is to elaborate the current model, then the second is to revise the model to find the new optimum representation. Of course, regardless of the optimizing process, the agent will continue to grow in complexity. But if that growth is carefully monitored, guided and pruned, then the resulting agent will be more elegant, easier to maintain, and easier to further adapt.
Unlike behaviors, which are simply coded directly in a standard object-oriented language, reactive plans are stored in script files. The plan is normally read when the agent is initialized, or ``comes to life,'' though in theory new plans could be added during execution. The reactive plans for an agent grow in complexity over the course of development. Also, multiple reactive plans may be developed for a single AI platform (and set of behavior modules), each creating agents with different overall characteristics, such as goals or personality.
Even when there are radically different plan scripts for the same platform or domain, there will generally only be one behavior library -- one set of code. Each agent will have its own instance or instances of behavior objects when it is running, and may potentially save run-time state in its own persistent object storage. But it is worth making an effort to support all scripts for a single platform or domain in a single library of behavior code.
Testing should be done as frequently as possible. Using languages that do not require compiling or strong typing, such as lisp or perl, significantly speeds the development process, though they may slow program execution time. ``Optimize later'', one of the modern mantras of software engineering, applies to programming languages too. In my experience, the time spent developing an AI agent generally far outweighs the time spent watching the agent run. Particularly for interactive real-time agents like robots and VR characters, the bottle-necks are much more likely to be caused by motor constraints or speech-recognition than by the intelligent control architecture.
The most interesting part of BOD's iterative design cycle is the set of rules for revising the specifications. However, understanding these rules requires understanding BOD reactive plans. The following section explains the details of BOD action selection. Section 6 returns to the question of knowing exactly how to optimize the agent.