[Back
To] A Primer for the Design Process,
Part 1: What to Do
2.
Good Habits, A Critical Eye, and the Fun Factor
Merging Design Documents, Schedules, and Budgets.
Time will need to be taken during, or immediately after, the pre-production
design phase to come-up with real numbers, times, and dates for the
project. The usual problem with those above-mentioned words is that,
for each concept mentioned, you have a different group of people crunching
the numbers. They also don't tend to be in very close contact with each
other. Many companies are fond of saying, "Hey, we need to fill
a gap in the quarter here! You guys, do this game in 8 months!"
Your response is, "Not on your life, but if we must, we'll need
more money and resource to do it." Of course, they don't want to
give you more money and resources to do it. That's why it helps to gather
all relevant parties to this portion of the development process, bring
them together, and hash out the numbers. That's why it helps to have
your design broken down into needs, tasks, and features at the start.
There is no better time to examine resource and budget considerations
then while you're hammering out design detail, unless of course you
have nothing to do with making the schedule or planning the budget.
If you're leading the design vision of the product, however, you should
very well have a hand in the schedule and budgetary considerations.
Get all the relevant people into the room at one time and hammer out
the numbers. It's a big pain in the backside, but it's definitely worth
doing in the long run. Remember, when the design doc is changed, or
features are re-worked, you're going to have to take a look at the impact
and figure out if this is going to push you back in the development
process.
Updating
the design document.
This sounds easy, but in the throes of development long hours and crushing
stress from all sides can cause details to slip through the cracks.
You might talk about a feature in a late-night impromptu gathering and
then implement the change the next morning. You should document that
change, especially if you end up doing a sequel a year or so later,
so that you remember what you did in the first place.
When anybody on the team decides to round out a feature, change a feature,
or add a feature this change should be noted, documented, and brought
to everyone's attention. If you've created an on-line style design document
not entirely unlike the one mentioned part one of this article, you'll
have the mechanism in place to keep the team informed and responsible.
Keeping
a Design Journal
This is as straightforward as it sounds; keep a running dialogue of
what's gone right and wrong during the project. Week to week will probably
do unless you're in the middle of one heck of a crunch time. This will
serve a number of purposes. First, it lets you recall, months and months
after the fact, lessons you may have learned or not learned early in
the project before the press of 15 hour days began to blur one day into
the next. Secondly, it allows you to bring up key issues of good or
bad work done by people throughout the project during the post-mortem
(your company has post-mortems, right?) And lastly, it will help you
in publishing a post-mortem article for a relevant publication so your
fellow designers out there can learn from your experience, right?
Critical
Evaluation
One of the best things you can do for your game when you're looking
to implement features is to critically evaluate the competition and
I mean look at them. There is a saying, "It's amazing how much
you can see if you just look." Don't knock on the competition simply
because their title is out before yours hits the shelves, evaluate it.
Every title, no matter how heinous, has some lesson to be learned tucked
within its folds. The primary lesson here is to avoid making the same
mistakes that killed a rival product.
This goes for the whole game, look at things like their front end to
see how easy it is to get into the game, check the controller set-ups,
examine screen real estate and test in-game timing issues and controller
sampling. You don't want to be reinventing the wheel if you don't have
to. If some other game is doing something well, borrow that idea or
concept. You just have to make sure that you don't outright steal the
concept. That would be a no-no. Remember: Good design not only about
ideas, but it's also about the implementation of those ideas.
Of course, at some point you are going to need to turn that cruel, cold
eye of unswerving criticism on your own title. Testing feedback will
help here but ultimately someone's toes are going to get stepped on.
When looking at your own product, put your ego in your back pocket.
Many a title has crashed-and-burned because someone's ego fought against
the tide of popular opinion and washed-out (or in) a feature (or features)
that killed game play.
The
'Fun Factor'
Some companies want you to work on the "fun factor." Everyone's
looking for that elusive concept that you read so much about in fluffy
design treatments and marketing blurbs. The causal gamer and average
consumer can't nail down what is really fun. They'll tell you something's
fun, but they can't tell you what's happening inside the game and what
they're responding to. Fun tends to be a relative concept that revolves
around things like pacing, timing, and excitement as specific to that
particular title. These are things you can theorize about; tell people
"punching this guy is fun!" but you'll never really know until
you spend time with the game and work it out. As a designer, you need
the ability to critically evaluate the competitions efforts. Look at
how they handle certain issues and make note of them.
The fun factor comes from being able to identify exactly what's being
done, how it's being done, and you can continue to do it without the
game getting boring. This is a touchy part of the implementation of
the design. Lots of people are going to have arguments one-way or the
other about the details. One thing that will help you with this is filtering
proper information and feedback from your QA department, but I'll go
into that later.
________________________________________________________
The
list of "NEVER"
|
|
|
|
Features
