How long are your design documents?

#1 Mine's two pages.

Of course, I'm a fan of the "incremental design" approach.

Ive worked on games with hunderes of pages of design doc, and generally, theyre completely a waste of time.

Your mileage may vary tho :)

Phil.

#2 Okay, I'm willing to bow to someone with more claimed experience, but how could you possible form a development strategy with two pages of design?

First, bear in mind that most projects here are virtual, and that most members of those teams have never sat down in a room together.

Second, with only two pages of design, it would seem to me that you are creating more work for yourself down the road, whether be in game balancing issues or simply the descriptions of a single player model and its capabilities. Measuring once and cutting twice, if you get my drift.

I can completely see where a document hundreds of pages of nonsense, and I've seen a couple so far, would fall flat. There is the team behind the document to consider as well.

#3 Scott, isn't your game just a standard FPS? Hehe, you're going overkill there big guy with 100+ pages and small font.

If you're wondering if yours is long enough, well it is... if your post was in fact a pissing contest (which I do feel it was. 100+ pages should be pretty obvious it's "enough") then well... U Sux! lol.

Ours is 54 pages, but to really make it "filled out" it will pry be around 75-80pages.

One nice thing about including much of the team in the design is that a crystal clear design document is not required. As long as it's understandable by the knowledgable team members then it'll work. Our team isn't big, and the people who need to know about the design details are the people who shaped it.

#4 My doc is pushing 100 pages, and it's probably 75% complete. Just need to fill in here and there with details.

This is for an RPG btw.

#5 Thou doth offend...with the comment of "standard" fps. I demand satisfaction! Mousepads at dawn, beotch :)

I'm honestly trying to get information about this process, as this is my first go...albiet an ambitious one. Point taken about the clarity of a design cutting it's design doc pages down. Thing is, I don't have the technical skills needed here, that's why I went out and got the guys from Tres Animations and Exile Graphics...guys like Fred Rosenbaum and Stefan Grufman to help with the programming and such. I'm the writer...so I write.

Now for an example...our inventory system is based on weight, not arbitrary slots like T2 or Rogue Spear. So, the coders need a whole bunch of info about item weight. Further, our clips become lighter as you shoot your ammunition (logicially), so individual round data was needed. In fact, the doc contains what I tried to predict the scripters were going to need to describe the behavior of each model or item in the game. Thus the length. Plus, this contains game modes, scoring, server options, GUI...everything I could possibly think of that goes into making the design as conceptualized.

I honestly thought I was still on the short side of document length.

Scott

#6 We've taken an iterative design/implementation approach to Myrmidon, as Phil mentioned. We don't have just two pages, but we started with a relatively small doc and list of requirements. One reason (probably the biggest) we chose to work in this manner was to make sure we could always play the game and see if where we were heading was on target. Is the game fun? What elements need tweaking? What elements should we add/remove to make the experience more enjoyable? Trying to design every facet up-front seemed a little too restrictive.

Dave Myers
21-6 Productions

#7 for my 02, from what i read on the web, your specs are approaching what the pros use. its not about how heavy the doc is. if you have a complex, detailed project ahead of you, you need a similar design doc, vice versa for simple projects.

#8 It's not the size of the ______ it's how you use it. Fill in the blank with whatever appropriate...it always works.

#9 Good point. I can hang a towel on my design document when I'm excited. I can also steer a yacht with it.

#10 And I think you could probably crush a small child with it :p

Progressive design is good... but I think Phil is taking it to the extremes hehe. I believe Phil's game is a fairly simple design, so I guess it's do-able from 2 pages built upon.

A RPG though... hehe, you're going to need a lot more to get started.

#11 My design docs have run as high as 50-60 pages. Usually they're 20-30 pages in length.

The important thing to me is to provide an overview of the game, and then provide detailed descriptions of the different elements.

When I'm satisfied with the design doc, I then create a separate "task list" document. The task list tries to break each game element into the necessary steps to create that element.

