1

Knowledge is Power, an Overview of AI Knowledge Representation in
Games
Daniel Brewer

1 Introduction
Artificial Intelligence systems process data to make decisions. The algorithms used to makethese decisions are often the focus of intense discussion. However, the behavior of an agent
is far more dependent on the data provided to the agent, than on the algorithm used to makeits decisions. It is therefore important to analyze the requirements of the design and provide
the agents with the required information to perform the role the designer intends [Carlisle13]. This article will present an overview of commonly used data representations in games
and illustrate how to improve agent behavior by providing the right information.
2 Categories of Knowledge
Every game has different requirements for its AI systems. The data to make decisions can be
split into three broad categories: Static Environment Data
 Dynamic Spatial Data
 Entity Specific Data

2

Static Environment Data, as the name suggests, involves representing the gameworld itself to the AI systems. This is data that does not change at runtime, or changes very
rarely. It represents the physical structure of the level and is what our agents use to find their
way around, or select positions to move towards.
Dynamic Spatial Data is used for representing spatial relationships that are affectedby the environment and change over time. Typically this includes territory and influence
over the world that shift as the game progresses.
Any data used to make decisions about a particular ‘thing’ in the game falls under
Entity Specific Data. It is potentially the broadest category and is the most game-play
specific. This information will vary dramatically based on the requirements of the design.
3 Static Environment Data
Static Environment Data represents the structure of the game world. The most common form
is navigation data for path finding. In an action or strategy game, it is important to represent
tactically relevant information about the level, such as the region connectivity andchokepoints, visibility approximation, and areas of operation for agents. This data also
represents physical objects in the world that the agents are required to interact with, such as
doors, vending machines, switches, etc.
3.1 Navigation
Navigation and path finding is one of Game AI’s eternal problem spaces. As environments
and the movement requirements of agents grow in complexity, so too does therepresentation of the navigable space. Agents are no longer simply required to find theshortest path, but instead should select an appropriate path for their behavior. For example, arogue character might prefer to remain in the shadows and move across soft carpets insteadof stone floors where his footsteps might be heard.
Finding a route through a level is traditionally handled by a search algorithm, such as
A*. These algorithms treat the world as a connected graph. The nodes of the graph represent
locations in the game world. Traversable routes between nodes are represented by links
connecting the nodes in the graph. The more features you need the agents to respond to, themore detailed and complex the graph. A more complex graph will use more memory and thelonger the search algorithm might take to find the desired route. The trick is to represent theleast amount of detail required for the agents to behave the way the designer wants.
There are many possible navigation representations [Tozour 04]. At the basic level,
you need to represent the valid, navigable areas and which places are blocked by obstacles.
If an agent requires extra information, such as illumination levels or surface type for ourrogue above, this data needs to be annotated in the navigation data. For our rogue characterin the example above, we would need to mark the surface type of each node - which arecarpet and which are stone. We would also need to annotate the illumination level of eachnode in order to identify which nodes are in shadow and which are in the light.
Regular grids are a popular and well-studied representation. The resolution of thegrid is uniform. You are either representing a big large open area with many tiny cells, or
you’re grouping everything in a large cell together and may miss obstacles or block off

3narrow passages, as Figure 1 illustrates. Any region annotations are per grid cell. It is
important to select a grid resolution detailed enough to represent the different regions.
Navigation meshes (NavMeshes) are very popular for continuous worlds. They
represent the simplified walkable surface. The advantage is that they adapt to the underlying
world. Large open areas can be represented by few large polygons, whereas tight, denseareas will be represented by many smaller polygons. The edges of the polygons do not need
to be axis aligned either, which allows them to conform to the floor better around irregularobstacles. Region annotations are per polygon. However, since we are not restricted to a
uniform polygon size, we can tessellate the polygons to add more detail as required.
It is possible to store the path finding cost for different regions directly in thenavigation data. This is too restrictive though, as it means all agents will use the same costs.
We may want the palace guards to not care about the illumination and floor surface, while
the rogue does care about this data. It is better to use flags or tags for annotation and thenallow the individual agents to have different heuristics for interpreting the cost of theregions. This way the world representation doesn’t change, but the agents’ interpretation ofthat representation can change and can result in different behavior depending on thesituation. The rogue may prefer to stay in the shadows while sneaking around, but once he isfound and decides to flee, he can change his heuristic to simply find the fastest route away.

