Download General Lightweight Scheduling in Game Artificial Intelligence

TECHNIA – International Journal of Computing Science and Communication Technologies, VOL.4 NO. 2, January 2012 (ISSN 09743375)
General Lightweight Scheduling in Game
Artificial Intelligence
1
1, 2
Trevor Adams, 2Clive Chandler
Faculty of Computing, Engineering and Technology, Staffordshire University, Staffordshire, England
1
[email protected], [email protected]
Abstract— Game Artificial Intelligence requires an
interactive AI, which by its very nature presents many
challenges to game developers. As AI tasks become more
complex, the need to manage the execution of those tasks
becomes more important. All but the most complex routines
can be managed with some simple abstractions for execution
management. These abstractions, through extension, could be
used to map functionality onto hardware specific
implementations; paving the way for hardware thread
support and multi-core support. This paper discusses the
need for scheduling in game artificial intelligence (AI); it
presents a design for a lightweight scheduler that forms the
basis of an extensible framework for basic control flow and
execution. Whilst not part of a larger API the design can be
compatible with and adaptable to the general tasks of AI
control.
Keywords— Games, AI, Software Engineering, Scheduling.
I.
INTRODUCTION AND MOTIVATION
Game AI presents many challenges. Computer games
operate over many hardware architectures and are built
using a myriad of software frameworks. Games are now
presenting increasingly engaging interactions with players.
Platforms are now able to give more hardware resources to
AI routines as hardware is devoted to other areas, chiefly
graphics. As AI becomes more complex, a mechanism is
required to manage the load and facilitate smooth running.
A scheduler is a computing control system designed to
manage the execution of code. Chiefly, the purpose is to
make good use of available resources by distributing tasks
efficiently.
Efficiency in this case is determined by the application
requirements and the constraints of the host environment.
Game developers have been using finite state machines
(FSM) to manage game interactions for many years [1],
but recently developers have also begun using behaviour
trees in place of hierarchical FSM as they rely on simpler
primitives and scale well to more complex scenarios [2].
Game AI is a good focus for the purpose of a general
scheduler as many games present indeterminate problems
at any given point in time. A game such as Madden NFL
2011 [3] may be calculating a path, traversing a path and
planning strategy for one agent or multiple agents
simultaneously and a version of the game may be
produced for multiple platforms. A high level, abstract
system for scheduling can help an AI system manage the
execution of these tasks.
There are three key elements to a game AI scheduling
system [4];
Having algorithms that can work over multiple
frames, and yield results in any frame (Anytime).
Dividing execution amongst routines (Frame / Phase).
A mechanism for giving preferential treatment to high
priority operations (Prioritisation).
A scheduler is a core support structure to general
game AI routines [2]. Each of these elements will be
considered and a set of suggested classes that are used
to implement a solution.
II. ANYTIME ALGORITHM
Anytime algorithms are designed, to a certain extent, to
emulate the way a human may perform an action – we
start acting before we have finished thinking [4]. The idea
that a first guess will be roughly correct and begin acting
upon it allows an AI to be responsive to input. The extent
of visible thinking will be determined by the game that is
hosting the AI. Anytime algorithms are used in
commercial games and are often bespoke, you can see
evidence of anytime algorithms when playing games such
as StarCraft 2 [5], a real time strategy (RTS) game. When
a unit is directed to travel to a currently unexplored region
of the game world it responds immediately and is able to
traverse the route without having to display any thinking
time; the agent heads in the general direction and updates
information as time goes on.
Anytime algorithms have been shown to perform well in
regards to pre-calculated counterparts [6]. Anytime
algorithms compliment scheduling as the nature of them
involves being interruptible. It could be said that
interruptible, anytime algorithms add to the illusion of
intelligence within a game due to responsiveness and
retracing that happens when better information is found
[7]. As movement and path finding are often the most time
consuming processes[4], they tend to be prime candidates
for anytime algorithms in the constrained environments of
game development.
The nature of anytime algorithms requires that an AI agent
have access to a resource for the purpose of memory [8].
A blackboard system as used in real time team planning
[9] and behaviour systems [8] would be ideal for the
purpose of scheduling. A blackboard system can also be
made thread safe and can be used by multi-core processor
systems, easing the load placed on context switching.
Shared context and centralised data can also assist in
breaking down the predictable nature of game AI staple
techniques E.g. FSMs.
TECHNIA – International Journal of Computing Science and Communication Technologies, VOL.4 NO. 2, January 2012 (ISSN 09743375)
III. DIVIDING E XECUTION
Millington and Funge [4] present a simple notation for
execution contexts and refer to them as behaviours.
Behaviours are the core execution component for a game
AI entity. Whether a game is to use a basic FSM for
behaviours [1], select behaviours dynamically [10] or use
a hybrid approach [11], having a behaviour be a fixed
point of execution provides a context for a scheduler
system.
level and provide constructs so as to be extensible when
further functionality is required.
IV. SCHEDULING & PRIORITISATION
The logic of scheduling tasks will be wrapped into its own
interface type so that it may be substituted for different
logic at run time. A pseudo code listing of the scheduler
strategy:
interface IScheduleStrategy{
interface IProcess {
void Update()
}
void Update(List<Behaviour>,float frame)
}
class Scheduler {
class Behaviour {
float frame
int Frequency
List<Behaviour> list
int Phase
IScheduleStrategy strategy
IProcess Process
void Update() {
void Execute()
frame++
}
strategy.Update(list, frame)
Some schedulers will refer to behaviours as a composition
of tasks. Tasks have their own context, referred to as a
closure [2], and can be configured to return information
such as completion status.
Most games code operates by way of a game update loop
[12]. Games tend to operate using a basic loop structure.
Input is gathered; game logic is updated and then rendered
to the screen. AI tasks are required to run within the logic
update section of the game loop. Many tasks are run
during this time, including graphical operations. The
lightweight scheduler will split tasks over a developersupplied frequency and stagger them using a phase
identifier. This is a default behaviour supplied as part of
the framework, it need not be fixed and could be
exchanged through use of the strategy pattern [13]. A
record class will keep an instance of the behaviour object,
the frequency of execution and a phase step. As it is likely
a game will require multiple tasks to be scheduled, a
schedule manager will be required to maintain a list E.g.
foreach (Behaviour b in listBehaviours)
{
if b.Frequency % (b.Frame + b.Phase)
b.Execute()
}
The phase is added to the frame to cater for the number of
behaviours being greater than the amount of frames [4].
The scheduler will also execute the schedule plan and
provide access to a mechanism for results and feedback.
The observer pattern [14] can be used for the purpose of
call back and notification, allowing a manager to report
back. The interface can be created generally so that it may
be implemented for the purpose of asynchronous call back,
taking advantage of threading where available. Much like
the rest of the design, the point is to be capable at the basic
}
}
Using concrete strategy:
class Standard: IScheduleStrategy{
void Update(List<Behaviour>,float frame)
{
foreach(Behaviour b in listBehaviours)
{
if b.Frequency % (b.Frame+b.Phase)
b.Execute()
}
}
}
Now that the execution logic is wrapped into a class, any
type of scheduling scheme may be employed. A manualphasing scheme would require intervention from the
programmer and knowledge of the code to be executed. In
more complex scenarios, the constructs may be used to
provide feedback by way of a return status. For example,
two possible routines could be using mutually prime
frames and timings taken for use Wright’s Method for
automatic phasing [4] and execution.
The core functionality can also be easily extended to
handle hierarchical scheduling. The composite pattern [13]
is a good choice for this. Depending on the programming
language used, the abstract entities (scheduler/behaviour)
can be implemented as an abstract class or interface type.
This will allow behaviour and a scheduler to be used
interchangeably and function as a hierarchy. A main
schedulers list of behaviours, when executed, may in turn
TECHNIA – International Journal of Computing Science and Communication Technologies, VOL.4 NO. 2, January 2012 (ISSN 09743375)
be sub-schedulers that hold their own list of behaviours to
execute. This architecture is shown by way of a diagram in
Fig. I. A hierarchical system could be expanded towards
the use of behaviour trees and goal-oriented action
planning [10].
Main
Team B
Team A
Char. C
Char. A
Scheduler
Char. D
related to rendering visuals, but less so in terms of AI.
This is an obvious area for advancement as many AI tasks
could fit into a common API and there is currently a lot of
work in the AI community in moving towards an AI API.
The lightweight scheduler as presented in this paper is
designed to be the basis for an extensible framework for
basic control flow and execution. While not part of a
larger API, this scheduler design is intended to be
compatible and adaptable to the general tasks of AI
control. For the purpose of game development, it would be
possible to extend the design presented in this paper to
cater for multi-processor environments (language specific
extensions) and software threads. The system could also
support priority scheduling using basic computing data
structures. The current design lacks any sort of load
balancing or the ability to automatically detect and/or halt
behaviours that have not completed successfully or failed
to finish in a desired timescales.
REFERENCES
Char. B
Composite
[1].
M. Buckland, Programming Game AI by Example. Plano,
TX: Wordware Publishing Inc., 2005.
[2].
A. J. Champandard, "Getting Started with Decision
Making and Control Systems," in AI Game Programming
Wisdom 4, S. Rabin, Ed., ed Boston, MA: Course
Technology PTR, 2008, pp. 257-264.
[3].
E. C. EA Tiburon, "Madden NFL 11," ed: EA Sports,
2010.
[4].
I. Millington and J. Funge, Artificial Intelligence for
Games, 2nd Edition ed. Burlington, MA: Morgan
Kaufmann, 2009.
[5].
Blizzard Entertainment, "Starcraft 2," ed: Blizzard
Entertainment, 2010.
[6].
R. Butt and S. J. Johansson, "Where do we go now?:
anytime algorithms for path planning," presented at the
Proceedings of the 4th International Conference on
Foundations of Digital Games, Orlando, Florida, 2009.
[7].
A. Nareyek, "AI in Computer Games," Queue, vol. 1, pp.
58-65, 2004.
[8].
J. Orkin, "Agent architecture considerations for real-time
planning in games.," in Artificial Intelligence in Interactive
and Digital Entertainment (AIIDE), Marina del Ray, CA,
2005.
[9].
K. McGee and A. T. Abraham, "Real-time team-mate AI
in games: a definition, survey, \& critique," presented at
the Proceedings of the Fifth International Conference on
the Foundations of Digital Games, Monterey, California,
2010.
Behaviour
Hierarchicalscheduling
schedulingsystem
systemusing
using composite
composite classes.
classes
Fig.Fig.1
I Hierarchical
inheritinga abase
baseclass
classororimplementing
implementingananinterface
interfacecan
canallow
allowan
an
Inheriting
to fulfil
roleof
of both
behaviour,
objectobject
to fulfil
thetherole
both scheduler
schedulerandand
behaviour,
effectively
allowing
schedulers
to be executed
as tasks.
effectively
allowing
schedulers
to be executed
as tasks.
V. DELIMITAIONS
The initial concept for a lightweight scheduler was born of
the need for a test harness application for AI, using an
automated unit testing library and mock objects. As such,
the current design does not currently cater for parallelism,
by way of threading or multi-core processing. The chosen
language for initial implementation is C# using the XNA
framework, although the design should be portable to any
object-oriented (OO) language common to game
programming E.g. C++. This language was chosen to take
advantage of available rapid development tools. A small
test harness application has been developed based on the
Westworld Adventure game created by Mat Buckland [1].
The high level aim of the design is to encapsulate
executable behaviours using a common interface. This
behaviour can then be added to a scheduler object along
with a given schedule, which will incorporate the
behaviour to execute, the frequency of execution and a
phase. The high level objects can be simple at first and
later extended to incorporate more complex scheduling
patterns. It is not intended to be a professional level tool
but could easily be used for simple games.
VI. CONCLUSION
General game AI frameworks, such as those developed by
the AI Interface Standards Committee (AIISC) [15], have
given rise to a paradigm shift in how developers consider
implementing AI. It is commonplace to see graphical
application programming interfaces (API) and abstractions
[10]. J. Orkin, "Three States and a Plan: The A.I. of F.E.A.R.,"
presented at the Game Developers Conference 2006, 2006.
[11]. N. Lau, "Knowledge-Based Behaviour System - A
Decision Tree / Finite State Machine Hybrid," in AI Game
Programming Wisdom 4, S. Rabin, Ed., ed Boston, MA:
Course Technology PTR, 2008, pp. 265-274.
[12]. B. Schwab, AI Game Engine Programming. Boston, MA:
Course Technology PTR, 2009.
[13]. A. Shalloway and J. R. Trott, Design Patterns Explained:
A New Perspective on Object-Oriented Design: AddisonWesley Professional, 2001.
TECHNIA – International Journal of Computing Science and Communication Technologies, VOL.4 NO. 2, January 2012 (ISSN 09743375)
[14]. E. Freeman, E. Freeman, B. Bates, and K. Sierra, Head
First Design Patterns: O' Reilly \\& Associates, Inc., 2004.
[15]. B. Yue and P. de-Byl, "The state of the art in game AI
standardisation," presented at the Proceedings of the 2006
international conference on Game research and
development, Perth, Australia, 2006.