What's
good in the
music/game world right now?
Some genre's lend themselves to certain kinds of music, often from professional
named bands or individuals. Take a listen to what's good, what seems
to be happening, then incorporate its style into your title. Some marketing
folks will fork over a chunk of your development budget to sign bands
or individuals to do the music for your title, but it's been my understanding
that very seldom, if ever, will a person's decision to purchase a title
be based on the fact that someone they may have heard on the radio once
did the music for the game. In certain cases having a named talent do
the music might add to the "cool" factor and help generate
a little buzz on websites or the odd magazine, but it's not going to
sway the consumer and it can also be a huge licensing hassle with no
real guarantee that what gets written for the game will be delivered
on time or be any good. If there's any question, a good solution is
to try to get a synchronization license (Where you get the right to
cover the song, but not to use the original recording by the original
artist) for a piece of music you'd really like in your game.
 |
|
Screen
shot from Toon Struck
|
Some companies
have been known to waste a ton of cash trying to get a particular vocal
talent or talents to act in their game as, unfortunately, a major marketing
aspect of the title. Did it matter that Rob Schnider was the main vocal
talent in A Fork in the Tail, or Christopher Lloyd was in Toon
Struck? As above, more often than not most gamers won't buy a title
simply because there's some celebrity voice actor that they button past
in the first 2 seconds of hearing it in order to get back to the game
play.
Get something (or someone) good that fits the attitude of the game,
and it will increase the gaming experience for the player. That's all
you need to be worried about.
What's
been done and how was it done?
I talk about this later on in the "Think" section about Critical
Evaluation, but this is a very important issue when you first start
your design. There's absolutely no need for you to tell a story that's
already been told, or develop a game that's already been done, or rehash
a genre that's on the way out. Do your research and learn from that
research. You should be playing games, plain and simple. You need to
know what's out there, what's already been done, and how high the bar
has been set so that you can clear it.
2.
The Working Design Document
Once you've focused your ideas, its time to think about the design doc.
The design doc acts as a script; it should be giving every other professional
involved with the product a more than firm idea of what they need to
know to implement their portion of the product.
Like other parts of the entertainment business, there are some basic
rules and formats for how ideas are presented, as well as a few things
that people no longer want to see. Publishing has its "double spaced
12-point Courier font" from the old Smith/Corona days, and film
and TV have standard script formats for either television or the silver
screen. These formats are not only expected, but also demanded.
Our business is a little different. It's not quite old enough for standards
and guidelines to exist, but we're moving into the "broad spectrum
formalization" for industry standards and practices. Simply stated,
tradition has bred expectation. Certain questions should be answered
before the thing is sent to production. This is your job, O Maintainer
of the Creative Vision. You need to answer these questions and more,
as everyone on the project will be coming to you or your people for
information and the lo-down on what needs to happen and, more importantly,
how it's supposed to happen.
Design documents tend to fall into one of two formats: they either loosely
describe a game concept so upper-management can sign off on the idea,
then get dropped into someone's filing cabinet never to be read again
OR they are the size of your local Yellow Pages, filled with every imaginable
detail that no-one but the person who wrote it cares about or is willing
to read.
In an effort to maintain the working lines of communication between
the design staff and the production team, we came up with the idea of
a "feature-oriented" document that could keep everyone on
the team up to date and informed whenever a design change was made or
redesigned.
If you look a production movie script, you'll see that there are different
colored pages at any given point throughout the entire script. These
pages represent changes that have been made to the script since the
start of filming. The colors allow the cast and crew to follow the changes
and thus maintain continuity and keep everybody -pardon the unintentional
pun-on the same page when updates occur.
Like a script, things in a design document will change due to circumstance,
talent, or innovative problem solving on the part of management or the
production team. These changes should not only be noted, but also sent
out to the people whom they affect.
The
Feature-Oriented Design Document
Our feature-oriented design document began as a basic form that could
help keep the 6 people involved with the design document up to date.
It was designed not only as a fluid guide for everyone on the team,
but also as a living document that could carry us through the ongoing
design of 3 different games.
We put the design document on our LAN, with the design team continually
adding to or updating the document at the same time. Version control
is a simple matter of the software (in this case MS Word) not allowing
more than one person to work on an individual sub-document at any given
time.
The document itself incorporates a couple of features that help with
keeping things organized, including major headings calling out important
items like what the engine needs to do to, AI requirements, game modes,
motion requirements, and on and on. Under these heading are the particular
sub-documents explaining the features or functions that individuals
on the team have been tasked with designing. Whenever a new design feature
is nailed down we can send out updates to the relevant team member through
E-mail with a hyperlink attached to the virtual document for easy access
by team members. We can do this because the document is being written
with the whole team in mind.
The sub-documents themselves take the form of a numerated template with
the heading numbers tied to the table of contents. This allows us to
sort these documents by feature or project when we work on layers of
design for separate products. The template helps push for a more detailed
design for each feature and also helps the designer answer questions
up front, allowing for a more thorough design when the project hits
production.
This template also allows us to design for more than one version of
the game. Some design features have been layered to appear over a series
of releases and as such, you're always on the same page with whatever
feature you're thinking to forward.
The master plan for the design document is to have it linked with both
a Technical Design Document that's arranged in the same manner and some
sort of scheduling software like MS Project. This has the added function
of allowing us to asses any impact to milestones or budget new design
features may have.
________________________________________________________
The
Template
|
|
|
|
Features