Figure 1
A NavMesh is used to represent the map on the left, while a regular grid isused for the same map on the right. Note that in this case, the grid is too low a resolution tocapture all the navigable space behind the pillars in the corner.
3.1.1 Dynamic Navigation Changes
So far we’ve handled the static, unchanging environment. If the level can change
dynamically at runtime, we need a way to update our navigation representation. Some ofthese changes may be predetermined - e.g. a canal that can be emptied or flooded, or adrawbridge that can be raised or lowered. Sometimes the changes can be completely

4dynamic. Perhaps the player can throw a Molotov cocktail and create an area of fire
anywhere in the level.
Regular grids have the advantage of being very efficient to modify at runtime. The
affected cells can be determined quickly and the appropriate flags changed. Modifying
NavMeshes at runtime is trickier. For predetermined changes, it often simpler to demarcate
the areas that will change at design time and then toggle the flags appropriately when theworld changes at run-time. However, for the completely dynamic changes, you either needto perform cuts and merges on the polygon data to patch in changes, or be able to quickly
rebuild the NavMesh. Rebuilding the entire level can be time consuming and wasteful, so acommon solution is to build the NavMesh out of many smaller tiles. This is almost a hybrid
large regular grid + NavMesh approach. Each tile might be 10m x 10m or 20m x 20m andthen if any dynamic changes are required, only the tiles containing changes need to berebuilt and patched into the NavMesh structure.
3.1.2 Other Representations
Waypoint graphs are a nice, efficient representation for sparse navigation data. If you areworking on an interstellar space game with fixed hyperspace routes between systems, thenwaypoint graphs are your best representation. Each system would be a node and each link
would be a hyperspace route between systems.
Waypoint graphs are also useful for a high level representation of the map. In a
competitive arena shooter, each room of the map can be represented by a node and thecorridors and doorways between rooms can be represented as links between nodes. In a
grand strategy game, countries can be represented as nodes and the borders and travel routes
are the links. Corridor maps and road networks are other commonly used representations
and are effectively waypoint graphs where the widths of the connections are annotated in the
representation.
Grids and NavMeshes are typically used for agents that have to move along the
ground. Agents that can move freely in 3D, face new representation challenges. 3D regulargrids are simple, but extremely wasteful and dense. Waypoint graphs get complicated when
the obstacle geometry is dense.
If your agents are restricted to flying over terrain, then height-fields can be a good
representation. You are effectively using a 2D grid with the height of the tallest obstacle
stored in each cell. The agents can then determine whether it is quicker to fly over or aroundan obstacle [Josemans 17].
However if your agents are required to navigate through geometry, such as flying
through the wreckage of a destroyed spacecraft, or if there is no ground surface, then asparse voxel octree representation may be more appropriate [Brewer 17]. This would have
many small nodes around dense obstacle volumes and few large nodes around open spaces.
3.2 Off-nav links
As game environments get richer, more detailed and more realistic, we expect our game AI
agents to traverse these environments in interesting ways. Vaulting a short wall or railing,jumping across a narrow gap, clambering up a wall onto ledge, and sliding down a zip-line
are all commonplace actions we expect agents to perform. We need to have some way to5represent these actions to our agents’ path finding search so they know that they can vault arailing from a walkway to land below instead of taking the long way around via the stairs.
Off-nav links are a common way to represent these actions. These are links between
nodes not represented in the native navigation structure. These nodes do not need to bepreviously connected, nor do their relative positions matter. What matters is that the agents
now know they can go from one area to another by using this new link.
Not all agents may be able to use all these links. The path finding search should only
follow links that are open to the agent. An agile agent should take advantage of jumps,
vaults and zip-lines, while a heavy, lumbering agent should not take these short-cuts andinstead take an alternate route. This means for each of these off-nav links, the pathfinderneeds to test if the link is suitable for the agent.
If the number of different types links is prolific, or the requirements for the links
overly complicated, the off-nav link can provide an evaluation function to return whether thelink is suitable or not, or to provide an extra cost value for using this link. However this is
not the most performant method. The types of links can often be reduced to a reasonable setof core capabilities, in which case a simple bit-mask can be used to represent therequirements for the link and the capabilities of the agent. Comparing these bitmasks is avery efficient way to filter out invalid links.
Off-nav links are often represented by smart objects. This allows all the complexityof performing the action to be encapsulated in the smart-object and essentially hidden fromthe path finding search. The path finding code doesn’t need to know how to use a ladder; itjust needs a quick way to test if the agent can use ladders, and to know that a ladder provides
a route between the ground and the roof.
3.3 Smart Objects
Smart objects are one of the unsung heroes of game AI knowledge representation. At theiressence, a smart object is an abstraction that encapsulates some arbitrarily complex gamelogic behind a simple interface and ties this logic to a particular location or entity in theworld. This is a way to embed knowledge in the world, instead of encoding it in an agent.
The agent only needs to evaluate and start the smart-object executing and wait until it iscomplete. The Sims is the poster child for how smart objects can be used to extend thecapabilities of agents and make them seem more aware of their environment [Bourse 12].
A simple example from an action game is an alarm switch. An agent who notices theplayer may have a behavior that checks for useful smart objects. If the alarm has not yet
sounded, this search may return a nearby alarm switch smart object. This smart object would
be responsible for providing the appropriate destination position and facing for the agent tomove towards and once the agent starts executing the smart object, it is the smart object, notthe agent’s behaviors, that determines the animation to play to press the button and would
also start the alarm sounds, flashing lights and start the reinforcement spawning system tosummon more agents to the area.
A more complex example might be a ladder. Smart objects are often used torepresent off-nav links as they just have to advertise the connection between areas and thenhandle all the mechanics of traversing the link internally. An agent might path through aladder smart object to get to a position on the roof. The ladder smart object would have its

