日本デジタルゲーム学会
Digital Games Research Association JAPAN

デジタルゲーム学研究
Journal of Digital Games Research

Improved Game Artificial Intelligence through Interactive Environments
Paul DEWAALi

Andrea KUTICSi Satoshi TOYOSAWAii

and

Akihiko NAKAGAWAi, iii

iNatural Science Division, International Christian University 10-2-3, Mitaka-shi, Toyko, 181-8585 Japan
ii
Welfare and Information Division, Tokuyama University Shunan-shi, Yamaguchi, 745-8566 Japaniii
School of Information Systems, University of Electro-Communications 1-5-1, Chofu-shi, Tokyo, 182-8585 Japan
E-mail: g126723e@yamata.icu.ac.jp, matz@icu.ac.jp, toyosawa@tokuyama-u.ac.jp, ranaka@nt.icu.ac.jp
Abstract Game AI has become standardized to use behavior trees and scripts, but both have problems due to indirectcommunication between the game environment and the games objects. Our design uses an environment-driven approach which
directly links the environment and objects. The evaluation experiment showed that the proposed method was perceived ashaving a higher level of character behavior as compared to a standard architecture. Likewise, when comparing the CPU-usageof calls, the method showed an overall decrease in CPU time.
Keywords Video Games, Artificial Intelligence, Behavior, Behavior Trees, Scripting, Interactive Environment

1.

Introduction

when, and where. This method allows for agents to mimic

Artificial intelligence (AI) is a rapidly growing field in

human behavior very closely and appear very human andthe game industry[1]. In recent years the focus of gamecinematic. But this process must be repeated for every new

development has shifted away from graphical advancements.

agent and every new behavior. However, it can allow for the

The focus has moved towards the improvement of artificial

developers make the agent behave to exact specifications[2]

intelligence and character behavior . Thus spurring the(like a movie script) at the cost of forcing the agent to follow

interest and development of bigger and better AIs in thea very specific set of rules. This limited behavior is a sidegame industry.

effect of forcing the agent to do a predetermined order ofGame AI has come a long way since early video games

scripted behaviors in the game.

[3]

The alternate approach is autonomy[6]. Instead of very

and animation[4]. Our focus for the Interactive Environment

specific rules dictating exactly how the agent is to behave,and another cornerstone of game AI is behavioral AI.

behavior is approached from a broad point of view. Instead

Behavioral AI is developing systems and architectures toof handcrafting specific behaviors for the agents they try to

mimic intelligent thoughts, actions, decisions, and emotions

come up with rules broad enough to react to a large range offor the agents in games. There have been many books[5, 6, 7]

player actions. Since they run autonomously, adding agentson the subject throughout the years and it is a highly

becomes a simple task of replicating them in the game world.

discussed topic in developer circles[8, 9]. Though one of the

The problem is, without specific and unique scripts andnewer focuses, it majorly impacts the gameplay experience.

behaviors; continued interactions with the agents will

After all, if the game character on the screen looks just like a

uncover repetitive, generic actions, limiting the scope ofhuman, it will be expected to act like one as well.

their behavior’s effect.

and has branched into many subfields such as pathfinding

In the broadest sense, the implementation of behavioral

Finding a balance between the two extremes is the goal of

AI can be divided between two extremes: putting the agents

many AI developers. This poses the question: howon a predetermined path, or making them autonomous[6]. By

exclusively mutual are they? The common perception is you

predetermining the agent’s behavior, the developer has tocan only have one at the detriment to the other; and to some

script the agent and tell it exactly what it wants it to do,extent that’s true. Certainly it’s hard to say a cut scene (anin-game movie) leads to no loss in autonomy. But, withvariables the agents need or want to watch. Blackboards may

increasingly popular techniques such as “interactive cut

store commonly needed variables like the location of thescenes” (where the environment and agents rely heavily on

player’s character in the game. As these variables change

scripted behavior but the player is still able to affect thethey can trigger the behavior trees to change their state,situation in a limited way) developers are attempting to meld

