Game Development Reference
In-Depth Information
Chapter 24
At some point in your project, you begin to realize that you
re a lot closer to the end
than the beginning. While the calendar tells no lies about this, somehow your work-
load seems to increase exponentially. For every task that goes final, two or three seem
to take its place. For a time, you and the team can take the added work with gusto
'
—
but after this drags on for a few weeks or months, everyone becomes exhausted. It
'
s
about that time the boss walks in and tells everyone another work weekend is ahead.
Does this sound familiar?
This phenomenon is pretty common in many project-oriented businesses, but games
are especially susceptible because there
'
s something games are required to deliver that
doesn
'
t exist anywhere else. Games have to be fun.
I
ve said it a few times in this topic already, but it deserves another mention. You
can
'
t schedule fun, and you can
'
t predict fun. Fun is the direct result of a few things:
a great vision, lots of iteration, a mountain of effort, lots of playtesting and redesign,
and a flexible plan. I
'
ve also recently begun to believe there is a very healthy dose of
luck involved, too. Any one of these things in abundance can make up for something
lacking in the others. Most game companies simply rely on the effort component
—
a valiant but somewhat naive mistake.
If you
'
ve ever been in a sustained endurance sport like biking, you know that you
start any event with lots of excitement and energy. Toward the end of the ride,
you
'
ve probably suffered a few setbacks, like a flat tire or running out of water, mak-
ing it hard to keep your rhythm. Your tired body begins to act robotically, almost as
'
851