Finally, I use the task list to create a series of "development phases". The tasks are compiled in the development phases such that each phase results in a playable, if incomplete, game. Also, each phase builds on the phase before it. This provides a certain amount of incremental progress while still keeping in mind the larger goal.

By the time it's all done, it can run from 50-100 pages, depending on the project.

On the other hand, though, we've also done projects where we began with a couple pages of notes and a loose framework of proposed development phases.

In my experience, the better planned a project is at the beginning, the shorter the overall time to release.

-David
Samu Games
The Journal

#12 I think the last approach would be definitely do-able if I was in the same building with the same people day after day. I was more speaking to the situation most of the GG teams face...that of physical seperation.

#13 At Dynamix we implemented an approach brought to us from Pat Cook, of FPS Football fame, who is now a PUM at Microsoft. We used a staged design approach.

Stage 1: 2-4 pages. This is a sales document that is used to get a green light to move to the next stage. Describes the high concept (elevator pitch) of the game. Usually accompanied by a mock up screen shot or sometimes even by a code demo. This document, along with a lot of expreience would determine a "grab your ass with both hands" budget guestimate and target ship date, i.e. 4Q 2004 (note- it's always 4Q, then work back from there, even though it never works out: People in the industry are laughing right now--- inside joke.)

Stage 2: 10-20 pages. Describes all sections of the game in much more detail. Discusses how the UI will be approached, the level of AI expected, etc. Still mostly a sales document, the S2 is accompanied by even more mock screen shots, and usually some form of demo. At this point an even more detailed budget and schedule is made. This document could be thought of as a movie script (which run approximately one page per minute or 120 pages for an average movie). Ti gets the point across, but does not tell how to do it.

Stage 3: As long as it needs to be. Nobody but the team uses this document. Some games need large documents, some small. Many games will get just in time design documents to fill out tables, weapons data etc. This document is also accompanied by a technical design review (TDR, in EA parlance) which describes how the project will be done, i.e. the tools, technologies, and techniques.

Some people feel the Dynamix approach was too lax, but I hold up the ship schedules during my tenure there to anybody's. A game, such as Tribes 1, that was heavy on the R side of the R&D equation, never had these formal processes. Other games, such as Pinball or Trophy Bass, were easier to schedule, so they had tighter specs and design documents.

Bottom line is this, "nobody knows nothing". There is no standard answer. The person that tells you they have the answer may believe it, but I call bullshit. I have seen teams that implemented design documents approaching one thousand pages. The poor designer spent all of his time updating an unmanagable document that was so large the team never read it more than once. You know what happened to these projects? They didn't ship.

The one thing that I notice here is the people that have done it before are much more lax in their design doc requirements. That's OK. When you are starting out, it is better to over design. That's also why we are indies. We want to do it "our way."

Jeff Tunnell GG

#14 Jeff hit the nail on the head, from ALL of the "design in minute detail" design docs Ive seen, Ive NEVER seen a shipped product.

I am taking it to the extremes with my 2 pages, but essentially, I'm in Jeffs stage 1.

i think the staged process is essential, so you dont get bogged down in minute detail far too early on.

My personal approach is this:

Stage 1: 2 page overview - more like a sales pitch. Tight and punchy. Who, what where only.

Stage 2: Core area's, AI, Music, Graphics etc. Work in enough detail to do stage 3.

Stage 3: Requirements analysis. From a programmer point of view, its much better to have something like
"Characters move at 1.3 meters per second" than something like "This character moves lightning fast" its this requirements phase were you nail down the solid details. This can be a just in time thing as Jeff mentioned, get the designers to do it just ahead of the programmers needs.

I think the thing that trips most people up is that they go off on a trip about thier "story" and "backend" and end up trying to write a novel, when in fact, the DD should be more a technical summary of the mechanics of play. Story means nothing in a DD other than the mechanics of how your going to present it (cutscene requirements etc).

In effect, I think it'd be better to seperate the story and backend stuff into another doc entirely (call it a manual) and simply get someone to create a requirements section on it for the DD.

On my 2 page approach. Iterative development is something I believe in, besides, 2 pages is just for show, I am not using a huge team or anything. Its just me and the artists and right now, until we get the art in place to make a start, whats the point in making anything more? I can provide mode gameplay in a prototype.

Prototyping's another issue tho :))

Phil

#15 Good call, Phil. I didn't even mention the story/character bible for those games that required it. For instance, on the two Starsiege Universe products (Tribes and Starsiege), these documents and the accompanying back stories that we released to the web were huge.

Art bibles are another story. First, we worked on the conceptual design to nail the look. From there we created conceptuals of every shape/item in the game. In many games, we used huge boards to display the conceptual art, the models, and the finished product, so it was easy to discuss the project in the team areas. Way too much process to describe in this small space.

Audio had a similar document.

The QA process had a plan as well. There was a lot of debate about weaving a QA guy into the project from the beginning to "build quality in". Well, qaulity should always be built in, and I don't need a full time guy eating up budget telling me so. Obviously, I fall on the side that the QA guys are brought in around Alpha or First/Second Playable milestone if you want extensive play testing done for a game that is experimental. The only thing I ever saw happen with having a QA guy on the project from the start is that the budget inflated. I know I'm going to take a lot of crap from QA guys for saying this, but that's just the way it is.

Jeff Tunnell GG

#16 I have three documents.

1) The Concept Document - this is the sales pitch with conceptual art sketches.

