Showing posts with label Artificial Intelligence. Show all posts
Showing posts with label Artificial Intelligence. Show all posts

FEAR: A Platform for Experimentation

Game AI generally takes a lot of work to implement—not directly for the AI techniques, but to integrate custom AI, or even middleware, within the game. This is an unavoidable consequence of current engine design, and can be difficult to deal with when starting out in AI development.

This book provides a real game for testing the AI, and not just a toy environment or command prompt. For this, the open source FEAR project is used, integrated with a commercial first-person shooter game engine. Some other game engines use similar frameworks to assist the AI development (but they're not as flexible). FEAR provides some helpful facilities, including the following:

  • World interfaces for the AI to interact with the game engine (physics simulation and logic)

  • Modules that implement AI functionality on their own or by depending on other modules

  • Flexible architectures that enable engineers to assemble arbitrary components together

  • Tools to create animats and their source files using minimal programming

As the combination of these elements and more, FEAR provides an ideal foundation for the examples in this book—and many other prototypes, thanks to its flexibility.

World Interface

The exchange of information with the world is an extremely important part of AI. For animats, this takes the form of interfaces between the brain and the body. In terms of information flow, this leads to two different types of interfaces:

  • Sensors provide a way to acquire information from the surrounding environment.

  • Effectors allow the brain to control the body to act upon the world.

Although it is possible to separate these two types of interfaces in the implementation, FEAR no longer imposes this. Respecting this convention is unnecessary and leads to overly complex code. Instead, it's more convenient to group world interfaces by functionality:

  • Weapon interface allows query of the state of the weapon, change and reload, and then actually use it.

  • Movement interface allows forward/backward and side steps to be performed, as well as turning actions.

  • Physics interface allows the animat to query its internal state: in water, midair, or colliding with a wall.

This approach generally reduces the amount of code required to implement the interfaces. Also, this separation enables you to import different functionality into the AI independently.

The implementation of the world interfaces is called the backend (as far as the AI is concerned). FEAR's framework can be plugged in to arbitrary platforms (for instance, game engines) that implement the backend for the interfaces.

Currently, the recommended platform supported by FEAR is Quake 2. The engine offers a great variety of game types, enabling programmers to develop animats for deathmatch, single player, or even capture the flag. The low-key graphics leave much computational power to the AI. There is tremendous community support for the game, including custom levels and various tools. The entire source code is available, too, making Quake 2 one of the best choices for pure AI development.

Modules

Modules are essentially implementations of AI techniques. When the modules are instantiated within the architecture, they're called components. For example, there is only one rule-based system implementation (module), but different rule-based behaviors can be used for movement and tactical decisions (components).

Interfaces

The module interfaces are purposefully made high level. Only the core functionality is exposed by the interfaces (for instance, movement requests). This approach emphasizes the purpose of the module, which helps understanding and the design.

Such interfaces have many advantages in terms of modularity—just as in software development in general. Essentially, the implementation can be completely abstracted from the other components, which reduces dependencies.

Many AI techniques have similar capabilities, such as pattern recognition, prediction, function approximation, and so on. This functionality can often be expressed as one concise interface, but implemented in different ways.

Data Loading

Special interfaces are used to store data on disk. These interfaces are also specified formally, so the meta-programming tools generate functions that save and load data from disk. The low-level details of the storage are thereby handled automatically. The programmer is only responsible for postprocessing the data as appropriate after it has been loaded.

Dependencies

Each module may import specific interfaces. Conceptually, this means the module depends on other implementations to provide its own functionality.

At runtime, this translates into nested components. The internal components are called on when their output is needed to produce the final result. For example, nested components could be used to implement a subsumption architecture for navigation, or even a voting system handling combat—as explained in the preceding chapter.

Flexible Architecture

FEAR supports entire architectures, defined as hierarchies of components. A hierarchy is the most generic type of architecture, because both monolithic and flat can be considered a specific subtype.

Each component has access to its children. (This access is called the scope of the component.) FEAR's dynamic C++ framework initializes the components automatically during initialization, so none of the standard code to import interfaces needs to be written manually (as with DirectX).

At the time of writing, all forms of arbitration (independent, suppression, combination, sequence) are supported indirectly; the programmer can implement each as modules in a customized fashion.


Creating an Animat

The process of creating an animat in FEAR is threefold, as described in this section.

Description of the Architecture

Create a file with the description of the architecture. This specifies which components the brain of the animat needs and other recursive dependencies for those components.

Generating the Source Code

To create all the project files, we need to process this architecture definition with the toolset. The resulting animat should compile by default, effectively creating a brain-dead animat!

Adding behaviors to the animat involves adding code to a few files—usually those with "to-do" comments inside them. Other generated files are managed by the toolset (stored in the Generated folder of the project) and should not be edited manually; their content may disappear when the tools are used again.

Preparations for the Game

The compiled files need to be accessible by the game engine. This involves copying the brain dynamic link library (DLL) into the correct directory, along with a descriptive file to tell the framework about the architecture required. All the data files for the animats are stored in their own directory, too.

Installation Note

Each of the animats can be downloaded separately, or in a complete package. The full source is available as well as the compiled demos. It's best to start by running the demos to get a feel for the platform. The instructions for installing the tools and building each animat are detailed on the web site at http://AiGameDev.com/.

Ref : By Alex J. Champandard

Architectures Designing (game) AI

Architectures
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).

