Grail Overview

Many traditional approaches to AI are implemented in the form of if something then do something. You can think of this workflow as declarative AI, because you explicitly declare what a bot should do.
In Grail, however, the underpinning idea is to equip a bot with options and let a reasoning mechanism choose one of them at particular moment.

A behavior represents the notion of a generalized action performed in the game. Any interaction of the bots in the game, which are controlled by Grail, should be implemented using the Behavior class. By interaction we mean things the bot really do and affects (changes) the game environment, e.g., running or shooting in an FPS game. Once the logic is implemented as Behaviors, you can use the Grail intelligent reasoning capabilities. Behaviors can be dynamically instantiated or reused from a common pool.

We recommend thinking about the possible options first and then design behaviors. The more modular/generic the behaviors are, the more flexibility you get in terms of testing various approaches to AI. For instance, you may tinker with various Utility Systems, Planners and Abstract Games and all of them may use the same behavior classes as output.

In the previous section we introduced Behaviors - things bots can do. Grail comes with mechanisms that define logic of selecting the most appropriate behavior at particular moment in a game. Let us call this logic of computing the right behavior (the behavior selection) as an AI algorithm. The AI algorithms are wrapped inside specializations of a class Reasoner. A Reasoner is an easier-to-use component on top of an algorithm that can be assigned to entity (described in the next section).

Reasoner provides a common interface for selecting behaviors and it is seamlessly integrated into the Grail update loop. However, you may use the algorithms directly by their interface classes, if you prefer so as well as creating custom Reasoner.

Reasoner specializations:

Interfaces of the algorithms:

Reasoners are assigned to AIEntity. You can think of the AIEntity as a separate thing that executes a single behavior at any given time from a number of possible behaviors.

Grail provides a built-in mechanism for exchanging data between entities based on blackboards. Each entity manages one private Blackboard and may share any number of Blackboards with other entities.

Allows for context-dependent behavior selection that is managable even when dealing with many possible options. The system uses instanced behavior approach, which allows it to distinguish betweet differently parametrized versions of the same behavior. The system comes with many predefined mathematical curves, but also allows the user to define his own - either in code or using hand-crafted cubic splines.

Features:

Particularly useful for

It is based on the GOAP approach (Goal Oriented Action Planning). Planner lets your AI agents devise long term behavior sequences to achieve various goals, instead of relying only on current world state and performing only reactive actions. Flexible state and action representation structures enable the planning algorithm to take into account any number of parameters and interdependencies of world objects and allows for easy translation from game-space to plan-space and the other way around. This method has been used in games such as F.E.A.R.® or Killzone 2®.

Features:

Particularly useful for

This is a simulation based technique that relies on stochastic exploration of the game tree to choose actions that have the highest probability of reaching the goal. Thanks to the possibility of simulating decisions of other agents it lets your AI predict player behavior and act accordingly. This method requires a simulation model, which is is done in code and it is usually either a simplified version of the actual game or a subset of it.

In addition, Grail is equipped with tools that allow to run the simulations (offline) as time-consuming task and save the results as a Decision Tree. Such a tree is rapidly fast to use in the game.

Features:

Particularly useful for

The final playing model incorporated in Grail is scripting with additional automatic optimization built in. Naturally, the biggest advantage of scripts is full control given to game developers over characters behavior. The biggest downside is lack of automatization and emergent adaptive behavior that is inherently featured in Planning and Abstract Games and to less extent in Utility AI. Thus, scripting is included in Grail mostly to complement other methods in corner cases.

You may mark some of their script parameters as optimizable. Such parameters are typically involved in making a decision in the game such as, e.g., shooting angle or army strength. We provide an Evolutionary-Algorithm-driven pipeline maintaining a population of scripted players. It consists of an Arena, where players are pitted against each other, which can be distributed among many computers and optimization scenarios. A scenario is essentially a subset of a game with starting state, terminal conditions and scoring (fitness) functions. The Arena attempts to find the best realizations of parameters with respect to given scoring function. Such parameters can appear anywhere in the script code.

Features:

Best used for: