AI Papers, Books, and Conference Publications

I've received some emails from individuals looking for some of my work (specifically my articles and papers on character motion management), so here is a list of some my published works with a brief note and what books/journals/conferences they can be found in - as well as a few extra early game programming works.

The chapters in Game Engine Gems 2, Game Programming Gems 8, and the paper presented at the Artificial Intelligence and Interactive Digital Entertainment Conference 2009 form the three major sources for the some of my work on character movement systems. Together they form a unique approach that combines AI, animation and physics into a unified architecture that provides a description of the background to, principles of, and the development of an approach to implementing a character behavioral system.

For Game Engine Gems 2, I provided a chapter entitled, An Egocentric Motion Management System. The egocentric motion management system (ECMMS) is both a model for agent movement and an application of a behavioral theory. Any game that features agents (e.g., animals, soldiers, or tanks) that move around in a 3D scene has a need for an agent movement solution. A typical movement solution provides mechanisms that allow for an agent to move through a scene, avoiding geometry, all the while executing some sort of behavior. This article discusses not only how focusing on the agent drives the immediate interactions with the environment but also, more importantly, that by gathering some information about the environment during locomotion, we gain the ability to generate spatial semantics for use by the agent’s behavior system. Portions of the ECMMS were used in a cross-platform game entitled World of Zoo (WOZ). WOZ is an animal simulator that requires various zoo animals to move through their environments in an incredibly compelling manner while the  players constantly alter the environment. So the proving ground for this system was in an environment that could be changed around the agents at any particular moment. In addition to detailing ECMMS I also discuss how to build a unified behavioral model that utilizes technology from all three of my character movement articles.

In Game Programming Gems 8, I've written an article detailing the World of Zoo's navigation system's architecture; as well as provided some general thoughts on developing a motion management system. The article is entitled, A Practical Spatial Architecture for Animal and Agent Navigation. This article is a nice bookend to the AIIDE 2009 paper (the Game Gems article provides more concrete insights, while the AIIDE paper is more algorithmic).

Here's a brief introduction to the article: Game literature is inundated with various techniques to facilitate navigation in an environment. However many of them fail to take into account the primary unifying medium that animals and agents use as locomotion in the real world. And that unifying medium, is space [Lefebvre97]. The architectonics of space relative to an animals or agent’s motion in a game environment, is the motivation for this article. Traditional game development focuses on modeling what is physically in the environment, so it may seem counterintuitive to model what is not there, but one of the primary reasons for modeling the empty space of an environment is that it is this spatial vacuum that frames our interactions (be it locomotion or a simple idle animation) within that environment. Space is the associative system between objects in our environments.

This article will discuss this spatial paradigm and the techniques that we used during the development of a multiplatform game, entitled World of Zoo (WOZ). WOZ was not only a challenging project by any standard definition of game development, but also because we desired our animals motion to be credible.


An important aspect of any animal’s believability is that they are not only aware of their surroundings, but that they also move through a dynamic environment (Color Plates 1 and 2 contain examples of WOZ’s environment) in a spatially appropriate and consistent manner. This maxim had to hold true whether the animal was locomoting over land, water or even through air! To help facilitate the representation of our spatial environments we used several old tools in new ways, and in conjunction with a few inventions of our own, we believe we accomplished our goals.




This peer reviewed paper outlines the general philosophy of a unifying paradigm for navigation systems. The paper is entitled, A Unified Spatial Representation for Navigation Systems and was presented at the Artificial Intelligence and Interactive Digital Entertainment Conference 2009 held at Stanford University.


Abstract

The purpose of this paper is to outline the core components of a practical navigation system which uses a novel technique for spatial representation in a commercial entertainment product. This paper is based upon thenavigation system developed for The World of Zoo (WOZ) by Blue Fang Games, LLC and published by THQ. WOZ placed the following requirement on our in game agents
(which are animals, such as tigers and penguins): depending on the animals species they were required to locomote across land, water, exhibit the ability to climb and eventually to fly all in a seamless manner. Animal locomotion in WOZ is driven by accumulating the root motion of multiple blended animations; this required a unique approach to the spatial representation of our environments. The system needed not only to take into account the defacto static environments that were created by
the level designers, but also the dynamic structures that the animals use (depending on the players interactions at that particular moment).


