Egocentric AI Processing for Computer Entertainment: A Real-Time Process Manager for Games

A general-purpose, real-time Process Manager (PM) designed to control the execution of “AI” processes in many different kinds of computer game is presented. It is viewed as a first step towards standardising AI execution for games, which is a prerequisite for AI hardware acceleration. The PM supports “egocentric” AI processing, which is an approach that favours believability over accuracy of simulation when constructing a virtual world for entertainment purposes. The PM can maintain, from the point of view of a human player, the “ego”, a constant frame-rate at the expense of AI processing under variable AI loads. A game that uses the Process Manager will appear to run smoothly even if the time required to fully process currently active objects exceeds the time available to update and draw a single frame. The PM user can specify a global upper time limit for AI processing, and the PM will attempt to ensure that this limit is never exceeded. A fuzzy upper limit and graceful degradation of AI performance replaces a sharp cut-off point for loss of frame rate. In consequence, the PM reduces the need for manual optimisation of AI code and thereby facilitates the implementation of more populated and interaction-rich virtual worlds. The PM also supports (a) simulated, multi-threaded AI process execution, (b) specification of the run-time frequency of AI processes, (c) suspendable and sliceable “behavioursets”, (d) automatic process interleaving and activation delay to minimise per-frame CPU load, and (e) user-specified conditions that define the relative “importance” of AI processes that is used to determine which processes to postpone under high loads. The design of the PM, its useful properties, and a prototype implementation on Sony Computer Entertainment’s PlayStation2 hardware is described. Results from testing the Process Manager in a simple problem domain are analysed. AI IN GAMES The term ‘AI’ is used extensively in the computer games industry to refer to a particular part of game code and game behaviour. Although use of the term is widespread there is often confusion over what ‘game AI’ is. In practice, what is termed ‘game AI’ is the high-level control code that determines the behaviour of game ‘agents’. Agents can be simple ‘space invader’ sprites, a bouncing ball in a sports game, or a sophisticated, goal-following, intelligent adversary. This is a very broad definition of game AI. Game AI is the code that orchestrates game events, in contrast to rendering code that visualises game events. In consequence, AI code constitutes a major part of the gameplay experience, creating and running the virtual world presented to the player, although it does so ‘behind the scenes’. In consequence, much of AI code involves checking, changing and creating information that refers to objects and processes within the game world. It is this sense of “AI” that will be used in this paper. The problem domain for game AI is as heterogenous and diverse as the games themselves. The AI for a puzzle game will differ markedly in content from the AI required for a sports simulation. The situation differs for game graphics: the problem domain is relatively invariant over game types, consisting typically in the drawing of 3D environments and characters on a 2D screen. This difference explains why standard methods and practices have been adopted for the implementation of game graphics, but not for AI. Standard methods are a prerequisite for hardware acceleration; hence, graphics acceleration is the norm for modern computer games consoles, but as yet there is no concept of AI acceleration. As a step towards the standardisation of AI methods for computer games a general-purpose AI Process Manager that can form the backbone for the execution of heterogenous AI code in computer games is presented. REQUIREMENTS FOR GENERALPURPOSE AI EXECUTION IN GAMES Games should be enjoyable. This requirement has many consequences. One important consequence is that games that allow player input at any moment (“arcade-style” games) should run in real-time, that is present events that occur fast enough to challenge the player’s reactions. Depending on the complexity of the game world and the computing power of the host machine, this may be more or less difficult to achieve. In practice, game developers strive to create games that maintain a consistent frame rate of at least 25-30 display frames per second, or preferably more. Lower frame-rates look bad, reduce opportunity for interaction, increase player frustration, and do not mimic the speed of events in the real world. In general, the latter stages of a project involve optimising parts of game code for processing time reductions. This includes AI code, which, depending on the type of game, can take up more or less of the available CPU time. Therefore, an important requirement for AI execution is that (a) it conforms to the timing constraint of the overall game frame rate. A consequence of (a) is that the AI never exceeds a maximum per-frame processing time. Game AI requires the execution of arbitrarily complex and heterogenous pieces of code, often grouped together as behavioural “rules” or “behavioursets” for various game objects or agents, such as the AI code for a trapdoor, obstacle, spring, or the code for an adversary, racing vehicle or character. Therefore, a further requirement for AI execution is that (b) it makes no assumptions about the exact nature of the AI code, including assumptions about how long the code will take to execute. Rendering code normally has to execute every frame in order to construct the visual scene. The situation is different for AI code. For example, a racing car controller needs to make steering decisions every frame, but can check its fuel consumption and decide to make a pit stop every twenty or so frames. Similarly, a footballer may need to check for passing and shooting opportunities every frame, but only need check its position against the team's formation every other frame, or only in a dead-ball situation. The general point is that AI code involves a wide range of execution frequencies compared to non-AI game code. If all AI code is fully executed every frame, despite the fact that the required execution frequencies may differ, the resulting code is inefficient, needlessly lowering frame rates and consuming CPU resources that could be better employed elsewhere. Furthermore, some games require different execution frequencies for objects and agents, in addition to controlling the execution frequencies of the processes that implement them. For example, a very slow moving tortoise need not be processed every frame, whereas the hare may need to be. Hence, a further requirement for AI execution is (c) it allows different execution frequencies to be specified both for agents and their constitutive internal processes. Some AI processes can be extensively time-sliced across many frames, particularly if the results of the process are not immediately required. For example, if a strategy game agent needs to plan a route through a terrain, then the planning can take place over many frames before the agent actually begins to traverse the deduced route. Time slicing allows computationally expensive processes to be 'smeared' across many frames thereby reducing the per frame CPU hit. Therefore, a further requirement for AI execution is (d) it allows AI processes to be dynamically suspended and reactivated. Currently, there are no general methods for supporting different execution frequencies of parts of AI code and timeslicing non-urgent AI processes. If these techniques are employed they are employed in a project-specific, ad-hoc manner. There is no 'AI operating system' that allows programmers to control these factors. This represents an important missed opportunity for the development of more complex AI in games. If all AI code is executed through a common AI operating system or engine, with mechanisms for specifying execution frequencies, upper bounds on CPU time, time-slicing, and suspension and reactivation of processes, then it would be possible to get more AI for the same CPU power. To summarise, four main requirements for general-purpose AI execution have been identified: (a) Conformity to the timing constraint of the overall game frame rate despite variable AI load; (b) no assumptions about the exact nature of AI code; (c) allow different AI processes to have different execution frequencies, both for agents and their constitutive internal processes; (d) allow AI processes to be dynamically suspended and reactivated. Requirement (a) is the more interesting requirement because it asks the impossible: AI algorithms that take the same amount of time even when asked to do more work. However, games must entertain the player, not compute a perfectly accurate world. Section 2 explains how this fact allows requirement (a) to be partially satisfied. BELIEVABILITY ALLOWS AI SUSPENSION A computer game is like the real world, consisting of both active and passive agents and events that unfold over time. For example, a truck may plant a mine in a road. A car drives towards the mine, notices it, and swerves to avoid. This in turn causes a trailing motorbike to not see the mine until it is too late. The bike hits the mine and explodes. The explosion involves hundreds of ‘particles’ flying into the air, which come to rest, and eventually disappear. Computer games need not process every object, agent and event in the virtual world in order to present a believable, entertaining experience. For example, if the truck was within the player’s field of view when planting the mine then the game necessarily needs to process the truck movement and the mine drop, and the rendering code necessarily needs to draw this event to the screen. However, if the truck was ‘offscreen’ the rendering code need not be run, and the AI code controlling the truck could simply assert the existence of a mine on the roa