The Understanding Phase

The understanding phase focuses on one particular task (for instance, obstacle avoidance). We attempt to understand how a solution works and describe it as best possible. The understanding phase relies on three different concepts:

• Goals Description of what we want the AI to achieve. Goals can be understood as a very high-level explanation of the outcome.

• Requirements A list of requests from various members of the development team that need to be taken into account when expressing the problem.

• Restrictions Implicit aspects of the platform (its design or implementation) that also affect the solution to the problem.

The purpose of the understanding phase is to create the problem or at least define it better. This involves translating the goals into a more explicit outcome, and then breaking that down into step-by-step actions as shown in Figure 7.3.

Figure 7.3. The understanding phase within the AI development process. It takes a collection of requests and attempts to specify the problem at different levels.

The understanding phase proceeds much like the analysis. We start with an overview of existing work to give us a feel for similar problems. Then, we can draft the criteria that will evaluate the outcome. Finally, a case study is used to split up the outcome into a combination of primitive actions.

Criteria and Desired Outcome

The first thing to describe is the resulting behavior. Ideally, we would like to have a well-defined outcome of the problem; the understanding phase makes sure of this! The goals we are given may be incomplete and somewhat inconsistent, unsuitable for engineering AI. Our aim is to interpret and understand what is implied and specify the outcome in a more precise fashion.

This generally takes the form of high-level criteria. We can draft a list of such criteria that will be used to evaluate the outcome of any solution. Because the list can be ordered, priorities between these criteria can be established. However, the ranking of criteria is not always obvious, as choosing between two of them is not always possible in the general case. In practice, the ranking becomes obvious when specific decisions must be made involving two factors. (The priorities are defined relatively to each other.)

The criteria are often problem specific, so they need to be described within the context of each problem. That said, some criteria appear regularly during AI development. These include reliability, efficiency, realism, flexibility, or even competence. Once again, we'll have to decide upon the list and priorities in each part separately.

For our obstacle-avoidance problem in Chapter 6, "Moving Abilities," properties are borrowed from human movement to serve as a reference for the AI behavior: realism, efficiency, reliability, and purposefulness. These take into account our goals for creating movement, overall requirements, and restrictions from the platform.

Being more specific, we could explain that animats should take no steps that cause a collision. Contact with obstacles is acceptable, as long as the animat is immobile or moving away from the contact point. A slightly more refined criterion would be to restrict the turns to a maximum of 20 degrees per second when no obstacles are within 4 steps, and no limits otherwise.

Problem Definition

When possible, the understanding phase must also decompose the outcome into a sequence of actions, those necessary to solve the problem. Breaking up the problem essentially makes it more explicit, thereby proving easier to solve.

Typically, it's possible to determine what should be done based on a case study (of human behavior, for example). Each of the situations is described, and assigned a particular result. Alternatively, a more implicit description would present key aspects of the behavior, using general examples and exceptions. So without listing scenarios one by one, we can describe what should happen and what should be avoided in a much more convenient fashion.

For our reactive movement, we wrote down a brief list of situations along with the expected action (refer to Chapter 6). This didn't need to be exhaustive because the task is relatively simple; however, we still described the expected turns and speed controls. More complex problems need more time spent on this stage.