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