6

own internal state machine that would cause the agent to play a get on ladder animation andthen loop a climbing animation while moving the agent up the ladder and finally play a get
off animation at the top before completing and allowing the agent to continue to his
destination.
The uses of smart objects are prolific: switches, doors, off-nav links, gunemplacements, treasure chests, cover points, patrol points, queuing at the bar, positions
around a campfire, or door-breach points for a swat entrance and so on. Using smart objects
requires the AI system to only decide which smart object to use, without needing to know all
the details of the object. A lot of complicated decision logic can be encapsulated in a simple,
designer-placed smart object.
3.4 Tactical Information
A lot of decisions in action and strategy games revolve around deciding where an agent
should move and how he should get there. Agents seem smarter when they show some selfpreservation instincts and take up firing positions in cover, or try to break line of sight with
their target. It can also be beneficial for agents to have an understanding of the overall flow
and structure of the level, such as choke points and good vantage points. It is important foragents to be able to identify these features, which requires we represent them to the agents.
3.4.1 Cover
Most simply, cover can be stored as a collection of discrete cover points. Each location
would need to store a position, a direction from which cover is provided and some flags to
select the appropriate animations to use. The cover selection algorithm can simply collectthe cover points, score them to determine the most useful ones and select the point with thebest score. While this provides good information about where to move, it doesn’t help
provide any information about what is obscured by the cover.
Instead of discrete points, cover can be represented by line segments. An agent cantake up position anywhere along this line and be in cover. Each segment needs to provide
the direction and height of the cover provided. This extra information is common to all
possible points along the segment. For position selection, one can simply generate a numberof points along the segment to be evaluated. By connecting segments together into chains,
agents have additional information about how they can move while staying in cover or canreason about where a target might move from a cover location.
Another advantage of using line segments for cover is that it becomes possible to use
this information to help identify areas of open space that are obscured. Since the cover line
segment effectively reduces the collision geometry down to a rectangle, a frustum can beconstructed from the silhouette, as shown in Figure 2. This frustum can be used to quickly
determine line of fire between positions without performing ray-casts against the collisiongeometry. It can also be used to weight path finding queries to get agents to take moredefensive routes through the environment [Brewer 13].

7

Cover frustum
obscures this area
Cover Points

NavMesh edges
for Cover Segments

Cover Segments

Figure 2
Different types of cover representations are shown on the left. The rightshows how a simple cover segment can be used to create a frustum approximating the coverprovided by an obstacle.
It is possible to use the edges of the NavMesh directly in place of independent coversegments. All that is required is to add extra annotation to the NavMesh edges to identify
whether they are against a wall or obstacle that can provide cover and how tall that obstacle
is. This does not require a separate data-structure for the cover and allows the cover query totake advantage of the floor layout to provide cover within a determined movement distanceinstead of straight line distance. However often the NavMesh will have extra edges to roundcorners and may have more detailed edges where a single line would be more appropriate.
Cover markup can either be placed manually by designers, or automaticallygenerated. An automatic system could take the edges of the NavMesh as input, and thenpost-process them to construct simpler cover segments.
3.4.2 Areas of Operation
Designers often want to choreograph how a particular encounter will unfold. Detailed
scripting of every agent’s actions is not only tedious, but highly error prone as each player islikely to tackle the encounter in a different way. Instead of assigning specific positions foragents, it is often more useful to provide agents with a volume in which to operate. The
agent’s systemic behaviors and position selection systems are still in control; however, thepositions considered are filtered by the area of operation.
This can be handled explicitly with scripts assigning specific agents to specific areasof operation. It can also be controlled indirectly by designers adjusting minimum andmaximum agent counts in areas and having agents assigned systemically [Isla 08] [Gallant
17]. Adding connectivity mark-up between areas of operations, simplifies the direction of
agents. NPCs that find their area of operation invalidated can automatically follow the linkto the next fallback area of operation. This can allow designers to stage complex fighting
withdrawals and ambushes, such as the maneuver shown in Figure 3.

8

Figure 3
An example encounter setup to retreat ahead of the player, drawing him into
an envelopment counter-strike.
3.4.3 Tactical Graph
When making tactical decisions, it is important to reason about the structure and flow of themap. The navigation representation can certainly help, but it is often too detailed. A
NavMesh will allow you to identify the free space between some trees, but will not easily beable to tell you about the forest. It is often useful to have a higher level representation of theflow of the map. What are the main regions of the map? How are these regions connected?
Where are there choke-points?
A structure similar to a rough corridor map can be useful to represent thisinformation. It should not be a detailed representation of the navigation space however. It
can ignore most small obstacles and merge together areas into semantically distinct regions.
If there are only two routes into a region of the map, then those are the areas thatneed to be defended from attack. If one of those routes is very narrow and restrictive, thenfewer defenses will be needed to cover that route, while a wide, open route would require
more significant defenses. This is the type of information that can be stored in a tacticalmap, such as that illustrated in Figure 4.

9

Figure 4
An example tactical map for a small castle. Note that the detailed navigation
representation is not required, only the high level structure and flow.
Note that this structure is similar to a high-level in a hierarchical navigation
representation. It is useful to represent tactically significant connections between areas. For
example there may not be a direct route to move from a courtyard to an overlooking
balcony; however, it may be possible to see the one area from the other. This information
would be useful for a position selection algorithm. The visibility information is only anapproximation. It should not be used to determine if a target can be seen, but only if it might
be possible to see a target from a location. The distinction is subtle. This approximation
should be used for an early filtering pass when evaluating possible positions.
4 Dynamic Spatial Data
Even though the physical structure of a map may be static, the positioning of units can resultin many dynamic situations. It is useful to be able to predict and react to these changing
situations. This is where it is useful to have a map of values representing changing
information in a way that reacts to and responds to the environment.
Influence maps are often represented as an array of values correlated to a grid orgraph [Mark 15]. Values accumulate in cells in a grid, or nodes of a graph, and the values
spread out and dissipate through neighboring cells in the grid, or connections in the graph.
Since the grid or graph is usually correlated to the structure of the map, these values tend toflow around obstacles and through channels in the map.
It is often simplest to represent an influence map as an array parallel to a navigation
representation. This allows you to reuse the connectivity information of the navigation
representation and means your influence map is only an array of values, instead of a more
complex structure. However the larger and more detailed the navigation representation, thelarger the influence map, which can result in significant overhead processing the influencemap. It is therefore useful to use a coarser graph structure, such as a tactical graph, instead

10of the most detailed navigation representation.
Influence maps are commonly used in strategy games to identify areas where theopponent is strong or where they are weak [Dill 15]. However, there are other uses. If you
spread influence from the player’s position and consider the difference in influence overtime, areas ahead of the player will have rising influence while areas behind them will havefalling influence. Figure 5 shows how this can be used to predict where the player isheading.
Influence has decreased
B

B

A

A

Influence has increased
Figure 5
When the unit moves north, the influence at B is actually decreasing due tothe structure of the map, while influence at A is increasing. The unit is therefore moving
towards A and away from B.
Adding influence to areas that include agents, but not spreading this influence toneighboring areas, results in agents leaving a trail of influence behind them. This can beused to get agents to spread out and explore the map. Having the value decay slowly willallow agents to circle back again.
Occupancy maps are simply influence maps with a modified influence propagation
function [Isla 09]. Influence originates at the target’s position, but is eliminated in areas
visible to the agents and accumulates in areas hidden from the agents. This then represents
the probability that a target might be hiding in an area and allows agents to infer the possible
routes the target might have taken through the map.
It is often useful to know the territory owned by rival factions. A simple distancevolume, such as 10 miles from the city, does not take into account how the terrain may
impact the territory. Figure 6 shows that using an influence map will allow for this territory
to conform to natural boundaries such as rivers and mountain ranges.

11

B

B

A

A