Components
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.

Another consequence of the black box paradigm is that you can use other components during implementation. These components are nested inside others. This is the epitome of modularity in AI.

Organization
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.


Monolithic architectures include only one component.

Flat architectures have many components in parallel.

Hierarchical models have components nested within others.

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.)

Decomposition
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:

Structural decomposition splits the solution according to the function of each component. For example, there may be a component responsible for movement, and another for handling the weapon. These are different functions.

Behavioral decomposition is based on the distinctive activities of the system. These can be understood as different modes such as hunting, fleeing, collecting ammo, or celebrating. Different components would handle these behaviors.

Goal decomposition uses the overall purpose of the system to determine how to split it into components. In game AI, goals depend on the behavior (for instance, finding a weapon). Although goals do not provide clear policies for decomposing the problem, they are always a criteria in the decisions [Koopman95].

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.

Arbitration
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:

Independent sum essentially connects each component to different outputs so no clashes can occur.

Combination allows the outputs of different components to be blended together to obtain the final result.

Suppression means that certain components get priority over others, so weaker ones are ignored.

Sequential arbitration sees the output of different components alternating over time.

There really is no right or wrong method of arbitration. Each of these methods is equally applicable to computer games.

Examples
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.


Subsumption
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 System
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.
Ref : By Alex J. Champandard

Reactive Techniques in Game Development

Reactive Techniques in Game Development
Just like the behaviors, reactive—or reflexive—techniques have many advantages. In fact, reactive AI techniques have been at the core of most games since the start of game development. As explained, these techniques are often enhanced to provide non-determinism, but this can often be simplified into a deterministic mapping.

Advantages in Standard Game AI
The major advantage of reactive techniques is that they are fully deterministic. Because the exact output is known given any input pattern, the underlying code and data structures can be optimized to shreds. The debugging process is also trivial. If something goes wrong, the exact reason can be pinpointed.

The time complexity for determining the output is generally constant. There is no thinking or deliberation; the answer is a reflex, available almost immediately. This makes reactive techniques ideally suited to games.

Success stories of such approaches are very common, and not only in computer games. Historically, these are the most widely used techniques since the dawn of game AI:

Scripts are small programs (mostly reactive) that compute a result given some parameters. Generally, only part of the programming language's flexibility is used to simplify the task.

Rule-based systems are a collection of "if...then" statements that are used to manipulate variables. These are more restrictive than scripts, but have other advantages.

Finite-state machines can be understood as rules defined for a limited number of situations, describing what to do next in each case.

These standard techniques have proven extremely successful. Scripts essentially involve using plain programming to solve a problem (see Chapter 25, "Scripting Tactical Decisions"), so they are often a good choice. Rule-based systems (covered in Part II) and finite-state machines (discussed in Part VI) can be achieved with scripting, but there are many advantages in handling them differently.

Advantages for Animats
The reactive approach also has benefits for animats, improving learning and dealing with embodiment extremely well.

Embodiment
With embodiment, most of the information perceived by the animat is from the surroundings, which needs to be interpreted to produce intelligence. Reactive behaviors are particularly well-suited to interpreting this local information about the world (as animals have evolved to do).

Also, it's possible to make the reactive behaviors more competent by providing the animat with more information about the environment. Thanks to their well-developed senses, humans perform very well with no advanced knowledge of their environment. Instead of using better AI, the environment can provide higher-level information—matching human levels of perception. Essentially, we make the environment smarter, not the animats.

Learning
Most learning techniques are based on learning reactive mappings. So if we actually want to harness the power of learning, problems need to be expressed as reactive.

Additionally, it's often very convenient to teach the AI using the supervised approach: "In this situation, execute this action." Reactive behaviors are the best suited to modeling this.
Ref : By Alex J. Champandard

AI Development Process

AI Development Process
Developing AI is often an informal process. Even starting out with the best of intentions and ending up with the perfect system, the methodology will often be left to improvisation, especially in the experimental stages. In fact, most developers will have their own favorite approach. Also keep in mind that different methodologies will be suited to different problems.

