Intelligent Mistakes: How to Incorporate Stupidity Into Your AI Code

[Neversoft co-founder West presents a thought-provoking look at improving the believability of AI opponents in games by upping their use of "intelligent mistakes", in a piece originally written for Game Developer magazine.]

Twenty years ago, I was working on my first commercial game: Steve
Davis World Snooker, one of the first snooker/pool games to have an AI
opponent. The AI I created was very simple. The computer just picked
the highest value ball that could be potted, and then potted it.

Since
it knew the precise positions of all the balls, it was very easy for it
to pot the ball every time. This was fine for the highest level of
difficulty, but for easy mode I simply gave the AI a random angular
deviation to the shot.

Toward the end of the project, we got some feedback from the client
that the AI was "too good." I was puzzled by this and assumed the
person wanted the expert mode to be slightly less accurate. So I
changed that. But then I heard complaints about the decreased accuracy,
and again that the AI was still too good.

Eventually the clients paid a visit to our offices and tried to
demonstrate in person what they meant. It gradually came out that they
thought the problem was actually with the "easy" mode.

They liked that
the computer missed a lot of shots, but they thought that the
positional play was too good. The computer always seemed to be leaving
the white ball in a convenient position after its shot, either playing
for safety or lining up another ball. They wanted that changed.

The problem was, there was no positional play! The eventual position
of the white ball was actually completely random. The AI only
calculated where the cue ball should hit the object ball in order to
make that object ball go into a pocket.

It then blindly shot the cue
ball toward that point with a speed proportional to the distance needed
to travel, scaled by the angle, plus some fudge factor. Where the white
ball went afterward was never calculated, and it quite often ended up
in a pocket.

So why was it a problem? Why did they think the AI was "too good" when it was actually random?

Humans have a tendency to anthropomorphize AI opponents. We think
the computer is going through a thought process just like a human would
do in a similar situation.

When we see the ball end up in an
advantageous position, we think the computer must have intended that to
happen.

The effect is magnified here by the computer's ability to pot a ball
from any position, so for the computer, all positions are equally
advantageous.

Hence, it can pot ball after ball, without having to
worry about positional play. Because sinking a ball on every single
shot would be impossible for a human, the player assumes that the
computer is using positional play.

Design or Code?

Is this a design problem or a code problem? To a certain extent it
depends on the type of game, and to what extent the AI-controlled
opponents are intended to directly represent a human in the same
situation as the player.

In a head-to-head game such as pool, chess, or poker, the AI
decisions are very much determined at a pure code level. In a
one-versus-many game, such as an FPS, there is some expectation that
your opponents are generally weaker than you are.

After all, you are
generally placed in a situation of being one person against countless
hordes of bad guys. Other game genres, particularly racing games, pit
you against a field of equal opponents. Here the expectation of
realistic AI is somewhere between that of chess and the FPS examples.

The more the computer AI has to mimic the idiosyncrasies of a human
player, the more the task falls to the programmer. The vast majority of
the AI work in a chess game is handled by programmers. Game designers
would focus more on the presentation.

In an FPS, the underlying code is
generally vastly simpler than chess AI. There is path finding, some
state transitions, some goals, and some basic behaviors.

The majority
of the behavioral content is supplied via the game designers, generally
with some form of scripting. The designers will also be responsible for
coding in actions, goals, and responses that emulate the idiosyncrasies
of human behavior.