Figure 6
Simple distances (left) is not as accurate as an influence map (right) for
determining how natural barriers affect territory.
It is possible to use influence maps to simulate the spread of a dynamic hazard, suchas a fire, or an oxygen leak in a spacecraft. Add influence at the source of the hazard andspread it through the connections in the graph. It is useful to modify the spreading function
to not spread through closed doors or barriers.
Influence maps are not just for strategy and actions games. They can be used insocial systems too. Each character or faction can be represented as a node in a graph and theconnections between these nodes can be weighted based on the relationships between thecharacters or factions. This can then be used to determine the impact an action will have on
the social landscape.
5 Entity Specific Data
These are the things your agents need to know about the other active entities in the game. It
is the most varied type of knowledge you need to handle in your AI systems and is highly
dependent on the type of game you are making. In an action game, this would include
information about targets. In a racing game, this would be information about the other carsin the race. In a high strategy game, this may also be information about the enemy
civilization, what technology they’ve developed and resources they have to trade.
Instead of having the behavior layer query the world directly for possible targets, it isoften useful to split off these queries into a separate perception system. The perception
system is then responsible for checking which relevant entities can be seen or heard for eachagent [Welsh 13]. Each agent can then be provided with its own list of entities it is aware of,and what information it knows about these entities.
5.1 How to store information:
There are many different ways of managing and storing entity specific data. The gamedesign requirements will usually dictate which architecture is most suitable. We discuss a
few common options below.
5.1.1 Target Information Struct
Action games typically do not require a lot of target knowledge. At a minimum, enemy
agents will need to know which targets they are aware of, if they can currently see a specific12target and where they last saw that target. A simple struct can be used to store known
information about a target, for example:
struct TargetInfo{
targetEntity
isTargetVisible
lastKnownPosition}
An array of these structs allows an agent to track multiple targets. The benefit of thismethod is that it can be very compact in memory and allows fast random access. The
downside is that the structure is rigid and all targets will have the exact same members. If
additional information is required, extra data members have to be added to the struct and thecode recompiled. Now all targets will have this new data, even if they do not require thisspecific information for a specific target. This is still a good method to use if the number ofdifferent properties we care to track is small and uniform across most targets.
5.1.2 Stats and Tags
Some games may require more flexible and nebulous information about entities. Tags are
simply an optional label we can give a character. For example, we may want to know if acharacter is Brave, or Happy, or Foolish, and so on. A character can have an array of tags
and we can configure these offline at design time, or add and remove tags at runtime to track
dynamic changes. If the number of tags is limited, we can use a simple enum for each. Or we
could use a Symbol or Class to represent them. [Graham 18].
Stats are almost just like tags, except they have a numerical value associated withthem. So instead of tracking if a character is Brave or not, we can have a Bravery stat and acharacter can have Bravery 70%, or Bravery 40%. These fuzzy values allow for morenuanced behavior from our characters than would be possible with binary tags. The valuesof stats can be fixed and specified by designers, but can also change over time or in responseto actions or events in the game. In The Sims, a character with a high Hunger stat, will finda smart object that can satiate her Hunger and after performing the action, her Hunger will
be reduced [Bourse 12].
If the information needed is a simple boolean, e.g. hungry or not, a tag is mostappropriate. However, if a more fuzzy value is desired, e.g. how hungry is the character,then we required a stat. Tags and stats can be stored either on the specific entity to which
they belong, or as Entity-Tag / Entity-Stat key-pairs in a table.
5.1.3 Event History
For some games, it is useful to keep a history of perceived events. It may not be enough toknow if an agent can see the player in a restricted area, but also to know if the agent has seen
the player enter the restricted area multiple times [Vehkala 13]. Depending on therequirements of the game, this history can be stored in a few different ways. We can add thetag PreviouslySeenInRestrictedArea to the player once an agent spots her. Or we canincrease a NumTimesSeenInRestrictedArea stat on the player each time she is spotted. For aneven more detailed history, we can use a database with a time-stamped log of all theperceived events. Table 1 shows an example of a possible history of an agent spotting the13player, then losing sight of her briefly and then hearing and seeing her again a few seconds
later.
Table 1
Time
135.6
135.8
142.2
143.4
143.5

An example of a history of perceived events
Event Type
EntityPerception Type
Enemy Target
PlayerVisibleEnemy Target
PlayerVisibleCombat Sound
Player
Heard
Enemy Target
PlayerVisibleCombat Sound
PlayerHeard

Position[20, 0, 15][18, 0, 16][16, 0, 23][18, 0, 23][18, 0, 23]This history can quickly grow in size and memory if left unchecked. We can keep it
manageable by truncating the list to a set number of entries, or discarding entries older thansome max time limit. If we need to remember events over a longer term, we can record themore salient information in a more compact, long-term database that can persist for theentire game.
5.2 Public vs Private
Some information is public knowledge that all agents should know, e.g. in a social game,everyone should know that Sam is dating Fred. However, some information might only beknown by the specific agents who have perceived the event, e.g. Guard 1 can see the player,
but around the corner, Guard 2 cannot. Some games may require all private knowledge.
Some may be able to work with all public information. Others may require a mix of bothprivate and public knowledge.
Private information that should only be known by specific agents should be kept
local to each agent. For example, each agent should have their own Target Information array
to contain the information about the targets they are aware of. Each agent manages their own
knowledge and each agent can have differing information about the world.
Public information is common to all agents and should be stored in a central place.
All agents can reference this common information and any state or changes will beaccessible and known to all agents. A good example is Prom Week, which uses a commonsocial facts knowledge base to track the social interactions between all the characters[Mateas 13].
5.3 What information do we need?
The information to track per entity is highly dependent on the design of the game. A social
interaction game, like Prom Week, will require very different information than a stealthaction game like Hitman, or an action shooter game like Halo. We cannot cover all theoptions in a single article. The key is to have access to the minimum amount of information
to allow the agents to make decisions according to their design in the game. The more entity
specific data knowledge we track, the more complex and believable we can make our agents
behavior. We will go into some simple examples for an action game to illustrate the point.
The most commonly used data about targets are visibility and last known position. It