In a somewhat brittle attempt to formalize what is essentially a dark art, I developed the flow chart shown in Figure 2.1. This flow chart describes the creation of one unique behavior. Jumping back and forth between different stages is unavoidable, so only the most important feedback connections are drawn.

Figure 2.1. An interpretation of the dark art that is the AI development process.


Hopefully, Figure 2.1 makes the process seem less arbitrary! At the least, this method is the foundation for the rest of this book. We'll have ample opportunities to explore particular stages in later chapters, but a quick overview is necessary now.

Outline
The process begins with two informal stages that get the development started:

The analysis phase describes how the existing design and software (platform) affects a general task, notably looking into possible restrictions and assumptions.

The understanding phase provides a precise definition of the problem and high-level criteria used for testing.

Then, there are two more formal phases:

The specification phase defines the interfaces between the AI and the engine. This is a general "scaffolding" that is used to implement the solution.

The research phase investigates existing AI techniques and expresses the theory in a way that's ready to be implemented.

All this leads into a couple of programming stages:

The development phase actually implements the theory as a convenient AI module.

The application phase takes the definition of the problem and the scaffolding, using the module to solve the problem.

This is where the main testing loop begins:

The experimentation phase informally assesses a working prototype by putting it through arbitrary tests that proved problematic in previous prototypes.

The testing phase is a thorough series of evaluations used only on those prototype candidates that have a chance to become a valid solution.

Finally, there is a final postproduction phase:

The optimization phase attempts to make the actual implementation lean and mean.

These phases should not be considered as fixed because developing NPC AI is a complex and unpredictable process. Think of this methodology as agile—it should be adapted as necessary.

Iterations
These stages share many interdependencies, which is unavoidable because of the complexity of the task itself (just as with software development). It is possible to take precautions to minimize the size of the iterations by designing flexible interface specifications that don't need changing during the application phase.

The final product of this process is a single behavior. In most cases, however, multiple behaviors are required! So you need to repeat this process for each behavior. There is an iteration at the outer level, too, aiming to combine these behaviors. This methodology is in spirit of nouvelle AI, which is directly applicable to game development.

Luckily, it's possible to reduce the number of outer iterations by using a clever AI architecture design, which is discussed in the next chapter.
Ref : By Alex J. Champandard

Required Background

Required Background
Before discussing the process of creating such animats in games, it seems appropriate to list what skills are required to develop AI. This book assumes the reader has a few years of programming experience, but creating AI is an interdisciplinary process. The AI part of the software sits at the crossroads between the game engine and the AI data; the AI engineer also mediates with the other programmers and designers.

Programming
An important skill needed by an AI developer is programming knowledge. AI can get relatively complex in places, but a reasonable knowledge in programming can help significantly. In fact, most programmers would be able to produce rudimentary NPCs without much AI knowledge. That said, programming is rarely the bottleneck of an AI developer.

Note

In this book, the theory behind the algorithms is described in pseudo-code for the sake of simplicity. As such, it's possible to implement them in almost any language. Because the code available on the web site is C++, most of the programming idioms focus on that language.



Computer Science
Most programming skills are accompanied with elementary knowledge of computer science. Being comfortable with data structures (for example, lists, trees, and graphs) and basic algorithms is a tremendous help for creating AI, too. Don't worry, however; the necessary principles are covered by the book.

Mathematics
Math is essential improving as an AI programmer. Just like 3D programmers need knowledge of geometry to push the application programming interface (API) to its limits, mathematical understanding enables AI programmers to integrate cutting-edge theory from academia, and to optimize the theoretical aspects of each algorithm. It is possible to avoid the math by relying on pseudo-code and example implementations, but a more permanent solution requires that you not shy away from theory. This book gives ample opportunities for dedicated readers to understand the theory and make a step toward academic papers.

Software Engineering
Designing an intelligent system that can control a creature in a complex 3D world is no easy task. Applying common design patterns to the problem certainly helps simplify the system. This book explains the design patterns commonly used in AI and how they can be adapted to different problems.

Game Engine Architecture
Preliminary steps need to be climbed before the actual AI development itself can start. This generally involves preparing the engine architecture so that it can support AI. In most cases—especially when human players are already supported—this job is straightforward.

As a good framework is in place, it's actually possible to code AI without knowing too much about the underlying game. Chapter 4, "FEAR: A Platform for Experimentation," presents the framework used as the basis of this book, which is extremely useful from an educational or experimental point of view.

In a professional environment, groups of developers work together to build the game architecture. Experienced developers (those who know best?) can thereby assist the integration of the AI in design and implementation. AI developers can rely on other programmers to assist them when necessary.
Ref : By Alex J. Champandard

A Modern Approach

A Modern Approach
Traditionally, AI is viewed as a code fragment that manipulates data. These small programs are generally known as agents. These agents are like software systems; they have layers. One central processor acquires information, processes it, deliberates a bit more, and executes some actions. Acting on behalf of the user, agents solve narrow problems with a human quality.

This view is problematic for building large and intelligent systems; the theory scales up poorly, and does not transfer from lab examples to other domains. Nouvelle AI rejects such focused AI, instead believing that true intelligence is about performance in the real world.

The 1980s witnessed a revolution based in robotics that eventually shook most of AI. The ideas, initially from Rodney Brooks (1986 and 1991), proposed using a different model for intelligence, allowing working systems to be built with more suitable methodologies [Brooks86, Brooks91].

This leads to studying embodied systems situated in realistic environments (such as robots or game characters). To solve the problems that occur in practice, new approaches to AI are needed (such as the behavior-based approach).

Brooks advocates that no central processor has to deliberate every move; instead, the system is distributed into behaviors that react instantly to their environment. Using this reactive approach, full systems are built up incrementally, by testing each set of components.

This revolution has continued since, notably influencing a group of researchers to focus on the simulation of adaptive behavior (SAB). The first conference was organized back in 1990 by the International Society for Adaptive Behavior [ISAB02].

"Every two years, the Animals to Animats Conference brings together researchers from ethology, psychology, ecology, artificial intelligence, artificial life, robotics, engineering, and related fields to further understanding of the behaviors and underlying mechanisms that allow natural and synthetic agents (animats) to adapt and survive in uncertain environments."

Animats are essentially synthetic creatures that live within a virtual environment. Because they are embodied, they interact with the world using only their body—making them fully autonomous. Animats can also adapt to their environment by using a variety of learning algorithms. But are these approaches suitable to games?

Animats in Games
Many game players, and even developers, would consider animats the "proper" way of dealing with AI NPCs. Wouldn't it be impressive to have each bot in the game as an accurately simulated creature? As far as game AI techniques are concerned, this nouvelle game AI approach is the opposite of standard techniques.

Are Animats Applicable to Games?
The major goal of game developers is believability; the accuracy of the simulation itself is not a concern. Still, animats have much to offer to computer games. By simulating the creatures accurately, fewer aspects of the behaviors need to be "faked." Because the AI is genuine, it can handle situations unforeseen by designers.

Already, similar (diluted) ideas are starting to leave their mark on the industry. Recent trends in game AI lean toward embodiment, notably in the simulation of sensory systems (Thief), the addition of noise to some actions (Quake 3), and even perceptual honesty (Black & White).

By extrapolating this progression, the result is fully embodied animats. This will certainly happen within a few years, but whether this is three or ten years away is anyone's guess. In the mean time, preliminary research in synthetic creatures shows that properties of animats, such as embodiment, actually lead to more genuine behaviors, which in turn improves believability [Isla02, Blumberg01].

As far as software engineering is concerned, the animat approach has much to offer from a design point of view. Embodiment is an elegant way of modeling the role of the AI in the game engine. The formal definitions of interfaces between the body and the brain is good practice (notably separating the AI from the logic and simulation). As for developing AI behaviors, animat and behavior-based research has revealed many ways of dealing with experimentation, such as incrementally building the AI system.

How Do We Create Animats Effectively?
How can such radical ideas be applied within game engines? Is it even feasible given time and computational constraints? As a matter of fact, it's more than feasible; different aspects of animats have already been demonstrated in popular games. This is the crucial observation; it's possible to integrate properties of animats into the standard AI design, which enables us to compromise between typical game AI approaches and the animat approach.

To date, no genuine animats have been shipped in commercial implementations, but this isn't too far in the future. Some animat prototypes have closely matched the skill level of standard game bots. In some cases, animat prototypes prove to be more reliable and realistic than game bots.

Instead of games using standard agents, animats can in fact be more efficient in many respects. The interaction of an animat with its environment is formalized so it can be optimized in the most appropriate format (for example, passing messages, function calls, shared variables). Learning techniques can minimize the processing power used to perform a particular behavior.

A Healthy Compromise
The animat approach has many benefits, regardless of policies on learning or embodiment. These advantages include improvements in the design and in the development pipeline. Naturally, genuine undiluted animats have the potential to be extremely successful within games, and the rest of this book investigates this noble goal. However, far from being on an idealistic crusade, this discussion attempts to identify places where the animat approach isn't appropriate in games, while trying to extract its advantages.

The remainder of this chapter investigates further these issues by tackling the two major characteristics of animats separately (embodiment and learning), looking into their potential benefits and pitfalls.

