The longer story:

There is a lot of research in artificial intelligence (AI) about the design and implementation of cognitive agents that are based on some form of logical reasoning. Each of the existing approaches provides a number of features for specifying the agent behavior including beliefs, goals, sensing outcomes, preferences, probabilities, imperative or declarative language programming constructs, reactive rules, finding linear and nonlinear plans, and more. This should be good news since it means that there is a wide variety of options for anyone interested in implementing a cognitive agent. Unfortunately though most of this research is not used in practice despite the sophisticated features that each approach provides and the appealing results about efficiency that usually accompany them. The video game industry is no exception as it is typical for the agents in the game (that is, the so-called non-player characters or NPCs) to be implemented in some scripting language that does not take advantage of research in cognitive agents.

We believe that one of the reasons for this lack of interaction between academia and the video game industry is that from the video game programmer’s point of view it is not easy to identify an AI module that solves a particular problem and embed it as needed into a game engine using an intuitive interface. This is not surprising as the academic approaches for cognitive agents typically presuppose that they have full control over all aspects that are relevant to the agent behavior, not just part of it, insisting that the whole software entity of the agent is programmed in the provided language.

Ideally, the level of abstraction that academia suggests would be the preferred option. That is, it would be great if the video game programmer could specify the behavior of a NPC in a high-level intuitive language similar to English, and then some AI system that is embedded in the game engine would deal with realizing the behavior of the agent in the game. The natural question is then why aren’t there any AI systems embedded in game engines. The obvious answer to this is that typically AI systems are not efficient, sometimes not any close to the level needed for real-time video games. But even if the AI systems were efficient enough we believe that it would still be awkward to embed and use them in a video game. The reason is that most of the AI systems have been designed inside academia without any feedback from the video game industry or some other similar application domain. As a result it is not clear that they actually solve those practical problems that a video game programmer would care about, with respect to specifying and realizing the behavior of the NPCs.

We believe that in order for the video game industry and academia to come closer, a different stance should be adopted. We argue that instead of providing “holistic” approaches to designing and implementing cognitive agents, academia needs to provide simple modules that perform practical tasks and can be used separately as needed by the video game programmer. Note that the most widely used AI technique in the video games industry is A*, a heuristic search algorithm developed in the late 60′s. The use of A* in a video game can be seen as using a simple AI module that deals with the practical problem of path finding. Along the same lines, one of the rare examples that an AI planning technique is used in a video game as a module is the use of STRIPS, a practical system developed in the early 70′s. It is probably not a coincidence that video games tend to use ideas that were developed in the early days of AI research and led to the existing modern AI systems. One way to interpret this is that these early AI modules need to evolve inside the video game industry this time so that the appropriate “holistic” approaches will emerge.

Following this intuition we are currently working in the following directions :

1. We identify a common component of many AI systems that could be used as an AI module in the development of the NPCs in a video game. This component, namely the Temporal Projector, keeps track of the state of the game world as actions take place, and is able to answer queries about the present and the future, e.g., “is there a way to open the red door”? We suggest that an instance of the Temporal Projector can be seen as regular database or data structure that is linked with a particular NPC, and explore the possibility that a simple SQL-based language would be appropriate as an interface for video game programmers that specify the behavior of NPCs.
2. We want to experiment with an implementation of the Temporal Projector in a commercial video game engine to get some feedback on the necessary efficiency that the AI module should have in order to be used in practice. We are currently working on building an NPC that is capable of doing basic planning for some minimal amount of lookahead in Source, the game engine by Valve that is used in commercial video games such as the Half-Life series.
3. Starting from the other end of the gap, we try to identify parts in the implementation of NPCs that could be abstracted as modules, and investigate how existing or future work in AI can provide better solutions than using a regular programming language.  For example, consider the finite state machine that usually specifies the behavior of NPCs that is often implemented as a big block of “if then else” statements. This block of code may abstracted by a slightly more modular rule-based system that achieves the same result in a way that is easier to maintain, debug, and extend.