14

can be useful to store the last seen time, or time since seen, rather than just a boolean flag for‘is visible’. Agents can then still consider targets visible for a short time after losing line ofsight. This adds robustness when a target is only momentarily obscured.
Keeping track of the target’s last known position, instead of current position, allows
your players to trick and manipulate the agents instead of them having omniscientknowledge of the player’s whereabouts. Note the use of the term ‘last known position’instead of ‘last seen position’. An agent may have other senses than sight and can update
their knowledge of a target’s position if they hear a sound he makes, or if a teammate relays
the target’s position.
If you do have agents sharing target knowledge, it is useful to have a flag to indicate
whether the agent has personally witnessed the target or only has secondhand information.
An example where this can lead to better gameplay is for a behavior to trigger the alarm.
Consider a player entering the L-shaped corridor shown in Figure 7. He sees one agent
immediately in front of him; however, another agent is waiting around the corner, where
there is no line of sight to the player. The first, visible agent sees the player and informs his
teammate. From the player’s point of view, it would be unfair for the hidden agent toactivate the alarm based on secondhand information. It would be better for the first agent,
who can actually see the player first hand, to run for the alarm. Not only does this makemore sense to the player, it provides him the opportunity to prevent the alarm from being
triggered.
Alarm

Alarm

B

B

A

A

Figure 7
On the left, agent A has witnessed the target first hand and should go for thealarm, while agent B only has second hand information. On the right, agent A has heard thetarget, but not yet seen him. Agent A should turn around to first see the target before runningfor the alarm.
Additionally, more meaningful behavior can be crafted by keeping track of the typesof information perceived. Tracking whether an agent has seen the target versus only heard
the target can result in more believable behavior. In a similar situation to the one above, if
the first agent had his back to the player and just heard a noise, it would make more sense
for the agent to turn around to see the source of the noise, instead of running directly for thealarm switch.
Another useful property is to store whether the target is reachable. A failed pathfinding query can take significant processor time. It is better to avoid continuously
performing path finding queries that you know will fail. If you fail to find a path to thetarget, you can mark that target with an unreachable flag. This way you know not to try path15