individual nodes, or their behaviors. While monitoring theseboth together. Usually if the developer wants to makechanges and reacting to them can give a real sense ofsomething cinematic he has to script the specific actions forthought and planning to the agents in a game, they also comethe environment, the agents, and possibly the player.

at the cost of needing constant checking.

2.

2.2

Related Work

While all the previous architectures are used for

A core goal of many AI architectures is autonomous
behavior. These architectures are focused on allowing anagent in a game to run by itself without any help or influence
from other classes and objects in the game. Some of thesearchitectures achieve this by basing the agent on a series ofstates. Each state in the agent can be used to respond to adifferent circumstance and the AI system decides what state
would be best to be in according to what’s happening in thegame. Common game states might include an ‘attack’ state
for when the agent is being aggressive or a ‘flee’ state forwhen the agent is trying to escape and hide in the game. The
first of these architectures, and a staple of the AI industry,
are finite state machines[10]. From these finite state machines,
a new industry standard has emerged: behavior trees.

2.1

Scripts

Behavior Trees

autonomous behavior in agents, different scripting systems
are also used to manually direct agents in the game. A script
is a piece of code written in a scripting language that calls
functions and executes tasks in the game code that would
otherwise have to be executed one after another by one ofthe developers. One of the most popular scripting languages
used in games today is Lua[15]; with a number of different
game engines supporting it. Although scripts can be used fora number of different tasks in game development, this paper
focuses on scripts for game AI.
AI scripts are often used to give specific behaviors to anagent that would otherwise not work in an autonomous
system. This can be for a number of different reasons, suchas the behavior being too specific to warrant repeated use(such as a script for an agent’s death) or the behavior is too

Trees can come in a number of different forms (such ascomplex to code into an autonomous systembehavior trees, decision trees, event-driven trees, etc) but

Another group of, and the largest scripts used for games are

their function remains the same. Behavior trees take thecut scenes. Games use cut scenes and cinematics to directconcept of state machines and add structure to the states andthe game’s narrative and draw in the player. In these cases,transitions, partitioning them into branches of a tree graph.

every single object, agent, and even the player in the game isThis formulates a system that is not only easy to visualize,

stripped of their control and is run exactly as the developers’

but also easy to manipulate using the multitude of tree

script.

traversal algorithms available.
Behavior trees are a way of grouping similar behaviors
and actions together under a parent node to form “sub-trees”
to create high level behaviors[11, 12].
These behavior trees often have their states and nodes[13, 14]linked to blackboards. A blackboard stores global

3. Our New Design: The
Interactive Environment
We propose a new game AI architecture that allows theagents and objects in the environment to send, receive andmanipulate data between themselves within the game.

Normally objects in a game are nothing more than an art
asset: the doors, walls, trees, etc. With the Interactive
Environment (IE) we turn these ‘art assets’ into objects able
to communicate with the agents in the game. Using thissystem there are a number of weaknesses that can beovercome from both autonomous and scripted AI systems.
Autonomous systems have very little perception of theoutside game environment, and the little perception they do

Figure 1: Order of event passing in the IE.

have is based upon predetermined variables that are
constantly checked.
Scripted systems, on the other hand, are very context
specific, non-scalable, and also are usually embedded into
predetermined variables. By allowing the agents tocommunicate (send/receive data) with the environment weovercome these weaknesses and create a new middleware
game AI system. By showing this improvement in game AI
through an interactive environment we bring further interest
and more focus on using the environment in AI; rather thanthe more traditional method of focusing solely on the agentsand their inner systems or scripts. Using the environment
and empowering the objects inside it we attain new AI
behaviors and a new architecture.
For this new AI architecture we designed a three classsystem. We designed a single class, the Interactive
Environment class, to be in charge of holding and helping
with communication between the other two classes, theIEEvent and IEObject classes.
Figure 2: Code for processing events in the IE class.

3.1

Interactive Environment Class

The interactive environment class is the central classstoring all IE objects in the game, and handles all events thatare broadcasted (sent to the IE) while the game is running.
The first variable that is looked at is the ‘toID’ variable.
Should it be set the IE only checks the range between theevent and the IEObject tied to that specific ID and if it iswithin range sends the event. Otherwise, an event is sent andprocessed using three variables: the size variable, range
variable and the type variable. The range variable limits thereceivable IEObjects to only those within the set range.

The type variable tells the IE which types of IEObjects
the event should be sent to. The size variable tells how many
to send it to. If the size is set to ‘0’ the event is sent to all
IEObjects that fall under the type. Otherwise the event issent to the first X (set by size) number of events, in range,that fall under the type. This can provide for bothgroup-wide “goal-sharing” as well as unique data exchange.

The object class works using an update method whichchecks to see if any events have been received. If there are
any in its queue it retrieves the oldest one (first in first out)
and sends it to the typeHelper method (shown in Figure 3).
From the typeHelper, the event’s type is used to determine
what function should be called, while many of the functions
also change or determine the state the customer will be.

3.3

IEEvent ClassThe event class has a number of identifiers saved to it. It
stores: who the event is from, who (if anyone) it is going to,
the size of how many times it should be sent, a range
variable to decide how far the event is to be sent out, avariable to store the specific type of event it is, the location
Figure 3: Code for processing events in the Customer class.

of the object sending the event, and then the data specific to
Figure 1 shows how an event would be sent using the IE.

the event.

The process starts with the player sending out the

The event class can be extended and by setting the ‘type’

black-outlined event to the IE. The actual passing of thevariable in the event the developer can make new events forevents to the IE is done by an array list shared by the IE anddifferent IEObjects. Below are figures explaining more

all its IEObjects. The sent event then gets put in the IE’s

specifically how these types and IEEvents were handled inevent array. When processing the events the IE implements aour IE game and is further discussed in chapter 4.1.

First-in-first-out (FIFO) approach. It updates every loop, and3.3.1

processes one event per loop. The code use by the IE toprocess events is shown in Figure 2.

Flowchart for an Event Broadcast

Figure 4 shows an IEObject sending IEEvent12 to the IE.
In Figure 5 the IE is processing IEEvent12. The first thing
the IE does is look at the ToID field. If it is not null the IE

3.2

IEObject class

The IE object class is the superclass of all objects that cansend and receive events. Meaning both the agents in thegame and actual game objects are children of this class. The
object class stores a few important variables to be used: theshared IEEvent array list from the IE, an ID variable to store
the objects unique ID, an array list to store events it needs toprocess, and a queued event that is run after a certain
condition is met (e.g. reaching a certain location).
Furthermore, by extending the other object classes (theplayer(s), agents, environmental objects, etc) from the
IEObject class, it allows the game to hold all of thesedifferent objects in an IEObject array in the same place foruse by the IE class.

will then scan its IEObject array for an object that sharesthat specific ID. Once found it will then send that event tothat IEObject and the process will be complete. Since it isblank, the IE then looks at the type and size. The type tells
the IE to look for Waiter IEObjects (because it’s ‘type’ iswaiter). The size of 1 tells the IE to only send this event
once, to the first Waiter it can find in range. Thus the IE
comes to the first Waiter in its array, Waiter1. It checks therange and if within range will send IEEvent12 to Waiter1(Figure 6). Otherwise it continues checking all Waiters until
one is found in range or it reaches the end of the array (atwhich point the event is discarded).

Figure 4: IEObject sends IEEvent12 to the IE; stored in the IEs
event array.

Figure 1: Screenshot of the game in action.

The major points of contention were in the behavior andreactions between the agents in the game. Participants were asked
Figure 5: IE processing IEEvent12.

to rate their believability overall, believability within theirinteractions, and within their patterns.

Another self evaluation was given on the ease andabilities of the IE code compared to the more traditional
methods of state machines and scripting. This code wascompared between the systems based on the complexity of
Figure 6: IEEvent12 passes the range check and is sent.

