Example Documents

#1 I don't have any particular advice/example documentation for you, but I think this forum discussion may be interesting:

A Better Game Design Document

#2 @Stephen

I'm hoping it will generate a good discussion. Since I've had to do things formally for my entire career, I have a hard time "flying by the seat of my pants" when designing or coding a system. I have found some people who can create great systems without having a document as a base for development. I'm hoping to see if there are differences in documents between business systems and gaming systems. I am hoping to get a better understanding of the process that people/companies go through to create games. Maybe even get some "lessons learned" that will help other projects avoid potential mishaps during their development.

Thanks

Eric C. Tomlinson

#3 @Stephen

Just noticed the link. I signed up there because it has some great ideas. Thanks again.

Eric C. Tomlinson

#4 Personally, our development methodology makes our design documents "grow", in that they start extremely basic, pretty much just a vision statement, and we iterate through "tiers" of design, development, re-design, re-development/code refactoring, with feedback and oversight into the design documents in each cycle.

This allows our documents to be very dynamic, as well as our design and implementations. For QA purposes, you need to have measurable and "automatable" requirements, but in many cases we've found that creating a massive set of design docs with no flexibility severely limits our development--not only from the time it takes to fully define your documents, but also the learning process developers go through when working with (for us at least at this stage) a complex and unfamiliar SDK (TGE).

There are a lot of problems with this approach obviously--even with the feedback and oversight, documents don't grow as quickly as they should--devs get on a rush and code things that aren't even mentioned in the design doc, and that can cause serious feature creep as well as deviation from the original vision. It does however work pretty well for us so far, and we get a lot of synergism as devs learn techniques and tricks.

Personally, our goal is to make sure that our design documentation stays "live", and also provides measureable criteria for both progress and testing. I would think that as long as you focus on that type of concept, the format of the documentation isn't critical.

My $2.00...

#5 I agree that most system documents have to grow and change, but getting people to look at and absorb is a different story.

Have you had problems with people "missing" updates and the like?

P.S. Thanks for taking the time to respond, it is much appreciated.

#6

Quote: agree that most system documents have to grow and change, but getting people to look at and absorb is a different story.

Have you had problems with people "missing" updates and the like?

Yes and no, hehe. We actually have three tiers of communication (we're a totally virtual, and very displaced group):

1) Forum boards. Most of our brainstorming/vision development happens on our forums. We've tried to keep things as organized as possible, but in any free-flowing discussion, ideas generate other ideas, and sometimes discussions go wildly off track. Still, it's our best method for idea generation. Largely, the team doesn't miss major discussions/ideas, but they do tend to get lost in some cases when not "concentrated" into a vision/design doc.

2) Document Repository. We've just recently added a module to our subversion repository (same as we use for our code) for vision/design documentation. Currently, only our senior designers/devs have direct access to the docs, and to be honest our ideas from our forums tend to go through dev's minds, into code, THEN into design docs, which probably isn't the best process. We also have a bit of difficulty making sure that the documents stay updated, but overall we haven't lost major track of designs (yet).

3) Direct email. In some cases, especially when a few team members are working cooperatively on a task, they communicate directly via email. This tends to work fine for question/answer, but I think that we may be losing some content through untracked emails. Still, it's a great way to work on short term tasks, and I'd hate to swamp every team member with every email, especially with a very large project.

We also use a very basic project management tool that lets us define and assign basic tasks and projects. It works great for me (as Exec Producer), but tends to be ignored by most of the rest of the team. I think a more comprehensive PM tool combined with stronger interaction from the team members would work much better.

All in all, our system works mostly well. When a design doc gets updated, I have folks review for comment/correction, and when a major topic evolves on our message boards, a large majority of the team participates well. One thing I have implemented for the team is a monthly "doc review day", where members are supposed to do nothing but re-read ALL (15 atm) of our vision/design docs, and sanity check current progres and tasks to make sure we're heading in the right direction. This has helped some to keep people focused on project vision and goals.

#7 Hey Eric, I read a Gamasutra article recently which shed a litte light on things for me. It is right about *finds link* here. Whilst it doesn't cover any real specifics, it gave me a really good impression of what my design document should contain.

Ian