The Analysis Phase

The analysis phase does not focus on one particular scenario; instead, it tackles common principles. Analysis involves studying two things:

• General task— A universal ability that we want to provide using AI (for instance, navigation)

• Platform— Various aspects of the design (for instance, environment) and software (for instance, physics simulation) affecting the task

The idea is to quantify these two concepts to know what can be relied on during the AI development. The result of the analysis is split into three major parts: assumptions, restrictions, and guidelines—as shown in Figure 7.2. Each part is nothing more than a description in English (as detailed as necessary).

Assumptions

The assumptions list the facilities of the platform that the AI can rely on. These are taken into account during the specification.

We can achieve this by explaining the environment in which the AI is to perform, as well as the relevant part of the game engine. In most cases, it's sufficient to enumerate and describe the interfaces provided for human players. Indeed, the AI will often be handled in a very similar fashion.

In the case of movement, for example, we assumed that there was a physics engine to apply the movement, and that it would resolve conflicts and collisions. We also relied on the animation system to provide low-level limb control, described as the locomotion system (used by human characters in the game, too).

Generally, little time is needed to draft the assumptions. At this stage, the design of the engine is usually already frozen. So, it isn't open to debate. The AI developer must decide how much of the platform to expose to the AI, and at what level it should be integrated. As a general rule of thumb, the maximum code should be reused, and the AI should rely on the human player interface as much as possible.

We should pay particular attention to troublesome aspects in the platform (for instance, clashes with the AI, temporary components that are not yet frozen). The description part of the assumptions should clarify the situation and help resolve the problems.

Restrictions

The restrictions are aspects of the design or software that affect the task at hand. The restrictions affect the problem itself, rather than its specification. As such, they are taken into account by the understanding phase later, which describes the problem.

Specifically, we need to describe the parts of the game engine that make the problem difficult to solve; these are restrictions. What aspect of the simulation has an affect on the way the problem is solved?

In the case of movement, the structure of the terrain is a restriction that prevents certain kinds of movement. There are also restrictions in model of the environment, notably our inability to gather perfect information. Also, the simulation itself can be restricting factor, as it implies that the AI can only get discrete opportunities to move around.

Guidelines

The guidelines are particular aspects of the design and platform that need to be taken into account during the application phase.

Guidelines take the form of various procedures that should be followed as closely as possible to assist the development. Often, developers have general guidelines that they follow throughout the process (for instance, document everything or at most 20 minutes per task). However, here we're talking about specific guidelines that focus on the particular task at hand. For this reason, it isn't possible to explain them generally, but once established, they should be followed all the same—as long as they improve the development process.

In the discussion about the environment, for example, a few paragraphs in Chapter 5, "Movement in Game Worlds," were spent describing the test bed. More specifically, suggestions are made about the use of normal game levels for development (not simplified ones), and making sure that many different levels are used to test the AI. These are examples of specific guidelines for the development of navigation behaviors.

Although there are guidelines that help developing AI behavior generally (for instance, diverse environments and time limits on experimentation), it's usually difficult to identify specific procedures before the development actually starts! Indeed, the best guidelines are based on practical experience. So, unless there is some existing wisdom that can be applied to this area, we're left with our theoretical insights as guidelines. That said, although it may be delicate to define good guidelines from the start, it's never too late to establish new ones and start following them—even far into the development; any form of structure is a good thing! Such practices, reminiscent of agile development (for instance, continuously upgrading to better methodologies) are particularly important for AI development because of the complexity of the task and its unpredictable nature.