adding in new behaviors to each system and running thecurrent behaviors. Complexity was judged based on thenumber of calls and checks that must be made to monitor

4.

Evaluation Method

and switch between the behaviors.

Game AI is focused on creating believable humanbehavior in their agents and on creating a system that is easy
to understand and can scale to fit the size needed by thegame. Therefore we decided to evaluate based on these two
common goals of game AI; believability and the simplicityof the code.

The Evaluated GamesThe games were a single room environment portraying a
bar and restaurant. There were tables in the gameenvironments and chairs for the agents to sit in. The agentswere the customers, the waiter, the barkeep, and the player.

To determine the believability of the games we made andcompared two games. One game used the more common
approach of state machines and scripting to model thestandard of today’s game AI architecture. A new architecturethat could not beat or tie the current one would not be of use
to game developers.

4.1

The other game used our new

Interactive Environment AI. The games were rated on theirbelievability in a number of fields.

The waiter interacted with the customers and player to gettheir orders and relayed them to the barkeep. The barkeep
interacted with the waiter by taking and sending out
completed orders. The barkeep also gave out drinks and talkto the player when interacted with. The customers could callon the waiter to place and order, and then once it wasreceived they would eat the order and either order again or
leave the bar. Customers, the waiter, and the barkeep talked

to the player if interacted with.

Environment system to run the agents. Both games ran off

The game was played from a top-down isometric view

the same main classes. In each game the screen was drawn(shown in Figure 7), and the view was locked-in and couldin the class named DrawingBoard (shared by both games)

not be changed. The player could use a number of different

and handled user input using the same class, Interface. Bothkeys to interact with the game. The ‘w’, ‘a’, ‘s’, ‘d’ keys

games had no sound and shared the same controls.

were used for movement and the ‘f’ and ‘c’ keys were used

4.4.1

The Interactive Game Environment

to interact with other agents in the game. The ‘f’ key would

The interactive environment game used the IE system ofinteract with and send a chat event to the nearest agent while

passing IEEvents between the objects (chairs) and agentsthe ‘c’ key would call the waiter to the player to place an(Customers, waiter, barkeep, and player) to change agent

order.

behaviors. Chairs would send events to custoemrs to tellthem where to sit. Customers would send events to the

4.2

The Participants

The participants were chosen from males, age 18-23. All

waiter to place orders and the waiter would send events backto return orders.

with experience playing games. They completed the survey

There was also an agent (called the barkeep) that wouldwith what genres they play as well as how often they playtake orders from the waiter and “cook” them before sending

per week. We chose all male participants to further keep thethem back to the waiter to deliver. He also received events

study group as non-biased as possible.

from the player for drink orders.
4.4.2

4.3

The Environment

Standard GameThe other game for the evaluation used a mixture of state

The room will be climate-controlled to a comfortablemachines and scripts to direct its agent’s behavior. A script at

temperature and they did not have outside distractions

the start seated the customers and from there state-machines

disturbing them. The games were played on a laptop, adictated their behavior with simple “blackboard” check

Toshiba Satellite P750-BT4G22. The specs are as follows:

methods for responding to input from the player and froma)

Processor: Intel(R) Core(TM) i5-2410M CPU @the customers wanting to place an order.

2.30GHz (2 CPUs)

4.4.3b) Memory: 6144MB RAM

SurveyThe evaluators spent 15 minutes with each game and thenDisplay Mode: 1366 x 768 (32 bit) (60Hz)

afterwards were given a survey to complete based on theird) Display Size: 15.6 inch widescreen LCD screen

opinions of the game. The survey was given in a 5-pointe)

NVIDIA Geforce GT 540 1GB video card

Likert scale. The questions were based on the topic of “Rate

The laptop was able to run both games with nothe below items on how realistic and human-like you

performance issues. The participants were seated about 3x

thought their behavior was” with the scale as: Not believable

the height of the display away from the laptop. The

at all, slightly believable, believable, nearly real, andbrightness was set to around 80%.

completely real.

c)

The start of the survey asked questions regarding their age,

4.4

Evaluation Survey

favorite genres, amount of time spent gaming, and their

There are two games that were played by the evaluators.

preferred platform for gaming. The behavior questions using

One game used scripts and state machines to run their agentsthe Likert scale referred to the individual behaviors of the

behavior and the other game used the Interactive

agents in the games as well as the behaviors among theFigure 8: The average scores of survey questions.
Figure 9: Chart of the survey answer dispersion.

agents. See the appendix for a copy of the survey.

4.5

Code Evaluation

While the average individual scores between the games

The evaluation of the code is based on the comparison of

showed differences, the overall average scores for boththe efficiency of the behaviors or states in the programs.

games were remarkably similar as shown in Figure 8. An

This comparison is based on the number and type of calls

average of all surveys was taken for each question in theused to achieve these behaviors. For a behavior that checks

survey and the results were also plotted.

every cycle to decide if it needs to be checked, it was given

Figure 9 shows the dispersion of the answers. As shown,

an “every turn” rating; if it is activated by an action, then thethe results of answers from both games showed a very

sequence of events to activate it was counted and was given

similar dispersion as most participants rated most questionsin the other ratings.

from the games as believable.

4.6

5.2

Procedure

Code Evaluation

The evaluators were told they would be playing two

The only difference between the games in terms of code

15-minute games and then taking a survey afterwards. The

was the AI implementation; therefore the remaining codeorder of the games was chosen randomly. There was a 5

shall be omitted from the evaluations. The evaluations wereminute resting period between the two games. The games

separated based on the behaviors and states in the games.

themselves have no way to lose or complete the game; so

Therefore there was a separate state and behavior in thethere is no risk of the evaluator getting to an ending state. At

Standard game and/or IE game for a waiter taking an order

the end of the second game session they were handed theand for delivering that same order. We evaluated 5 different

form and asked to fill it out. The total time was around 40

behaviors (Waiter taking order, Waiter delivering order,

minutes for each individual.

Customer placing order, Customer receiving order, andWaiter dropping order) and summed their scores below in

5.

Results

5.1

Survey Evaluation

Seven male participants took the survey. The participants
had an average age of 21. They averaged 3.3 hours of gameplaying every week.

Figure 10.

Table 1: Table showing the number and types of calls for the‘Customer Placing Order’ behavior.
Calls by Type

IE

Standard

Every Turn02Order(N)[ loops]: Run Once

1

1

Boolean Checks or Calls

6

3

a number of calls and checks to place its order. It must first
send out the event to the waiter, after which it waits for thewaiter to arrive and receives another event in response. From
Figure 10: Chart of Code Results.

there is must make a call to create an order to be placed in
the event it will send back out to the waiter. It then makes a

An example of our evaluation is given below in section

final check changes its behavior to a waiting state.

5.2.1. Some behaviors, such as entering and leaving thegame, were fundamentally the same and thus were not

6.

Discussion

evaluated.

6.1

Survey Findings

As we discussed in the preliminary findings, the results
5.2.1

Customer Placing Orderwere quite similar. From a player’s point of view, they did

The behavior of the customer placing an order shows

not pay enough attention to note the small differences that

more improvement for the IE over previous evaluations. As

might come up by using two different AI systems. In someshown in table 3, the number of lines needed to run thecases, they even perceived a difference when there was none

behavior in the Standard game uses 2 more calls that must

there.

be made every turn. The IE, on the other hand, does have ahigher number of individual checks and calls.

In the IE for instance, the participants ranked thecustomer’s behavior with the player significantly lower thanThe Standard gets its 2 every-turn calls from the inability

in the Standard. The code and mechanics though, in bothof the customers to directly call the waiters. The Standard

games, was exactly the same. The customers gave the exact

must check every round for customers needing to order.

same responses in each game, and were interacted with inSince a waiter can only handle one customer at a time thethe exact same way (standing near them and hitting the ‘f’other customers needing to order must spend every roundkey). There was likewise no difference in the delay between

sending out requests to have their orders taken until they are

responses in either game and they were drawn to the screen

serviced. The second reoccurring call comes from insidein the exact same way. Likewise, the barkeep’s overall

their ordering state as they must check every turn if the

behavior was also graded differently though the code andwaiter is close enough for them to give their order. The loop

implementation was equal.

comes from once again having to loop through all thecustomers to get its order request sent out.

But, there were areas where they were graded similarly by
the participants; even if in some cases the code was different.

The IE also has its usual one for loop that is required to

The waiter’s behavior with the bar and the player weresend/receive events to start the behavior and another tograded nearly identical. Interestingly enough, the waiter’s

check the range for the event. Once inside though it requiresbehavior with the bar was the same in both games; but when

its own agent system. Considering the small-scale anddealing with the player each game’s waiter had quite

simplicity of the games it isn’t hard to see the number ofdifferent approaches. In the Standard, the waiter gave

repeat checking getting larger with the game size in the FSM

preference to the player when they called for an order. On

game. The IE, on the other hand, would continue to keep its

the other hand, the IE’s waiter queued up each response forneed for constant checking to a near minimum.

an order and then took them in that ordering (meaning if theIt does come at a small cost though, as the IE consistently

player didn’t call “first” they would have to wait their turn).

uses more calls and checks to run its behaviors. As a sideThis suggests that as long as the behaviors given are equal

effect of letting behaviors be triggered by events, it always(both games have the waiter come to the player to take their

had to at minimum run through the list of objects to find theorder, and both games have the waiter chat to the player and

one to send it to and then have the object check to discern

the player answer back with his order) that the actual

what type of event it was once it was received. This ismechanical differences working the background (giving

something that grows larger in waste as the size of the object

preference to the player or not) aren’t as easily noticed.

array grew and needs to be taken into consideration. If

Throughout all the results, it gives a clear picture ofefficiency was needed there are solutions like sorting theequality. Given each game had the same behaviors andobject array by ID or the range of the objects with respect tointeractions available to the player it was shown the games

the player.

thus give an equal level of believability. While small

Overall though, the cost of constantly checking variables

differences in the execution of the behaviors can be present

and states will waste more processing time and resources

between different systems, most went unnoticed and did notthan a few extra checks. Furthermore, as found in themake a large impact on the final evaluation.

behaviors involving food orders, the IE had the advantage of

It was also shown that the overall experience whenbeing able to pass the actual order class inside the event it

playing a game, can color the perception of different areas

broadcasted allowing for the order to be changed andregardless of the actual differences that exist. In the case ofmanipulated. In the case of the Standard it had to store theboth games, they had areas that were graded with a clear

order inside itself and lock it away until it received approval

difference but were in reality coded and behaved the exact

from the waiter.

same way. This gives the appearance of the overall game
experience and player mindset from other behaviors andinteractions helping influence their thoughts and feelings onother parts of the game.

7.

Conclusion
The behavior evaluations of the IE showed equal levels of

believability to the industry-standard systems of FSMs andscripts. Given equal behaviors and interactions, the games

6.2

Code Findings

were ranked equally. With further testing in future studies,

The coding findings showed a good pattern of thewe expect to find a difference felt by players as new

differences between the IE and the Standard game. In the

behaviors are introduced into one game, while the othercase of the IE game there were no calls that needed constantgame stays the same. Since new behaviors can be easily

checking; they were erased by the inherent architecture ofcoded and introduced into our IE, if the difference felt by

the IE system. The Standard on the other hand consistently

players is significant enough; the benefits and uses of an IE

had at least 1 value that would need constant checking to

could be further shown. As the ground case has been provencover for its inability to communicate and interact outside ofequal (i.e. with equal behaviors, different coding practices

achieve the same results in subjective terms) we plan tofurthering the theory of video game artificial intelligence forfurther expand on showing both the importance of adding

