Q & A with DICE AI Developer

**Q. & A. with DICE – Tobias Karlsson**

October 31, 2006

***Please introduce yourself***
and give a brief overview of your work in Battlefield titles.

My name is Tobias Karlsson. After I had completed my M.Sc. in Computer Science
I ended up at DICE more, or less by chance. At DICE, I started by designing the
AI for Battlefield 1942, and then implemented it together with two colleagues.
I then moved on to work on the AI for Battlefield 1942: The Road to Rome and I
was the lead programmer, as well as the AI programmer on Battlefield 1942:
Secret Weapons of WWII. I then went on to be the lead AI programmer for
Battlefield 2, and for the start of Battlefield: Bad Company. After that I’ve
helped finish Battlefield 2142 and now I’m architecting the AI for an
undisclosed title.

***There are many different***
types of artificial intelligent systems: expert systems, rule/case based
programming, heuristics, neural networks, fuzzy systems, hybrid systems,
genetic and evolutionary algorithms, etc.

Why was a
Reactive AI system chosen for Battlefield, and what similarities and
differences does Battlefield AI have with other game or non-game artificial
intelligent systems?

It is common to divide different AI solutions into two general categories,
reactive and planning (also known as proactive) systems. The different
approaches to AI mentioned above are either reactive or proactive (though some
systems may have parts that fit both categories). Reactive systems react to
perceived changes in their environment and choose actions that either are
getting them closer or that are preserving their goal state. Proactive systems
try to create a plan for reaching their goal states first, and then use this
plan to select the corresponding actions to execute. The problem with planning
systems is that if circumstances change enough, the plan will be invalid. A
plan necessarily contains some predictions about the future, and if it turns out
that these predictions turns out to be inaccurate, the plan becomes invalid. In
an environment such as the one found in the Battlefield games, the world is
very hard to predict, especially for any length of time. Also, the world is
very complex, which means that either the predictions need to be very short
term, or risk missing vital information. Also, as a general rule, the reactive
systems are much less CPU intensive. Given this, choosing a reactive approach
came pretty natural. The BF game AI is mostly reactive, but there are parts of
the system that aren’t or are a mix of reactive and planning systems. The
pathfinding is a classic planning system, using the ever popular A\*-algorithm.
The strategic AI (or SAI for short) is purely reactive, and has no sense of the
future (which may sound like a contradiction for an AI dealing with
strategies).

The Battlefield AI is based on an architecture called supersumption. I don’t
know how rare this is, but game AI is frequently based on Finite State Machines
(FSMs for short). In my experience, this is an architecture that is efficient
for small systems, but soon becomes difficult to expand and maintain.
Supersumption is an architecture that is used in the MIT synthetic character
group, but these systems aims at much more complex, and docile AI than that of
Battlefield.

***Battlefield AI consists of***
a number of components and layers: bots, behaviors and weights, knowledge, AI
templates, sensing, pathfinding, SAI, strategic areas, strategies, etc.

In which
of these (and why) does the BF AI developer spend the majority of his/her time
during development? During testing?

All systems that you mention have taken a considerable amount of time to
develop, but the most time intensive tasks are the low level systems (like basic
steering of vehicles), and the behaviors (including their short term plans).

***How does a bot see the***
Battlefield?

This is a difficult question to answer. The bots’ senses are quite different
from ours. To begin with, the sensing the bots is aimed to introduce
uncertainty, rather than the opposite that is true for biological systems. In
the game, we could always cheat and provide the bots with perfect information
about the world. This is also the easy way out. Most players, however, would
consider it to be unfair, and hence not feel that the game was as fun, if the
bot always knew exactly where the player was. Consequently, we need to provide
some kind of simulation of more human senses. This is done by doing raycasts
from the bot’s eyes to the position of the enemy (within the bot’s frustum)
that we want to test if the bot sees. If the bot sees the enemy, the bot will remember
the location off the enemy and which point on the enemy the bot saw. The bot
also updates its team’s common knowledge data base.

The bots of Battlefield 1942 were sometimes accused of being irresponsive, and
sometimes ignoring the player. To minimize these problems in Battlefield 2, we
allowed bots in the same squad or same vehicle to share this information, and
we also allowed bots to look at enemies outside their frustum whenever they got
hit so that they would respond faster when under attack.

***Why are sensing and***
pathfinding different systems?

Sensing and pathfinding has two very different purposes, and hence the outputs
of the different systems are very different. The same thing goes for how the
output is calculated, and what data is needed to do this. The output of the
sensing system is whether a bot can or cannot see a specific vehicle or
soldier. The output of the pathfinding system is a sequence of positions that
the bot needs to traverse in order to get from its current position to its goal.
The navmeshes of Battlefield 2 does not contain the information to correctly
check visibility, and they have no code support for doing 3 dimensional
raycasts. Instead the navmeshes contain only information regarding pathable
surfaces. The fact that one edge on a polygon in a navmesh isn’t connected to
another polygon only means that it is not valid to try to path across that
edge, it says nothing about the reasons for this (there could be a wall, and
abyss, or the end of the combat area). The navmesh is much simplified compared
to the detailed collision meshes that the raycasting of the sensing use.

***What makes Battlefield***
pathfinding so resource-intensive that it must be statically generated prior to
game runtime?

This is hardly unique to the Battlefield games. Most games, if not all games,
use precomputed pathfinding data. Anyone that has tried creating a navmesh for
a Battlefield 2 map knows how long time that take. Doing the same calculation
in real time is hardly feasible. Battlefield maps are also much larger than
maps of most games. A soldier occupies an area of about 0.1 m2 while the maps
can be over 16 million m2. The Battlefield maps are also highly complex in
certain areas, which mean that the precision needs to be correspondingly good.