to that target again, until the situation has changed. Once the target has moved significantly
away from this unreachable position, or the level has changed (such as a previously locked
door is now open), you can clear this unreachable flag to allow another attempt at finding apath to the target.
Knowing that a target is unreachable is also useful for constructing fallback
behaviors. A melee focused agent could select a different target, one he can reach.
Alternatively, the agent could switch to a range weapon and attack from a distance. Having
this information allows your agent to make these decisions intentionally.
Interesting behavior can be crafted by knowing what weapon the target is wielding
and where he is aiming. A trivial example is having the agent play a sideways dodge
animation if he is being aimed at, however it may be unnecessary to dodge if the opponent
only has a melee weapon and no ranged weapon. A more complex behavior might be for aswashbuckling game. If the player is armed with a single-shot flintlock pistol, it would makesense for the agent currently threatened by the pistol to remain still while other agents, who
are not being aimed at, can cautiously circle around and approach from a flanking direction.
If the player only has his sword equipped, the agents can all approach more aggressively.
These examples are all very action game focused; however, the same principle
applies to other genres. By having each agent determine this information based on whether
he can perceive that information, makes the agents more believable and allows for the player
to apply more interesting strategies to engage with the agents.
6 Conclusion
Whenever we make game AI systems, we are translating parts of the game design into
something the computer can execute. Agents require data to make decisions and exhibit thedesired behavior. Richer behaviors can be crafted by providing richer information to agents.
Information can be embedded in the world, or gathered via messages and sensory systems.
When constructing behaviors for an agent, we should take the time to plan what data will be
required for the agent to exhibit the behavior, rather than focus on which behavior selection
algorithm to use.
7 References[Carlisle 13] Carlisle, P. A Simple and Robust Knowledge Representation System. In GameAI Pro. ed S. Rabin. Boca Raton, FL: CRC Press, pp. 433-440[Tozour 04] Tozour, P. 2004. Search space representations. In AI Game Programming
Wisdom 2, ed. S. Rabin. Hingham, MA: Charles River Media, pp. 85-102.
[Josemans 17] Wouter Josemans. Putting the AI back into Air: Navigating the Air Space of
Horizon Zero Dawn. Game AI North 2017. Available online (https://www.guerrillagames.com/read/putting-the-ai-back-into-air)[Brewer 17] Brewer, D. 2017. 3D Flight Navigation Using Sparse Voxel Octrees. In GameAI Pro 3, ed S. Rabin. Boca Raton, FL: CRC Press, pp. 265-274[Bourse 12] Bourse, Y. 2012. Artificial Intelligence in The Sims series.

16

http://www.yoannbourse.com/ressources/docs/ens/sims-rapport.pdf (accessed November 11,2020).
[Brewer 13] Brewer, D. 2013. Tactical Pathfinding on a NavMesh. In Game AI Pro, ed S.
Rabin. Boca Raton, FL: CRC Press, pp. 361-368[Mark 15] Mark, D. 2015. Modular Tactical Influence Maps. In Game AI Pro 2, ed S. Rabin.
Boca Raton, FL: CRC Press, pp. 343-364[Dill 15] Dill, K. 2015. Spatial Reasoning for Strategic Decision Making. In Game AI Pro 2,
ed S. Rabin. Boca Raton, FL: CRC Press, pp. 365-388[Isla 08] Isla, D. Building a Better Battle: HALO 3 AI Objectives. GDC 2008. Available
online(http://www.gdcvault.com/play/497/Building-a-Better-Battle-HALO
https://web.cs.wpi.edu/~rich/courses/imgd4000-b12/lectures/halo3.pdf)[Gallant 17] Gallant, M. Authored vs. Systemic: Finding a Balance for Combat AI in'Uncharted 4'. GDC 2017. Available online(http://www.gdcvault.com/play/1023949/Authored-vs-Systemic-Finding-a)[Isla 09] Isla, D and Gorniak, P. Beyond Behavior: An Introduction to Knowledge
Representation. GDC 2009. Available online (http://www.gdcvault.com/play/1267/(307)Beyond-Behavior-An-Introduction)[Welsh 13] Welsh, R. 2013. Crytek’s Target Tracks Perception System. In Game AI Pro. ed
S. Rabin. Boca Raton, FL: CRC Press, pp. 403-411[Graham 18] Graham, R. and Brewer, D Knowledge is Power: An Overview of Knowledge
Representation in Game AI. GDC 2018. Available online(https://www.gdcvault.com/play/1025172/Knowledge-is-Power-An-Overview)[Vehkala 13] Vehkala, M and De Pascale, M. Creating the AI for the Living, Breathing
World of Hitman: Absolution. GDC 2013. Available online(https://www.gdcvault.com/play/1017802/Creating-the-AI-for-the)[Mateas 13] Mateas, M and McCoy, J.An Architecture for Character-Rich Social
Simulation. In Game AI Pro. ed S. Rabin. Boca Raton, FL: CRC Press, pp. 515-530.
10 Biography
Daniel Brewer graduated in 2000 with a BScEng in Electronic Engineering, focusing on
Artificial Intelligence, Control Systems and Data Communications. Since then he has
become a veteran game developer. As lead AI programmer at Digital Extremes, he has been
instrumental in bringing the co-op, online, multiplayer action shooter, Warframe(2013) tolife, as well as continuing to further develop, maintain and upgrade the game AI systems in
the game. Other notable titles include Halo 4 multiplayer DLC packages(2012), Darkness II(2012), BioShock 2 multiplayer (2010) and Dark Sector (2008). Over the years, he haspresented numerous talks about various facets of AI at the Game Developers Conference.