Embodiment
Embodiment is a different way of dealing with in-game creatures. Typically, NPCs are just agents: "smart" programs that manipulate data, like chatbots or web spiders. Such entities are purely virtual, whereas embodied agents live in a simulated world and have a synthetic body. Regardless of whether they are 2D sprites or complex 3D models, these bodies cannot do some things. Indeed, the bodies are influenced by the physical rules of the world.

Definition

An embodied agent is a living creature subject to the constraints of its environment.


Because the bodies of animats are physically constrained, the actions of their brains are limited. In general, the possible actions that can be executed by the body—and hence the AI—are restricted to the subset of actions consistent with the laws of the simulation. These actions often turn out to be physically plausible. However, embodiment generally does not limit what the AI can achieve; it just restricts how it is done.

Some characters in games represent human players who get to control the bodies. Many other characters are synthetic, similarly controlled by the computer. The AI itself can be understood as the brain, and the body offers the means for interaction with the game's physics and logic.

Consider a classical example: a standard agent can change its position itself to reach any point in space. An animat—with embodiment—needs to move itself relatively to the current position, having to actually avoid obstacles. It will not even have the capability to update its position directly. Nowadays, many games do this, effectively enforcing the simplest form of embodiment.

Actually simulating the body enables developers to add biologically plausible errors to the interaction with the environment. Errors might be present when information is perceived from the environment and in the actions. For example, animats could have difficulty perceiving the type of characters in the distance. There could even be parametric noise in the turning action, so aiming is not perfect (as with humans). Including such biologically plausible details allows the NPC to behave more realistically.

Motivation
Increasingly, agents with full access to the game data are becoming inconvenient. Having no restrictions on the reading and writing of data often results in internal chaos within the design of the engine. Because there is no formalized interface, the queries for information are left to the client (AI). Developers are actually starting to impose restrictions on these queries, notably limiting the subset of information available to the AI, such as preventing bots from seeing through walls.

For large games (such as massively multiplayer online games), it's essential to develop such hooks for the AI in the game engine. Using formal interfaces is essential because doing so allows the server to be distributed so that agents can reside on different machines if necessary. The AI can thereby be fully separated from the game logic and from the simulation of the world (physics).

So it seems formal interfaces, such as those that the AI Interface Standards Committee is attempting to define [AIISC03] will become increasingly important. Whether these can be standardized is another issue, but embodiment provides useful guidelines for drafting custom interfaces as the exchange of information between the body and the brain. Sensory data flows from the body to the brain, and actions are passed from the brain to the body.

This book anticipates the trend and uses such formal interfaces. In terms of code complexity, major improvements result from separating the acquisition of the data from its interpretation. As for efficiency, using embodiment often allows better optimizations.

Technology
With a formalized interface, the engineer can easily decide on the most appropriate format to communicate data to the AI—and do so mostly transparently using mechanisms such as messages, callbacks, abstract function calls, shared variables, and so on. Because a standard interface exists, its implementation can be particularly optimized for speed using the most appropriate mechanism.

Implementing embodiment efficiently requires a few common techniques to be used. These tricks are the major reasons why formal interfaces can actually outperform an AI implementation with direct access to the data:

Lazy evaluation means that no information is gathered from the world until it is actually requested by the AI. This prevents redundant computation.

Event-driven mechanisms mean that the AI does not need to check regularly for data. When relevant information is available, the AI is notified in an appropriate fashion.

Function inlining still allows the interfaces to be separated, but also optimized out by the compiler (if necessary). This is suitable for small functions, but larger ones benefit from being separate.

Custom optimizations can be used often to speed up the queries. By using spatial partitions of the world, only necessary information can be checked by visibility to gather the information.

Batching refers to collecting many queries or actions so that they can be processed later. Within the engine, the implementation can then decide the best way to deal with them to maintain memory coherence.

Used appropriately, these techniques can significantly reduce the cost of exchanging information between the AI and the engine, and make formal interfaces and embodiment a desirable property.

Learning
Learning is the second property of animats and characteristic of nouvelle game AI. Instead of the designer crafting fixed behaviors, the process is automated by adaptation and optimization techniques.

Definition
Regardless of their actions in the world, living creatures are constantly presented with a flow of sensory data. Biological animals are capable of assimilating this information and using it to adapt their behavior. There are no reasons why animats are not capable of learning; they too are presented with a stream of information from the environment, which they can interpret.

"Learning is the acquisition of new knowledge and abilities."

This definition identifies two kinds of learning: information and behavior. As far as the result is concerned, there is little difference between the two. Indeed, it's often possible to learn knowledge as a behavior; conversely, behaviors can be expressed as knowledge. So intrinsically, both these subtypes of learning can be considered identical in outcome.