***How will game AI***
pathfinding systems cope with the advent of many-body physics and
deformable/destructible environments?

This is a huge problem that faces many AI teams in the industry. The answer is
either that we don’t know yet, or we will cope poorly. As mentioned above, the
standard solution for pathfinding problems in the industry has been using the
A\* algorithm on pre-computed navigation data. The more complex and detailed the
levels become, the more time and CPU-power is used to compute the navigation
data. It is reasonable to assume that recomputing the navigation data in real
time will not be feasible for most systems in use today.

***Battlefield 1942 allows for***
up to 64 bots. Battlefield 2 allows for up to 108 bots (maxed squad members).
Battlefield 2142 allows for 108 bots plus and additional 256 autocontrollers.

Are these
increases a simple issue of available cpu and ram resources, or is this a more
complex situation involving the game engines’ capabilities and limitations?

The real limits for the number of bots in the Battlefield games are arbitrary
from the AI’s point of view, but rather limits are set in the game. Also, the
number of bots you can comfortably simulate varies greatly from system to
system, and it has turned out to be very difficult to sell the idea that the
performance of the AI can vary much in the same way as the performance of the
graphics.

***The more bots on the***
battlefield, does Battlefield AI complexity grow linearly or exponentially?
Why?

The complexities of different parts of the AI grow differently. Many systems,
like a bot’s pathfinding, are unaffected by the amount of bots. The cost of
constructing a path is independent on the number of bots in the world, so the
total cost of constructing path grows linearly with the number of bots wanting
to construct paths. Other systems, like the sensing system, are dependent on
the number of bots. When a bot check what it sees, it checks against all other
players to see if it sees them (there are lots of early outs, but the principle
is true). All bots need to check all other bots, so the total cost for sensing
grows quadratically with the number of bots.

***A common criticism of***
Battlefield AI by mainstream players/reviewers is that the AI is not
challenging, that bots are too predictable.

Is there
any validity to this criticism?

What, if
anything, needs to change or be addressed that would most greatly impact this
perception?

AI is probably the most unforgiving discipline in game construction. Anyone
knows what a valid behavior is, and is well adapted to spot players that behave
badly compared to that norm. Even the most powerful computer of today cannot
compete with a human brain in a general competition. Sure, they can perform
complex meteorological calculations and beat grand masters at chess, but the
‘simple’ act of seeing and through that comprehending the world at a near human
level is something that is far beyond the reach of today’s computers and
programs. A game AI that runs a on a fraction of the CPU of an ordinary home
computer cannot even begin to compete with humans. We know this, and instead of
trying to make an AI that is the intelligent in the true sense of the word, our
goal is to make the AI that is the most entertaining there is. Granted, the
Battlefield AI could be much more entertaining (and smarter) than it is, but as
with all projects we have a limited amount of resources, and the needs of the
AI are weighted against the needs of all the other systems that make up the
game. To make a long answer short, yes the criticism is valid, and it will
always be, there is always something that can be done better, and in the case
of the Battlefield AI, there are a lot of things that will be improved for
every new game.

At the same time though, I feel that the criticism is sometimes too hard. I
have, for instance, yet to read a review of Battlefield 2 that acknowledges the
significant improvements of the AI that were made over the AI in Battlefield
1942. And I also have yet to see anyone acknowledging that making an AI for
Battlefield is an extremely difficult undertaking. In Battlefield, there are
huge maps, a vast array of vehicles of very different types, and yet the AI is
compared to other game bots tactical infantry games and flight-sim pilots.

The first thing I would like to do with the Battlefield AI is to make it use
cover. The lack of self preservation that is currently prevailing in the bots
is their most obvious weakness. A more general skill, and somewhat related to
the covers, I would like to give the bots a much better special awareness.

***How are bot behavior***
weights derived?

Is this
type of weighting exclusive to Battlefield AI, or common among game AI, or
comparable with non-game AI systems?

This is mostly a process of trial and error. You spend a lot of time testing
and retesting situations in which you like the bots to behave in a certain way.
You keep on tuning them until you are happy with the results.

As for other AI systems, I don’t know to be honest. I assume that weights are
pretty common whenever you want to compare different behaviors in the way we
compare them, but they would make little sense for other kinds of systems.

***While map strategy syntax***
and construction appears fairly straight forward, the “why” is much more
elusive because of the multitude of variables – strategic areas, landing zones,
neighboring, choke points, water ways, squad behavior, etc – which must be
taken into account.

Please
provide a brief analysis of a formidable map strategy set - not necessarily a
technical description, but more an evaluation of the reasoning for the
conditions, prerequisites, modifiers, and strategies.

The first step is to create the strategic areas and their relations. Once this
is done, I consider the different plausible scenarios of the map. Almost all
maps will work well with a standard strategy that runs most of the time, one
strategy if the team is dominating the map, and one strategy if the team is
being dominated. This setup will make the map play decently in most
circumstances. If this turns out to be too stiff and repetitive, it may be a
good idea to add one or two more strategies for the normal situation on the
map. These strategies aims to create situations where one team may concentrate
on one flank, one spear head attack, or spread wide to try and capture badly
defended areas. Once I know what I want to achieve, I write the strategies and
add flags to the strategic areas so that I know that the strategies only will
activate when I want them. The same thing goes for the modifiers. If I want the
bots to attack a certain strategic area, I make sure that the flags for that
strategic area are unique so that I can add modifiers that guarantee that that
strategic area is the one with the highest temperature.