Welcome to the Nemo's Mind Design Document!
The Virtual World's
what?   why?  who?
Is Evolving
They are helping us develop the Virtual World too...

Need the web secrets to easier reading?


  Design Documents & Team Dynamics

"Donít be buffaloed by experts and elites. Experts often possess more data than judgment. Elites can become so inbred that they produce hemophiliacs who bleed to death as soon as they are nicked by the real world." Unknown Ė



  Tutorial Intro
  Things that make you go "hmm"

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.


  The Innate Goals of the Design Document

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.

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.

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.

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.

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.


  The System

This online tutorial is the beginning of a repository for the interactive industry's ideas on how to coordinate team efforts and implement systems and schedules that are motivating and productive.

Examples of systematic processes that will be explored in the Nemo's Mind design document, and in this growing tutorial of ideas, from the experiences of teams through out the industry:

  • weekly status report page
  • communication system for a virtual team
  • how to use a web site as an FTP (file transfer protocol) for holding maps, textures etc. only the team can access
  • how to use web pages as team only communication
  • areas of responsibility within the team


  Working in reverse
  or how to let some problems solve themselves


will post this section over the month of November -  on how to make a development process run it self and become a living team member in its own right - how to develop a "system" and the mental mindset of the facilitator to let it happen


  Authors Team Experience and Goals


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


  Links to Design Document References


http://www.godgames.com/oracle.html - look for this in their FAQs if this
link doesn't get you there - see question # 34 - sadly this is the most often referenced "design document" on the web - its a great outline but no examples given - come on game industry - lets see a real design doc for the gamers




http://www.gamedev.net/reference/docs/refarticlelistuser.asp?catid=23    - lots of specific stuff here - a whole directory to articles on design documents, game design, and story development



Why give us a vote of confidence?

next page

back to the top             contact us

© 1999-2001 by H. Kevin Long - Nemo's Mind TM   all rights reserved
Welcome to the Nemo's Mind Design Document!