Game Development Reference
In-Depth Information
Cutting Features and Postponing Bugs
Perhaps the most effective method of pulling a project out of the fire is reducing the
scope of work. You can do it in two ways: nuke some features of the game or choose
to leave some bugs in their natural habitat, perhaps to be fixed on the sequel. Unless
you
'
'
t know
about everything you wanted to install in the game. You might be able to shorten
or remove a level from your game, reduce the number of characters or equipment,
or live with a less accurate physics system.
Clearly, if you are going to cut something big, you have to do it as early in the project
as you can. Game features tend to work themselves into every corner of the project,
and removing them wholesale can be tricky at best, impossible at worst. Also, you
can
ve been a bit arrogant in your project, the players and the media won
t have already represented to the outside world that your game has 10,000
hours of gameplay when you
'
re only going to have time for a fraction of that. It
makes your team look young and a little stupid.
'
So, 70 Hours of Gameplay? Really?
Always give yourself some elbow room when making promises to anyone, but
especially the game industry media. They love catching project teams in
arrogant promises. It
s great to tell them things about your game, but try to
give them specifics in those features you are 100 percent sure are going be
finished.
'
After code complete, the programmers are fixing bugs like crazy. One way to reduce
the workload is to spirit away some of the less important bugs. As the ship date
approaches, management
bugs in this manner becomes somewhat
ravenous, even to the point of leaving truly embarrassing bugs in the game, such as
misspelled names in the credits or nasty crashes.
Anything can be bad in great quantities, and reducing your game
'
s scope or quality is
no exception. One thing is certainly true
'
s desire to
“
fix
”
—
your players won
'
t miss what they never
knew about in the first place.
This One Must Die so That Others May Live
MushroomMen: The SporeWars on the Wii was in late development, and one of
the levels was falling behind. Art was unfinished, scripted events were still undone,
and many other things left the team with the distinct impression that getting the
level done was going to take a lot of work. After some serious soul searching,
the team decided to cut the entire level and spend time making the other levels
in the game better. It was a very hard decision, because so much work and care
had already been spent on it
and had it been completed, it would have been one
of the cooler parts of the game. In the end, it was the right decision.
—