future systems and games.

new behaviors to improve player perception and showing theReferences
Parker, L,. The future of A.I. in Games.
Gamespot,
November
11th,
2010,
<http://www.gamespot.com/features/the-future-of-ai-in-games-6283722> (Jan. 15, 2012).
[2] Woodcock, S., Game AI: The State of theIndustry. Gamasutra, August 20th, 1999.
<http://www.gamasutra.com/view/feature/3371/game_ai_the_state_of_the_industry.php?>(Oct 20, 2011).
[3] Sturtevant,N.
R.,
Memory-Efficient
AbstractionsforPathfinding.
(2007).
Proceedings of the 3rd Artificial Intelligence
andInteractive
DigitalEntertainment
Conference, 31-36.
[4] Champandard, A., and Gyrling, C., Animating
in a Complex World: Integrating AI and
Animation. (2009). Proceedings of the Game
Developers Conference AI Summit.
[5] Mark, D. (2009). Behavioral Mathematics forGame AI. Course Technology PTR.
[6] Rabin, S. (2008). AI Game Programming
Wisdom 4. Charles River Media.
[7] Russell, S. J., and Norvig, P. (1995). Artificial
Intelligence: A Modern Approach. Upper
Saddle River, N.J. Prentice Hall.
[8] Game Developers Conference. June 12th, 2012,<http://www.gdconf.com/> (May 24, 2012).
[9] Game AI Conference. June 12th, 2012<http://gameaiconf.com/> (May 24, 2012).
[10] Lee, D., and Yannakakis, M. (1996). Principles
and Methods of Testing Finite State MachinesA Survey. Proceedings of the IEE. Volume 84,
number 8, 1090-1123.
[11] Colvin, R., and Hayes, I. J. (2010). A Semantics
for Behavior Trees. The University of
Queensland.
[12] Cerpa, D. H., Champandard, A. J., and Dawe,
M. (2010). Behavior Trees: Three Ways ofCultivating Strong AI. Presented at Game
Developers Conference AI Summit.
[13] Riedl, M. O. (2005). Towards Integrating AI
Story Controllers and Game Engines:
Reconciling World State Representations.
Proceedings of the IJCAI Workshop on
Reasoning, Representation and Learning in
Computer Games.
[14] Isla, D. and Blumberg, B. (2002). Blackboard
architectures, AI Game Programming Wisdom.
Charles River Media, Inc, 333-344.
[15] DeLoura, M. The Engine Survey: General
2009.
Results.
Satori,March
5th,<http://www.satori.org/2009/03/the-engine-sur
vey-general-results> (Feb. 9th 2012).

more efficient coding method achievable by an IE.
Small scale testing of the code showed the ability of thesystem which can rid itself of excessive redundant variablechecking which you might find in a more traditional FSM or
behavior tree system. While larger and more scaled up
games have not yet been tested using the Interactive
Environment, we see the benefits as showing greater
improvement while the testing environment is scaled up.
In modern game development, deciding between having
agents being autonomous or simply scripted is a situation
every developer faces. The state of current architectures
seem to acknowledge this point but rarely accommodates
both. The future for making better games which draw in theuser and make for more realistic gameplay is something that
won’t choose sides but instead tries to close the gap between
the two. It’s no longer good enough to simply keep building
up architectures that only work within the confines ofthemselves. Instead it’s better to look toward being able tocommunicate and share with other systems.
Incorporating a system that allows for communicating
between agents and other objects in the environment will
open up a number of different paths for allowing bothautonomy within script and reducing the waste associatedwith constant checking in autonomous systems. The goal isto spread out more of the burden of behavior off the agentsthemselves and allow for a much more interactive
environment for behavior to be made in. While manytechnical and coding issues must be overcome, the first stepto making any new game architecture is creating andbringing forth the theory behind it. We anticipate creating agreater awareness of the power and ease of using theenvironment to create more game AI systems like in ourInteractive Environment; and by bringing this awareness,[1]