then there is little chance that the opponents the players face will appear very smart at
all.
This creates special problems in terms of how to best produce a game. Level
design is often one of the last tasks to be carried out on a game, before it goes into final
balancing, then testing, and finally ships. Similarly, AI is usually only worked on after
the core engine is firmly in place, most of the mechanics for the player’s movement are
fully functional, and many of the other more critical programming tasks are mostly com-
plete. Now, if the same person who is designing the levels is also creating the enemy AI,
it might be simple to integrate the development of the two, but this is rare if not
unheard of in modern game development. As a result you have two teams — the pro-
grammers and the level designers — working in parallel. Unfortunately, the usual case
is that each charges forward with their work without fully considering the other. The
level designers do not have the AI yet, so they cannot tailor their levels to support it. It
is just the opposite on the other side of the equation: the programmer does not have the
levels yet, so it is hard for him to make an AI that will function well in those levels. The
situation is a catch-22. Once the levels are done in terms of architecture, the AI is
finally added to them, and then it turns out that one or the other needs to be radically
reworked if the game is going to be any fun. In the worst-case scenario there is no time
to rework either the levels or the behaviors, and the gameplay ends up suffering as a
result.
Of course, the level designers will protest that the AI should be designed to fit the
levels they create. And, similarly, the AI programmers will complain that the levels
simply must be reconceived to work with the AI they developed. Since I have worked
as both a level designer and an AI programmer, I may be in a special position to arbitrate
this dispute. In my opinion, neither party is entirely right, and a little give-and-take is
required on each side. I would advocate trying to make a simple, playable AI first. It
does not need to be bug free or work perfectly in every situation. If it works fairly well
in some situations, level designers can start making levels that facilitate what the AI is
known to do well. As the level designers take this direction, the AI programmer can
keep working on his AI, getting rid of any bugs while always keeping an eye on what
shape the game-world is taking. The AI programmer must communicate to the level
designer when he sees a problem emerging in a level, such as a situation the AI is
unlikely to handle well. At the same time, the design of the levels may give the AI pro-
grammer new ideas about what tricks the AI can pull off. Maybe ledges start showing
up in the game-world that would be ideal locations for snipers. Or perhaps the structure
of the game-world’s architecture is suited to coordinated team movements. If the AI
programmer can then add functionality to his algorithms to allow the agents to identify
these locations and behave accordingly, the AI will become stronger as a result. Both
sides of the designer/programmer equation must be ready to compromise. Often a
designer may have to compromise for the good of the project, modifying something he
may like as is but which horribly confuses the AI. Similarly, the programmer may need
to add some ugly special-case code to accommodate a problem that occurs in a majority
of the maps that have been created. The designer and AI programmer must trust each
other such that when one of them tells the other something needs to change, they
believe the other and make it happen.
Chapter 9: Artificial Intelligence 165