| This tutorial emphasizes how the team uses the design document to
prevent team disintegration. We will explore more than
just the format of the
document. This installment and the following, expose the
inner workings of a successful development team and possibly bring you
to the conclusion that the elusive design document, is squirreled
away for a reason (okay - this is a blatant attempt to get others to
reveal themselves - we need them). A thorough and successful design document,
that has the detail to carry a team all the way to the end product, is
an invaluable template. If there is protectionism of these
bibles of development, then it is nothing but silly. There aren't
enough good games in all the genres, to keep up with the needs of the
gaming public. A public growing every year and an industry
growing into more sub genres. Only outlines and philosophies exist on the Net and
a growing list is posted at the
bottom of this page. What is not emphasized, are the team
problems, along with situation examples, explaining how the offered
structure addresses team dynamics.
A design document is a lot of hard work and always a learning
experience. It is the keeper of the flame - the flexible vision
for making a program from thought to completion. This is the
point many designers miss. It is relatively easy (compared to
the 2nd and 3rd step) to write down all the details of a new world, to
the point where possible publishers and development teams can get
"as close as possible", to seeing the same
vision. Where the development process breaks down is when the
"system" for developing the program, isn't adequately documented (step
2), or even implemented (step 3). What the end product will look,
and sound, and feel like, is easy to put on paper, but how it
is accomplished, is usually not detailed enough. If the
maintainer of the design document prioritizes where to spend the
most time, it should be step 2, the manual on the development
procedures. Step 3 is the push to stick to the "system" or
procedures laid out (hopefully created and altered as needed through
team input).
Inadequate design documentation is often blamed as the downfall of
a development team - it either didn't give enough guidance, or it was
used as an inflexible guide or the project moved away from the
original design and no one bothered to update the design document/keeper of the
flame. It didn't keep track of where the team has been and what
they should be doing on a weekly basis.
Where will the successful teams and their design documents take us?
Into a step-by-step "system" accounting for the full
psychological nature, and dynamics, of a talented, highly intelligent
team of innately solo performers. The "how" behind
developing
trust in the other team members, facilitators, and the development process
used - versus
becoming another soap opera story, of the disintegrating project.
Another way to look at the need for a design document requiring
hours upon hours of work... 400,000 small businesses die every
year in the land of capitalism because they didn't have a plan, a
system locked down for the team to rely upon. Another concept to
borrow from the business world, to balance out the design document as
both a keeper of the flame and a business plan: entrepreneurs
are advised by venture capitalist/investors to "go as far as you
possibly can" developing your product and the business plan with
out support. This is how long it takes to really brainstorm and
thoroughly discover and saturate yourself/team with the product and
the business strategy to market the product. This was also
reflected this very week in the Genesis3D
Forum, in another way. Your best chance of getting a
publishers attention is with a full design document, and a full game
demo. Both are the only way a publisher can tell, the
development team has what it takes to stick together and finish the
product. There is nothing else to judge by. The industry
has matured enough, to stop leaping at every exciting idea,
because of the pain that comes with the fallen team and loss of money.
A strategy borrowed by the publishers looks an awful lot like that of
the venture capitalists/investors: telling the presenter(s) pitching a
game design to "come back next month and will consider". Then the
presenter comes back and gets the same message. This can go on
for months. The message is this - they are waiting until they
are convinced you have a good idea - fully developed - and the talent to produce it. Altogether - they want to see the full
business plan in writing and conviction, along with proof you can make
the product. (Note: with more powerful development tools made
available to startup teams every year - future teams should consider
going without publishers, more, and more - but this does not negate the
teams need for a useful design document)
Also keep this underlying result of maintaining a top notch design
document in the back of the mind. At the end of the process you
have a book on how to run the next project that accounts for all the
experience gained in the last adventure: improvements on schedules,
archiving procedures, e-mail use, etc.
This tutorial is useful to stimulate brainstorming the reader, of
any level of experience, and at the same time accounts for
the start-up team of an independent project, and even virtual teams.
|
|
This list is both the goals of the design
document and the issues a team must discuss in the initial meetings
before starting up the formal development process.
You are going to read some of these and say "In a design
document?" - but all these issues, once agreed upon, must be
documented somewhere, and adhered to, or else. Best possible place
is within your design document. And in this authors HO it is
much better posted somehow on visually appealing web pages (anything
and everything for morale - plus you have the template already made,
for modification in future projects). Post on password accessed web pages or company intranet
if you have to. The following issues must be discussed in the initial meetings of the team, and
agreed upon. This is trust building. If the following
procedures seem silly, you are not alone - adequate formal team
training as a life long schooling subject, is nil. If you are a virtual team
(section coming on virtual
teams) then try to get as close a simulation, to all faces seeing and
talking, as possible. In a text chat room meeting if you have
too. You could use 3rd Voice while everyone looks at the
same web pages of the posted design document.
Vision
Start with the easiest and most motivating subject and discuss
the challenge of gaining the same vision of the end product.
Attempt to visualize the experience through
the eyes of the end user. Use the best examples setting
the vision from the design document as the guide for this. Set up a system
keeping everyone
"on the
vision" and how to get closer to having the same vision as the
development process goes on. For instance using the first levels
made, as a reference, and then tweaking those to get closer to the
vision.
Morale of Team and Trust Building
The overlooked part of the business plan/design doc.
Foresee problems. How do you do this? Ask the team what
they want to see and not see happening in every aspect of development
concerning the director, the other team mates, procedures, schedules,
etc. Such as QA (Quality Assurance): Some kind of agreed upon system to
get as many eyes to look at the levels of a game or virtual world, as
they are developed. The "system" the team comes up
with might be: develop the level first with generic textures, no
lighting or entities, then post the level for other team members to
look at. Discuss the goal, of learning to take critiques
within the team. Not an easy thing to do, but much easier if
everyone accepts this source of strife early.
Looking at others work, enhances your own, by giving needed breaks, and
learning each other's strengths and weaknesses. Hopefully the
team will agree to learn each others secrets. Then after
the initial look at a level, the next QA by the team might be when
initial textures are placed,
etc. If these systems are not set up, then you run into problems,
when you suddenly show up, wanting to see how the work is "looking so
far". It should not look like "checking up" on, and all should
know
the system, so no one starts thinking they are the only one, being
"watched". Running a development process requires predictable,
systematic schedules to make all members of the team feel like
milestones are being reached. Agreeing on issues before they
come up, allows a better environment for morale building and when the
unforeseeable does come up, the team is better prepared to tackle it as
a team, versus individuals.
Communication
Another overlooked area for morale. The team needs to
agree on a systematic means of communication. The dreaded weekly
meeting? Or as needed? Here is an ISSUE - most hate meetings or
will in a short period of time (this will be discussed later in this
tutorial). Guidelines and a designated time keeper are needed.
The team needs to discuss e-mail procedures, and
how updates are posted to the design document. For instance, it
is very important for all communication to reach all of the
team. If a technician comes up to the team facilitator and says,
"we need a better tool for making gray-scale maps" (height maps for bump
mapping or terrain)... Instead of the facilitator/manager/director
reacting off of their personality and either saying "what we have,
will have to work" or "I will take care of it" - that
request should be broadcast to every member of the team - so the team
can help decide if a better tool is worth the resources to make one, or
one of the team members may already know of a ready made tool that is
better. Whether verbal, or e-mail/ICQ all notable communication
must be made available, or sent to all. What messages need a
quick response, versus later, or none? Once the
answer/solution (occasionally if something becomes an issue that can't
find a consensus then someone has to step in and make a decision
versus wallowing, waiting, for it to go away) is agreed upon - then this
opportunity can't be overlooked for posting in the design
document. Changes in procedures and resources must be updated in
regular postings (maybe weekly or daily, acting like a
"latest" page of a web site) and within the design document.
Do you have a, plan formed by the team, for handling negative
communications? If a team member has a grievance, should they send
the communication by e-mail or by face-to-face?
The bottom line in communication: trust falls when team members perceive private communications or
feel left out of the loop or feel like they are working in a vacuum.
Trust falls when communication falls on deaf ears, "oh we already
tried that", "I don't think it would be worth the
effort", "that's an excellent idea but I think someone
else should implement it". The team must systematize
communication so all are guaranteed to be heard. Maybe each
regular meeting each member brings a special issue to the floor.
Implementation
Reassurance and high morale directly result from timelines that
are agreed upon. I want to know exactly what I am doing next
week, month, year, until the project is done. I want to know
when important goals have been reached, stages have been passed.
Examples of schedules, procedures, etc. will be found in the Nemo's
Mind design document along with exploration in later installments of
this tutorial. Another example of a possible
system: One individual has specialized in outdoor
landscaping. To coordinate with other managers or level makers, a
system is needed to see stages of progress and gain input for meshing
indoor and outdoor sections of the level. Perhaps the team comes
up with the following solutions/system. Once outdoor terrain is
produced then use generic textures (maybe even a checkerboard of many
colors, to easily see the lay of features, against each other) for
initial QA by the other team members, before spending a lot of time
painting the terrain. Then others can give invaluable input, to
make the most, of this newest art.
Recording
The team needs to know where they have been, as well as where
they are going. With the thousands of little details, a week
goes by and nothing stands out in the mind. But a month of
weekly postings by the local texture artist and that technician can
see accomplishment.
Once the project is finished, then a topnotch design document worthy
of hard copy packaging (and discs with the web pages) should be given
to every team member, to serve each individual as they go out and conquer the next
project. Template and experience, ready to go.
Marketing Plan
An example of something the team might not always be included
in. Doing so overlooks great brainstorming ideas and the
motivation of everyone feeling like they have a part in a big "trust
factor" issue - finances. Must be discussed.
Involvement motivates.
|
|
My practical communication and team work experience comes
through 17 years as an instructor of Survival and Rescue. This involves
countless situational management experiences, in every possible
human and indoor/outdoor environment. Supervising teams of
instructors and students, from Biscayne Bay Florida, to Korea, to the
Arctic Circle. But the most challenging aspect is always the human
element. During the "Quality" management craze of the
last 15 years I became a "Quality Guru" with certifications as
Facilitator, Leader, and Instructor of "Quality"
management. As a complete game addict, I have watched the young
interactive industry struggle, with team issues. It excites me to
see the industry has matured enough to have some great team experiences
but unfortunately not mature enough to start emulating the methods
behind those success stories. As the process gets more complicated,
and the
tools get easier to use - it will be very interesting to watch the art
of Design Documentation grow - and I dedicate my self, to having a part
in the documenting of that growth. Nemo's Mind has more work ,to become a premiere example of a design document. A game
attachment (alternate game program adaptation of the chat terrain) will
fill in the blanks, to make this tutorial integrate with the design
documentation of Nemo's Mind, to become a fully fleshed design document. To
comment or add to this tutorial you can use the e-mail link at the
bottom of the page or even better post it public style at this forum
|