There was also the extra challenge of a system that was as straightforward as possible for level designers to work within. As Anthony J.D' Angelo so succinctly stated, "Don't reinvent the wheel. Just realign it." It is with this sage advice in mind that we reevaluated traditional navigable representations, in conjunction with how our animals should move through their environments. As important as the navigation framework was to the development of WOZ, the way the thought processes developed preceding the implementation is also of interest; as the re-understanding of what navigation is composed of (in virtually any environment) guided our decisions through the design and implementation stages.


In Game Programming Gems 7, I've written an article detailing the architecture of a multi-platform threading engine. The article is entitled, The Design and Implementation of Multi-Platform Threading Engine. One of the most important aspects of designing a multi-threaded program is spending the time upfront to design and plan your game architecture. Some of the high-levelissues that need to be addressed are: task dependencies, data sharing, data synchronization, acknowledgement and flow of data access patterns, decoupling of communication points to allow for reading but not necessarily writing of data, and minimizing event synchronization. This article details the GLRThreading Engine and also provides a lot of practical advice for either using the GLRThreading Engine or writing your own. Other topics include dealing with cache issues, thread pools, execution properties and more.
 
In Game Programming Gems 6, I've written an article about the Quantified Judgement Model (QJM) and it's usage and application to strategic game development. The article is entitled, Using the Quantified Judgement Model for Engagement Analysis. The Quantified Judgment Model (QJM) is both a model and a theory of combat. Originally developed to simulate historical battles and then later upon further refinement, used for modern engagement prediction; it is an ideal system for predicting potential victors in a game. In this gem I describe the base QJM formula. The base QJM formula can then be furthermore expanded upon, by adding models calculating attrition factors, spatial effectiveness of units and casualty effectiveness.

There is also some notes on the difference between the Lanchester equation and the QJM.




In AI Programming Wisdom Volume 2, I've written an article on Multi-Tiered AI Frameworks (MTAIF). This is the new framework used in the current iteration of Master of the Empire. The article is entitled, Designing a Multi-Tiered AI Framework. The MTAIF allows an AI to be broken up into three concrete layers, strategic, operational and a tactical layer. This allows for an AI programmer to have various AIs focus on specific tasks, while at the same time having a consistent overall focus. The MTAIF allows for the strategic layer to be focused exclusively on matters that can affect an empire on a holistic scale, while at the operational level the AI is in tune with reports from the tactical level. A differing factor from many other architectures is that the MTAIF does not allow decisions to be made on a tactical scale that would violate the overall strategic policies. This in turn forces highlevel strategic policies to be enforced in tactical situations, without the AI devolving into a reactionary based AI.


In Game Gems 5 I've written an article entitled, Advanced AI Framework Development with a Parallel Virtual Machine (PVM).
Its forms the fundamental understanding that is needed to start developing a parallel AI system. The article had to fit into 12 pages or so, so that meant a lot of actual implementation details had to be left out, as well as information on potential
design fallacies that may occur.



Early papers.

This is an article I wrote for OS/2 Developer entitled, Advanced Game Design with OS/2. The use of was the editor's idea. The article provided a basic summary of doing fast GPI updates - the technique I used for Master of the Empire. Obviously a super dated article (as it was published in 1997), but nonetheless it provides an interesting cross-section of my background.






Genericized Object Management (GOM). Todays games have huge AIs, being worked on by multiple programmers. Unless a new technique is introduced when the project begins, it becomes difficult to add any new type of methodology to the framework. This comes from the concern of breaking a currently implemented system or the real world fact that the new technique is just too complex. What the Genericized Object Manager (GOM) allows for is a simple way to register multiple objects through a parameterized functor [Alexandrescu02], which can then be easily accessed at runtime through one central core routine. A benefit of GOM is that the implementation can fit into almost any preexisting framework, so your game can have the immediate gains without refitting your framework to a particular solution. The GOM technique allows for setting up a specific AI, such as a particular Field Manager (see Designing a MultiTiered AI Framework), input managers, state machines that need to deal with multiple behaviors, or just a central system that is needed because the programming team is large. GOM also serves as a good technique while refactoring a large codebase.