Separate names with a comma.
Discussion in 'Game Design' started by Bernard François, Aug 12, 2007.
Can you give us few examples of the game you have design like that?
About 1/4 side of an envelope
Off the top of my head...
X-Files: Resist or Serve (PS2)
Star Wars EP3 (Xbox / PS2)
Jungle Strike (Genesis / SNES / PC / Amiga / Game Gear / Gameboy)
Urban Strike (Genesis / SNES / Gameboy)
Nuclear Strike (N64)
MX2002 (Xbox / PS2)
and a bunch of levels for Legacy of Kain (PS1 / PC)
There are more, but those are the ones off the top of my head that had high paper-to-play ratios.
My point is, write the documentation you feel comfortable with, but remember, the larger your game and the more people you have to coordinate with, the better it is to write things down. It'll save time and money in the long-run.
I assume you are talking about design documents that evolved over the life of the project. If you are telling me that you wrote 125 page design documents pre-development that turned out to be 80% representative of the final product, I'm calling big time BS here Except for maybe the Strike sequels, as the mechanics were obviously well-defined in those cases...
Regardless however, sounds like you guys did a good job of thinking mechanics-oriented throughout development. I wish I had worked with more guys like you in the past, haha.
(Meridian59, huh? Is that 3D0? I know a lot of ex-3D0'ers)
Anyway, those examples are ones that where the documentation was properly executed in PRE-PRODUCTION and the game was executed to spec, with little to no deviation from the design. As a matter of fact, I've heard more than once from over my 20+ year career, "stop telling us it's in the doc," from various team members while in meetings.
If you look at each Strike game, with the exception of Nuclear Strike, each game involved new mechanics, so saying they were "well-defined" is a disservice, but whatever...
Keeping on topic, I think the excersize of writing documentation is as invaluable a tool in learning what "to do" and what "not to do", as with actually executing the game. People learn through repetition and it's even been said that people learn more from failure than they do success.
As for "how long", as previously stated, "how long" is "as long as it needs to be". In the case of a standard "developer / publisher" relationship, longer is better. The less left up to interpretation, the better. Also, the larger the team, the larger the document, I'd say. Again, avoiding confusion.
Small games / small teams don't require as much documentation.
Also, to "over documenting", try to keep "fluffy stuff" like buzzwords, backstory, etc. in one section and up-front in the document. That way, people who care about that stuff can go to that section and people that care about how much gold it takes to buy a broadsword aren't mired down in plot twists.
No offense intended with the "well-defined mechanics" comment, and I apologize for that. Obviously there were mechanics that must have carried over from game to game, but nailing any new mechanics during preproduction is certainly an achievement.
You've certainly raised my standard on this topic, and I think I'm going to try and hold myself to that standard in the future... Knowing that it can be done and all
I especially agree with your last paragraph, and that's kinda what I was getting at when I was talking about designers thinking in a mechanic-oriented way. It's hard to find designers who can easily separate the two.
Yep, Meridian 59 from 3do. Ironically, I didn't start working on Meridian until after I *quit* 3do. In fact, I didn't even know Meridian was a 3do game until then... Go 3do marketing! LOL...
lol, my current one for a shoot-em-up 2D platformer is 45 sheets of BUTCHERS PAPER (about 1 mtr tall and 75cm wide), + 92 printed sheets of game design elements and docs about what makes a good game in that genre, ect...;
My handwriting is quite small too...
is there a name for a document thats more story driven? maybe not a 'design' document, but is there such a thing is a story document?
I'm more interested in the story behind role playing or adventure games and how the story fits into the elements of the game. I enjoy writing out my story ideas in relation to game design because it lets me see what ideas are totally whack and what ideas could potentially work. As well as fleshing out characters and how they evolve over the game.
I'm also interested in the flow and pacing of a game and things happening at the right time - which I felt was related to the pacing of the storyline.
I would like to share my ideas with others who are interested in making their own games, but I'd hate to just share a story idea without showing how it can relate to real game dynamics.
I believe a GDD (game design document) should be tailored to the game it's written for. Sure,I have a specific format I used and have cultivated over the years (and it seems to keep spreading throughout the industry, as more people see my designs), but each GDD is geared towards the product it was written for and each one is a learning experience.
A game that's more story-driven should have more story elements, almost like a script, as long as it ties the narrative to the game mechanics, otherwise you're simply writing a novella.
Mine vary between hundreds and no pages, depending on the type of game. RPGs and RTSs will have huge ones, smaller and more action-oriented games or puzzle games might need none at all.
Ok...newbie to the boards here, but I am no stranger to written design documents. I have had to write documents for smaller games (downloadable) as well as larger console (console titles). To echo previous statements a design document needs to be as long as it needs to be.
Most of my design documents are written to identify what tasks other people on the team need to do. This is greatly important when no one has a real clear vision of the project. If you have a schedule that is short, a more detailed document is needed. This usually leads to gross discrepancies between documentation and final product, but is not the rule of thumb. With a project that has a longer development cycle, I think you can do with less detailed document.
I find that with a longer project, with proper prototyping, a smaller concise documents covering specific systems will probably be better it allows for flexibility down the line. More detailed documents can also work. What I have found is if your documents specify parameters and tweakable variables, you document then is flexible enough to stand the test of time. When you start detailing, exact numbers expecting that to be the final product you will probably find your are more often wrong. What is most important for a designer is knowing what variables you will want to tune when further in to development.
In my current project at my game company, a downloadable XBLA/PSN title, the design document is about 80 to 90 pages. I think most of it is still fairly close to the final product, but there are some wholes when it comes to the UI design. It's not one of my strengths. I have a second project with the same parameters at is like 100 pages, but 30-40 is boss pictures and documentation. All mine refer to working in Word.
I have one question for all, who here uses a wiki for documentation? I'm sure that makes it harder to say how long a document is.
I use a wiki. You can still estimate pages of text based on the size of plain text (.txt format) -- 2kb is about one page more or less -- but yeah, it's harder.
I write my first draft of the GDD to include everything the game will do and what I want in the game.
Then every draft after that is where new, maybe better ideas come into play, but eventually my GDD reaches a final draft.
So I really believe in a flexable GDD, and a well documented GDD that everyone in your group gets to see, no matter how big or small the update is.
We summarise every game on one page, then the game design document gets made and edited along the way. We use it mostly as reference to get everybody ( 2 people working from home) to understand what it's about and the general direction.
Current game doc has 11 pages and grows everytime we have to get into specifics. The gameplay is one page. The art another, the interface yet another, menu structure takes up 4 pages, we'll add the achievements and other bits on the way when they get made, as it's faster to just make a list of achievements, then making them directly (the symbols) than going through all the design then build hassle.
Then again, this is our first game, so I guess we'll adapt our methods when necessery.
I don't have a design document at the beginning. I play something for a while in my head, and if it feels like a winner I do a prototype.
Once the prototype is up and running and I like it, and it feels like a winner, then I do the design document, as there is no point in doing a design document when its in the "fantasy/feasibility" stage.
I'm at the moment just about to do the design doc for my game as its passed the prototype with flying colours, wish me luck!
All I can say is for a design doc is: if you're doing one, approach it like a screenwriter. These people do not leave room for error. They specify the scene exactly how it should be. Example: "The glass is in her left hand, and she wears a button on her blouse hem." - WRONG! it should be: "The glass is in her left hand, and she wears a pink dress, with four round red buttons. There is a 5th red button on her blouse hem, on the right side."
Specifics are everything for a design doc imho. Write it so that the game could not possibly be made in any other/accidential way.