2) The Functional Specification - this is what the game is supposed to do in great detail (specific units, levels, terrain, finalized concept art, etc.) with Use Case diagrams.

3) The Technical Specification - this contains the real meat of the design. It is like a blueprint for a house. This includes Sequence diagrams, State diagrams, Class diagrams, etc.

#17 Me make good game fast cheap fun gun guy dead blood jump bombs by tomorrow...

This just happens to be my design document...

See you in the big time guys!!!

Scott

#18 I think it really varies, depending on the type of game you're going for, as well as your personal knowledge.
I think at last update our design doc was around 30 pages, but probably not that much. However, I haven't updated it in awhile...why?
First of all, I'm just an indy designer. I don't know enough about programming or about the tiny details of the Torque engine to be able to say "and we will have melee weapons work like this"...allthough I tried. ;) A lot of sections in our design doc are very strange, because they're basically my best guess on how things work. In the end, it's more work for me to do that then hear my lead programmer tell me it's actually done this way than to simply tell him what I want.
Second, I'm taking on specific things in different documents. For example, I wrote a single doc on the types of characters and their basic specs. Another one for vehicles. Another doc for the levels.
Essentially, I'm making a new design doc in pieces. While you may need to open multiple documents to find info on both the tank and the level it's on, in many ways (I think) it's better than having to click hyperlinks in a GIANT design doc and be dropped into the middle of the document, afriad to scroll too far into the next section.

Of course, this really all has to do with different variables. The type of game determines things...if you're doing a game with standard FPS gameplay, you don't need to describe it in a big document. However, if you're making an RPG you definetly need to explain the combat system.
If you work differently than others it matters as well. I like to constantly be up to date with all team members (thank god for hotline). I check in on how each one is doing, make suggestions, and give assignments. If I have a big problem to face, I arrange a meeting and we discuss it. If I need to know if something's possible, I talk to my lead programmer and he tells me.
Others work differently. Some people like a pyramidial system, in which they have one or two advisors who let them know how others are doing on their work. Some people like to stick all their people in a room and let them duke it out over decisions, then decide who's arguement he likes best. Some people like to have a strict plan set up and strict rules that people adhere to.
If I like to micromanage and you like a pyramid of command, we obviously won't have the same design doc. I'll find out what's possible when I need to, explain stuff in my free time to people, and get it all worked out so I don't HAVE to write it down...while you may write a detailed document, then have a group of people approve it.