In practice, a distinction exists between the two. A part of the animat does not change (phylogenetic), and another part can be adapted (ontogenetic). If the AI system itself is changed at runtime, the adaptation is called direct, and indirect otherwise [Manslow02] (Again, there's a fine line between the two.)

Motivation
Two main scenarios encourage the use of learning in computer games. Different terms are used for each of these cases—optimization and adaptation, respectively—during the development and within the game:

Optimization is about learning a solution to a known puzzle. This is essentially used to simplify the development process (offline) because learning might produce a better answer to the problem in less time than the manual approach.

Adaptation is about learning in unknown situations, and how best to deal with them. This scheme requires the AI to continuously update itself—to deal with different player styles during the game, for example (online).

Fundamentally, these scenarios may be considered as the same problem, too! Indeed, the exact same techniques can be used to perform either. However, both learning schemes are suited to different domains, implying different AI techniques are more appropriate.

The design of the AI can exploit these different types of learning, too. Optimization is often much easier to integrate into the development pipeline as a useful tool for creating believable characters. Adaptation, on the other hand, has repercussions within the game, so it requires a few more precautions in the design.

Technology
Many AI techniques can be used to perform both varieties of learning: neural networks, decision trees, genetic algorithms, reinforcement learning, classifier systems, and so forth. These different solutions are discussed throughout this book. From a conceptual point of view, there are the following four categories of algorithms:

Supervised learning algorithms need to be presented with examples. Apart from assimilating facts or behaviors, they can recognize patterns in the training samples. This allows the learning to generalize, and perform well on unseen examples.

Reinforcement learning evaluates the benefit of each action using a scalar number, instead of providing specific examples. This reward feedback is used to adapt the policy over time.

Evolutionary approaches provides scalar feedback for a sequence of actions, evaluating the fitness of episodes instead of giving a continuous reward.

Unsupervised learning does not rely on direct training. Instead, the designer provides high-level guidance, such as a performance metric.

Naturally, there are often ways to integrate these approaches—or even use one approach to solve the other (for example, self-supervision). These design issues come into consideration after the problem is identified.

Given techniques that learn (either supervised or not), the animats can be taught in different ways:

Teaching involves humans providing a set of examples that help the animat to behave until it's managed to understand what to do.

Imitation allows the animat to copy another player, who is usually human. It can thereby learn its behavior from a third-party experience.

Shaping sets up successive trials from which the animat can learn. After the animat learns to accomplish simple tasks, more complex ones are presented.

Trial and error places the animat in its environment and expects it to learn by trying out all the different approaches on its own.

Each of these methodologies can be followed during the development stage or during the actual game. Although these different approaches are presented in a practical fashion throughout this book, Chapter 35, "Designing Learning AI," specifically covers general technical and design issues.

For Skeptics
The key to successfully integrating learning within games is to use it with consideration. Some things are just not suited to learning. There will always be a need for "static" AI, even if it just acts as the glue between adaptive components.

The benefits of learning are undeniable! Learning enables the developer to save time whenever possible, and to add to the game's appeal by bringing ambitious designs to life.

However, it's debatable whether learning is capable of performing reliably within games. One of the major advantages of learning techniques is that they can be combined with other solutions. This enables the designer to modify or override the results of the learning. This book covers ways to indirectly control the learning, but directly supervise the outcome.

Finally, the fact that techniques can be applied to learning facts or behaviors, online or offline, and with so many different methodologies undoubtedly means that one flavor is suitable for every purpose.
Ref : By Alex J. Champandard

An Engineer's Perspective

An Engineer's Perspective

Relying on a solid design is important for game developers. However, creating an AI system requires a more pragmatic approach.

Entertainment and realism are undoubtedly goals for game developers. In fact, these objectives are often worshipped—as if placed on a pedestal. Such an attitude is often counterproductive, leading to comments such as these:

"We don't need feature x, we're looking for entertainment."

"Do it first, then I'll judge if it's realistic enough."

This attitude is acceptable from a player's point of view, but the goal is more cooperation within the development team! Thinking of entertainment and realism as the Holy Grail really dodges the issue. English is ambiguous, and leaving these values as fuzzy terms such as entertainment and realism certainly doesn't help understanding. By not even trying to define these terms, the development teams—and particularly the AI engineers—are sentencing themselves to hours of forced labor, fastidious tweaking in the search of what closely resembles an illusion.

The aim of game designers and AI programmers is to bring these objectives onto the dissecting table and divide them into small parts. These atomic concepts are easier to identify and analyze, revealing what entertainment and realism are all about. Engineering relies on the capability to quantify goals; removing all ambiguity from these goals makes it possible to refine the design into specific NPC behaviors. Under these conditions, the development team can perform at its best.

Ref : By Alex J. Champandard

AI in Game Programming

AI in Game Programming

In practice, the purpose of the AI system in the game engine is to control every aspect of the NPC. For example, within computer games—and not only first-person shooters—the AI must provide the following:

  • Primitive behaviors such as picking up items, pressing switches, using objects, performing purposeful gestures, and so on

  • Movement between areas of the game environment and dealing with obstacles, doors, or platforms

  • Decision making on a higher-level to decide which actions are necessary for the NPC to accomplish its tasks, and in what order

To develop systems capable of providing such control, a minimal amount of technology is necessary. Although standard programming techniques allow the implementation of intelligent NPCs, techniques from the field of AI can provide the following:

  • Elegant solutions for explicit control

  • Technology to support implicit control efficiently

Compared to standard scripting techniques, AI technology can be computationally more efficient and can generate better quality behaviors. Such improvements are possible thanks to various aspects of AI, discussed throughout this book:

  • AI techniques providing functionality such as motor control, pattern recognition, prediction, or approximation

  • Design patterns inserted at a system level to assemble these components together

  • Methodologies used to design and test behaviors within realistic environments

These AI methodologies allow the synthetic characters to come to life, but they also serve a particular purpose in games. Game development has common requirements that need to be taken into account when engineering the AI system. Two properties are important in games:

  • Entertainment— The AI can call upon the skills of human players. This involves providing them with various challenges and testing different abilities with increasing levels of difficulty. The AI also can play on emotions to increase entertainment value. The AI can trigger amazement by arranging cool events, or fright by building scary atmospheres.

  • Believability— The AI characters can improve immersiveness by doing their job in a way that does not distract attention from the mission of the game. As for realism, AI allows each individual NPC to behave in a plausible way that seems logically feasible to human players.

In summary, AI game development is about providing control to NPCs to produce entertainment (assisted by believability or realism). The next chapter takes the engineer's approach, using AI technology to assist in the creation of systems capable of such tasks.

Ref : By Alex J. Champandard

The State of Game AI

The State of Game AI
Remember the dawn of 3D graphics in games? Only a few companies were willing to take the plunge: the proverbial penguins. Some mastered the subject, but the games still had many bugs. Visual artifacts slowly disappeared, eventually becoming unacceptable. Nowadays, even when new technologies are introduced, they are integrated seamlessly; the development pipeline is well established. There is much experience in the field, assisted by a strong hardware industry.

In AI, we're still in the first stage. Common techniques that have been used over the years—such as scripted behaviors and A* pathfinding—could be compared to 2D graphics. Although improvements still need to be made, these two techniques have matured tremendously; scripted behaviors and A* pathfinding in most AI systems nowadays don't make obvious mistakes. This is an amazing feat. We've even reached a stage where such AI techniques shine in some games (for instance, Unreal Tournament 2003 and Return to Castle Wolfenstein).

However, AI (both kinds) is set to revolutionize the way we make games. AI technology is modernizing the development, and intelligent creatures are transforming game design.

Technological Revolution
Some companies have ventured into more advanced technology borrowed from the field of AI (for example, decision trees or reinforcement learning). In these applications, the superior AI generally achieves similar design goals, only the means of production change. (For instance, Colin McRae Rally 2 uses learning and neural networks, which means the AI doesn't have to be programmed manually [Hannan01].) Despite the standard gameplay design, the game engine needed to be adapted to accommodate the AI techniques and the development process (usually involving less scripting). This is the technological AI revolution in the trenches.

Nevertheless, a certain amount of skepticism still exists within the game-development community—and justifiably so. Why is better AI technology actually needed? Given a standard design, does it help the development in any way? The answer is that AI techniques are not a requirement per se. There's no need for awesome technology if it produces the same gameplay! In development, we could do fine without AI; in fact, most professional game programmers have the skill to do without any form of AI if they so desire.

However, AI technology has the potential to improve the development process by boosting efficiency, speeding up design and experimentation, and generally improving the quality of the final product—when chosen in the right context. We spend the rest of this book on this subject, learning from successful prototypes and making mistakes.

Design Revolution
Few other games use modern AI to actually push levels of NPC intelligence beyond designs possible with "standard" AI (that is, scripts and pathfinding). Together, the stronger AI techniques and adventurous designs have led to obvious improvements in gameplay. For example, Black & White's gameplay revolves around the interaction with an intelligent creature with learning abilities.

On the whole, these more intelligent creatures have had a great reception from the press and the public (including AI enthusiasts). Capturing this amount of attention has only been possible with ambitious designs, which the game community now seems to crave. This is the AI design revolution, and it's just starting.

There's a calm certainty that a golden age in AI NPC is looming, despite some hesitations about how to make it happen. There is little doubt that the AI revolution will be mainly design driven. The savings generated by a better AI production pipeline compare meekly to the lucrative market for AI games. This market in itself is enough to drive any progress.

The technology to bring these AI designs to life has been available for years—if not decades. Granted, the necessary processing power and experience have been lacking anyway. Only recently has it matured enough; nowadays, practical wisdom has increased dramatically and computational power is less of a problem. In this book, we explore such techniques capable of bringing AI designs to life efficiently.
Ref : By Alex J. Champandard

Overview of Artificial Intelligence

Overview of Artificial Intelligence

To a great majority of the population, AI is the brain behind powerful cybermachines—the kind found in sci-fi films. To software developers, it's a buzzword for technology that repeatedly failed to deliver on its promises throughout the twentieth century. To academics, it's a seemingly endless source of challenges and excitement.

But how is AI relevant to game developers?

Artificial intelligence has two separate meanings; both types are beneficial to game development:

  • First, AI is a form of intelligence that has been artificially re-created using machines.

  • Second, AI is a set of academic techniques, research methods, and problems that fall into one sub-branch of science.

Machine Intelligence

Historically, it seems "intelligent" is a term mankind found to describe itself. Intelligence is just a human ability that distinguishes us from animals or plants. Nowadays, intelligence is commonly used as a distinguishing trait among humans; everyone implies that "intelligent" means an especially clever person.

Universal Ability

Conceptually speaking, a generic form of intelligence undoubtedly exists. Humans and animals have small subsets of this ability, particular instances of universal intelligence. Humans seem to have inherited a larger portion of this universal skill. However, our biological intelligence lacks some characteristics of universal intelligence (for instance, exhaustiveness and neutrality).

Most computer-science researchers assume that biological intelligence can be reproduced, and that intelligence is not exclusively human. This statement essentially gifts machines with a subset of universal intelligence. AI can therefore be seen as an artificial counterpart of the intelligence produced by our biological brains. Naturally, engineering produces different results than evolution, explaining why AI has different properties than human intelligence (for instance, thoroughness). AI is another instance of universal intelligence.

It's difficult for us to understand universal intelligence because we have few advanced examples. However, we can try to define human intelligence.

Definition of Intelligence

For lack of a better definition, intelligence is a set of skills that allows humans to solve problems with limited resources [Kurzweil02]. Skills such as learning, abstract thought, planning, imagination, and creativity cover the most important aspects of human intelligence.

Given this wide variety of abilities, there is no unique problem to put them all to the test. Animals are intelligent in some ways: they are capable of surviving and managing their time, for instance. Insect colonies can adapt quickly to their environment to protect their nest. Popular IQ tests are very specific and require training more than the gift of "intelligence." These tests measure what is known as narrow intelligence.

Each problem requires different abilities. We're particularly interested in a problem that can become surprisingly complex—behaving autonomously within a realistic virtual environment. Playing games isn't just about wrist power and rudimentary reflexes! Games present interesting challenges because most humans find entertainment in solving such problems.

Computer game AI is an artificial version of this human ability. AI controls computer characters purposefully, meaning that actors and background cast don't have to be hired (as they must be in films). We'll refer to this first interpretation of AI as nonplayer character (NPC) intelligence, which implies that it's machine intelligence.

Field of Science

The second interpretation of AI is as a set of technologies. The definition on the introductory page of the AI Depot has served well over the past couple years:

"Artificial intelligence is a branch of science that helps machines find solutions to complex problems in a more human-like fashion. This generally involves borrowing characteristics from biological intelligence, and applying them as algorithms in a computer-friendly way."

AI algorithms can be applied to practically anything—they're not just limited to re-creating human intelligence. For instance, they could be applied to managing a production chain, or perhaps to pattern recognition in medical data. The common properties of AI techniques and biological intelligence (for instance, learning or abstraction) make these techniques part of the field of AI.

As a discipline, AI sits at the crossroads of many subjects (for instance, computer science, psychology, and mathematics). These subjects all share a significant body of common knowledge. Given such a wide variety of influences, it's difficult to say what belongs to AI and what doesn't. It seems to vary from year to year, depending on the popularity of each field. There is an increasingly large overlap with other disciplines anyway, which is a good thing; it reveals the maturity of the field and its consistency with other theories.

Historically, AI tended to be very focused, containing detailed problems and domain-specific techniques. This focus makes for easier study—or engineering—of particular solutions. These specific techniques are known as weak AI because they are difficult to apply outside of their intended domain.

This weakness of AI has become a roadblock—one that can't be driven around. Weak AI has been extremely successful in many domains, but human experts need to apply it manually. When trying to assemble techniques together to solve bigger problems, it becomes evident that techniques are too focused.

This is one reason why we need AI engineers. If AI were good enough, programmers wouldn't be needed. This is (at least) a few decades off, however; until then, we need humans to develop the systems. This is the case for AI technology in computer games, too; rest assured, programmers are still necessary!

Ref : By Alex J. Champandard