Game Development Reference
In-Depth Information
And the design is incoherent because so many people were working sepa-
rately on their own varying impressions of what the game should be. One
part resembles a deep story RPG. Another is like a heavily scripted action
shooter. A third is like a strategy game. The design ultimately becomes a
sort of badly sewed-up Frankenstein monster of a game, the pieces never
coming together into an elegant whole.
As the release date approaches, something has to give. The game
doesn't work as an integrated system. The remaining work does not match
the abilities of the team and cannot be measured. One subsystem is miss-
ing a huge amount of art; another has never been tested; a third is below
performance requirements. Finally, there is no way to advertise the game
because nobody knows what it's going to be.
In the end, the team crunches for six months, cuts large chunks of the
game, tries to shore up a core of what they have, and pushes something
out the door. It gets a ho-hum reception and everyone wonders what went
wrong.
These developers' fundamental mistake is that they underplanned.
Underplanning and Overplanning
Without planning, a process disintegrates as different parts of the team
and game work against each other. This is underplanning. But if we make
a careful, detailed plan, it falls apart on contact with reality. This is over-
planning. It seems like a catch-22. Either way we go, we get hurt.
Thankfully, there is a solution. But before we look at it, we must first
understand the problems with underplanning and overplanning in more
detail.
tHe Costs of unDeRPlanning
Underplanning creates several characteristic problems.
When we underplan, we almost always do work that has to be thrown
out. The work turns out to be unnecessary, or is made obsolete by later
progress. Plans avoid this problem. With a plan, we can determine the
minimum set of steps we need to get to a goal. If we find that a piece of
work isn't needed, we can remove it from the plan during the planning
phase. This is more efficient than doing it and then throwing it away.
Underplanning also harms team coordination. Planning is a necessary
part of coordinating a team. Even a team of two developers must talk about
what they're doing in the next hour. Scale this up to a team of hundreds,
and coordination becomes a massive challenge. A plan that describes what
