Books, articles, papers, technical ramblings...

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 the navigation 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 developing 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-level issues 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. Buy it! This is an article I wrote for OS/2 Developer entitled, Advanced Game Design with OS/2. The use of advanced 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. 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. This article can serve as an introduction to an actual series of articles that I intend to write (see below for an article outline).     Other 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 Multi-Tiered 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. Articles on AI Development using a PVM: Articles on AI Development using a PVM.