Um...ok, that's enough from me. Pardon me if this post is not my most coherent ever...I was up all of last night at an election night party (yes, we already have elections going on in Cali), so I'm a bit tired.

-Evan

#19 RE: Jeff & QA.

Top line: I agree with Jeff for the most part.

I've worked QA on both small and really large projects. Currently I'm Principle Engineer on a $25MM project with 50 people: I'm responsible for the technical delivery of the system.

In all aspects, you don't need QA people on a project all the way through, unless the actual workload demands it. In some industries, Gov't Regs and Reg/Standards Body requirements have a hefty document sink, and you may want to have your QA guys hammering at that pretty well from start to end.

But the simple truisms do exist: you design in quality, you can't test quality into a project. This in no way means that you need a QA/QC babysitter sucking up budget. Best approach I've seen is to use a QA contractor/consultant to come in at certain major milestones, and to pop in and out at regular intervals to poke people here and there. With proper guidance from a well-rounded and tuned-in QA guru, and solid *project management*, you can easily do what needs to be done with only around 1% or less effort commitment from a QA specialist. For a 2,000 effort-day project this means roughly 20 effort-days; that's roughly 5 meetings plus 5 1/2-days of one-on-ones, and 10 days spent reviewing documentation, code, and reports at various intervals. You don't need QA on staff for the sake of having QA on staff.

Even during Alpha, Beta & Acceptance testing, formal QA should be an advisory role, not some guy(s) banging away at your product trying to make pieces fall off.

In my world, QA audits occur. Teams swoop into the labs, and literally turn everything upside down and shake it for two or three weeks, then disappear into the sunset, leaving behind nothing but ulcers. Two months later a report filters in from on high, and usually they consist of 300 pages of nitpicking - "None of the programmers on Team A and most members of Team G are unaware that a revised ICD (Interface Control Document) #N-010-430002-A dated 01/01/01 was issued with all signatures. Consequently the common header pool was not updated to signify the change in the use of the type DWORD to 'long' for axial position reporting until it was uncovered in unit testing (see SDR #12345 and SPR #98765)". While this sort of thing certainly doesn't diminish quality, it escapes me how it actually assures it, or improves it.

In the game industry I think the best approach is to have a protocol that everyone follows. A programmer's guidelines doc that people can refer to for stuff like naming conventions, which unit test should be done how often, what sort of test coverage should be enabled at which stage in the project, what a defect or non-conformance report should contain, and so on. Every so often, at a rate that makes sense for the project timelines and people's availability, someone reviews these reports, makes sense of them, sorts them, identifies trends and develops a snapshot of the known issues. The PM uses that to make the appropriate decisions about what the next steps should be, and you move on. If you feel you have to use a real QA expert, you use him for one simple purpose - to free you from your assumptions. Once he's rattled your cage enough, you send him on his way, make adjustments, and carry on.

Now lest you start thinking that this is really overbearing, I'll give you a sense of scale: in the current project I mentioned in the first paragraph, the total time spent by the project's QA representative on the activities mentioned in the paragraph above this one over the past 18 months was 23 days (roughly (0.25 % of total effort-days to-date), not counting the time spent with the QA auditors when they were on site (unavoidable). Two full-time technical writers (together costing less than half the price of the QA rep) worked on the document stream with his guidance (which also was part of the 23 days).

BTW - all QA audits have been satisfactory, and the interim report for the last audit (we are this --> <-- close to delivery to the live rollout site) passed us with flying colours. More than 99% of the solid quality of the system is directly due to the efforts of the project engineers and programmers. Of course we know the full report is going to take 2 months to prepare, and use up 300 pages to tell us that :-).

Bottom Line: I think Jeff is mostly right.

#20

Quote:"The person that tells you they have the answer may believe it, but I call bullshit."

lmao. Quote of the year. :-)