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.


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.


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.

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.

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.