Design Doc Rant
by Anne Chilldon · 08/06/2007 (8:35 am) · 11 comments
Ok, so seeing as I'm still somewhat new to this community I have been putting off this rant for as long as I can, but after reading the forums for awhile, I think it is necessary. Before I go any further though, I think I should point out that this is not directed to anyone in specific but just a general rant.
It appears to me that a lot of people view the documentation process of making a game as just writing down all the game ideas and organizing them into categories. Being someone who loves and thrives off of this particular process, I view this somewhat as blasphemy, though I will admit that most have the basic sections down: overall story, levels, characters (NPCs & enemies), items and weapons. Yes, these categories are necessary and information must be placed in each of them but what kind of information seems to be what confused from one tutorial to the next. Those categories should be used by the designers to figure out everything. Whoever is in charge of documentation should constantly ask the questions: who, what, where, why and how? If any of those questions are not answered, the designers must go back and figure out a way to answer them. The best example of this I can think of is J.K. Rowling who, on several occasions, has stated that she has storage units filled with notes on every single character, building, animals, etc. in the Harry Potter series. This is what needs to be done with a game's documentation but on a smaller scale.
For each genre of game the documentation changes, if you are doing a puzzle game, you do not need as much documentation on characters as you would for an RPG. If you are trying to go for a game that emotionally involves the player you are going to need a lot more documentation for the back stories. You want to make the player see that you know a lot more than what you are letting on.
Documentation is used by everyone in your team so needs to be readable by everyone, and not everyone likes to read pages of back story to find out why someone has a scar on their right cheek. To make it easier to read, it is suggested to use the "newspaper technique." Highlight everything that really needs to be known in the first paragraph. In the following three paragraphs, give a slightly more detailed version of the information given in first paragraph. After that feel free to write a whole novel on something but always keep in mind that there is a possibility that no one but you will read it.
It doesn't stop there though! Each previous category should include the stats for each person/item in said category. The documentation also should include descriptions of how things look and/or sound, detailed enough to give concept artists and musicians. Said concept art should also make its way into the documentation. There also should be a place to hold algorithms, and in the case of games using combos, the sequence to create such combo. Specifications on the hardware that will be used to play the game, for PCs it is a good idea to the basic and optimal performance specs, and the audience you are trying to target with your game should also have their own very special spot.
Most importantly, the game document should grow with the game. Stats change through testing and should be changed in the document. Many things change while making a game and those changes should be reflected in the document. It is a living thing and should be treated with respect instead of just being thrown to the side once you start coding.
Many people in the industry consider those of us that like to do documentation a little odd, I have been called a sadist on more than one occasion. Yes, it can be a tedious job but it is an extremely rewarding job also. Even though I haven't even started scratching the surface of what goes into a document, hopefully this will help those that are asking questions about how to document and make others realize that it isn't just compiling notes into separate categories.
It appears to me that a lot of people view the documentation process of making a game as just writing down all the game ideas and organizing them into categories. Being someone who loves and thrives off of this particular process, I view this somewhat as blasphemy, though I will admit that most have the basic sections down: overall story, levels, characters (NPCs & enemies), items and weapons. Yes, these categories are necessary and information must be placed in each of them but what kind of information seems to be what confused from one tutorial to the next. Those categories should be used by the designers to figure out everything. Whoever is in charge of documentation should constantly ask the questions: who, what, where, why and how? If any of those questions are not answered, the designers must go back and figure out a way to answer them. The best example of this I can think of is J.K. Rowling who, on several occasions, has stated that she has storage units filled with notes on every single character, building, animals, etc. in the Harry Potter series. This is what needs to be done with a game's documentation but on a smaller scale.
For each genre of game the documentation changes, if you are doing a puzzle game, you do not need as much documentation on characters as you would for an RPG. If you are trying to go for a game that emotionally involves the player you are going to need a lot more documentation for the back stories. You want to make the player see that you know a lot more than what you are letting on.
Documentation is used by everyone in your team so needs to be readable by everyone, and not everyone likes to read pages of back story to find out why someone has a scar on their right cheek. To make it easier to read, it is suggested to use the "newspaper technique." Highlight everything that really needs to be known in the first paragraph. In the following three paragraphs, give a slightly more detailed version of the information given in first paragraph. After that feel free to write a whole novel on something but always keep in mind that there is a possibility that no one but you will read it.
It doesn't stop there though! Each previous category should include the stats for each person/item in said category. The documentation also should include descriptions of how things look and/or sound, detailed enough to give concept artists and musicians. Said concept art should also make its way into the documentation. There also should be a place to hold algorithms, and in the case of games using combos, the sequence to create such combo. Specifications on the hardware that will be used to play the game, for PCs it is a good idea to the basic and optimal performance specs, and the audience you are trying to target with your game should also have their own very special spot.
Most importantly, the game document should grow with the game. Stats change through testing and should be changed in the document. Many things change while making a game and those changes should be reflected in the document. It is a living thing and should be treated with respect instead of just being thrown to the side once you start coding.
Many people in the industry consider those of us that like to do documentation a little odd, I have been called a sadist on more than one occasion. Yes, it can be a tedious job but it is an extremely rewarding job also. Even though I haven't even started scratching the surface of what goes into a document, hopefully this will help those that are asking questions about how to document and make others realize that it isn't just compiling notes into separate categories.
#2
I still have a love/hate relationship with documentation. If I'm really devoted to a project I can find enjoyment for hours in writing pages more than would be necessary for backstories, origins and other little details for a world. Of course, the flip side of that is if I'm not as excited about a project then the documentation is something I have to slog through and finish.
Either way its still important. I remember back in school there were a few instances where a certain element of the game was called into question and four people remembered it three different ways while the fifth one didn't remember discussing it in the first place, fortunately it was almost always written down in the documentation. Yes, I said almost, and those moments not covered by the 'almost' sucked.
08/06/2007 (9:38 am)
Well of course you're a sadist, anybody who went to Full Sail is. ;)I still have a love/hate relationship with documentation. If I'm really devoted to a project I can find enjoyment for hours in writing pages more than would be necessary for backstories, origins and other little details for a world. Of course, the flip side of that is if I'm not as excited about a project then the documentation is something I have to slog through and finish.
Either way its still important. I remember back in school there were a few instances where a certain element of the game was called into question and four people remembered it three different ways while the fifth one didn't remember discussing it in the first place, fortunately it was almost always written down in the documentation. Yes, I said almost, and those moments not covered by the 'almost' sucked.
#3
I can definitely see the need for extensive documentation when developing a game with a team, but the usefulness isn't so obvious if a lone wolf wants to make a game.
08/06/2007 (11:45 am)
What do you think about design documents for solo hobby developers, Anne?I can definitely see the need for extensive documentation when developing a game with a team, but the usefulness isn't so obvious if a lone wolf wants to make a game.
#4
personally I find a few pages of ideas, general planning and suchlike is good, it provides a nice guidline while being flexable enough to grow and change. Also, I write down any sudden ideas I get because otherwise I forget them. Whether this process will work...shrug. We'll see.
08/06/2007 (11:52 am)
And I've read post mortems that point the other way. The unreal tournament guys had no design document originally, they played around and implemented their ideas and in the end had a smash hit (The post mortem was written by a guy on a different team, who had a design document and a plan and didn't do half as well, recommending agile and flexable development). 2 Years into development I have found that design doesn't survive contact with reality. Unless you have a lot of experience behind you and even then....personally I find a few pages of ideas, general planning and suchlike is good, it provides a nice guidline while being flexable enough to grow and change. Also, I write down any sudden ideas I get because otherwise I forget them. Whether this process will work...shrug. We'll see.
#5
Most often when I see these posts, it's just one person with an idea wanting to take on and then change the world. Grand ambition has it's place, but not when the only documentation you have is a basic world story and loose (oh but the players make all the story) plot! Much less is when there are those who have no documentation at all.
Sorry if I sound harsh, and I am most definately *not* trying to discourage anyone from making games. All I would like to see is a little more realistic ambition. I know first hand that if you try and take on the world, solo or even with a team, and it's your first attack, you will more than likely fail. This failure will likely sour you on future attempts, and the world wins another round and another potential great game fades into the dust.
Keep your grand visions on the shelf when you're just starting out, please. Better yet, look at your grand idea, and see if there's a single, tiny piece of that world/game which could be made into a simpler, smaller game. Take a minigame idea and turn that into a stand-alone. Take a single element and flesh it out.
Dream big, yes, but when it comes time to actually work, start small and build upwards.
This has been another public service announcement from the Crazy Kitsune (TM)!
08/06/2007 (11:53 am)
Just want to pitch my $0.02 in and agree wholeheartedly with Anne here. I see so many posts in Help Wanted, various other forums, and even on blogs where someone new to GG and worse totally new to game design as a whole is stating their intent to start a big project (often another MMO).Most often when I see these posts, it's just one person with an idea wanting to take on and then change the world. Grand ambition has it's place, but not when the only documentation you have is a basic world story and loose (oh but the players make all the story) plot! Much less is when there are those who have no documentation at all.
Sorry if I sound harsh, and I am most definately *not* trying to discourage anyone from making games. All I would like to see is a little more realistic ambition. I know first hand that if you try and take on the world, solo or even with a team, and it's your first attack, you will more than likely fail. This failure will likely sour you on future attempts, and the world wins another round and another potential great game fades into the dust.
Keep your grand visions on the shelf when you're just starting out, please. Better yet, look at your grand idea, and see if there's a single, tiny piece of that world/game which could be made into a simpler, smaller game. Take a minigame idea and turn that into a stand-alone. Take a single element and flesh it out.
Dream big, yes, but when it comes time to actually work, start small and build upwards.
This has been another public service announcement from the Crazy Kitsune (TM)!
#6
We spent a couple of years tossing around ideas and making notes. All ending up in a Design Document, Techincal Document, Appendixes, Business Plan, Game Manual and Game Demo Manuscript (All the hundreds of pages are still under heavy improvement).
Currently its around 90 hours a week on the game project, but its worth the effort for sure!
08/06/2007 (3:04 pm)
I agree that documentation is important :)We spent a couple of years tossing around ideas and making notes. All ending up in a Design Document, Techincal Document, Appendixes, Business Plan, Game Manual and Game Demo Manuscript (All the hundreds of pages are still under heavy improvement).
Currently its around 90 hours a week on the game project, but its worth the effort for sure!
#7
Hope that answered your questions.
08/06/2007 (5:04 pm)
@ Kevin - I think the importance of docs for solo hobby developers depeds on the scale of the project. I look at it this way, there could always be the chance to turn a game being done by one person into a larger scale game done on a team. If that happens, the one person working on it originally has to go through everything that they thought about while designing and programming the game (which is alot harder to do if they haven't touched the game in awhile) when it would be easier to write stuff down before they start coding and during the code process.Hope that answered your questions.
#8
08/06/2007 (5:09 pm)
Yeah, that makes sense. Thanks for answering my question.
#9
I cant stress how important it is to have good documentation in order to get your ideas across to someone else, like a contract dev/artist/musician if you want them to be able to produce what you are expecting. If you cant get your idea across, you will end up with something that doesn't quite satisfy you, and its not the contractors fault, its yours.
Of course you may be able to skip a lot of it if you have a close working relationship, like in the same office, and you both have the same vision. Even then, you may find your ideas diverge more than you think.
08/06/2007 (5:34 pm)
I think I mentioned something similar a while back, after I had been on a clients site writing a software requirements doc to inform the client and our Dutch programmer how I saw our base logistics package being modified to fit the clients workflow. I cant stress how important it is to have good documentation in order to get your ideas across to someone else, like a contract dev/artist/musician if you want them to be able to produce what you are expecting. If you cant get your idea across, you will end up with something that doesn't quite satisfy you, and its not the contractors fault, its yours.
Of course you may be able to skip a lot of it if you have a close working relationship, like in the same office, and you both have the same vision. Even then, you may find your ideas diverge more than you think.
#10
It really verys based on your team andw hat they feel comfirtable with. Where I currently work we have no working design document. We have a general idea of the game and where it is we want it to go. But most of the story and everything comes from different designs and a effort on everyones part at our daily meetings.
Each day before we start work we have a 30min to a hour long meeting and talk about what each person is working on and then what each cell is going to be working on as a group. We also toss in some ideas about features and such when it comes around.
But the general idea is we add in a feature play the game. Is it fun? Does it add to the game? Does it fit within the game? If we can answer all these questions it decides if the feature stays or go. Is there lost work that way? Sure but it also keep the game fun to play as everyone plays the gme on a daily basis at the end of the work day to unwind and find any issues.
Theres no concert document that says all this stuff will make it into the game and is priority. No the priority is making a FUN game in the end.
Ageain though all fo this verys from company to company and team to team. I love doing work this way as my cell isnt tied down to a list of stuff that we HAVE to do. Each day we vote and decided what feature / work needs to be tried for the day and go from there.
Its what is called a living design document that is created on the fly as the game is made. Alot of companys go this route. As stated above alot of the Epic games go off this route of design as you go. Is it fun? thats the key and the goal.
08/07/2007 (2:07 pm)
I tend to find things very from company to company. There is no RIGHT or WRONG way to go about it. Some teams of people do really well without ever making a design document while other teams tend to do well with making a detailed design document.It really verys based on your team andw hat they feel comfirtable with. Where I currently work we have no working design document. We have a general idea of the game and where it is we want it to go. But most of the story and everything comes from different designs and a effort on everyones part at our daily meetings.
Each day before we start work we have a 30min to a hour long meeting and talk about what each person is working on and then what each cell is going to be working on as a group. We also toss in some ideas about features and such when it comes around.
But the general idea is we add in a feature play the game. Is it fun? Does it add to the game? Does it fit within the game? If we can answer all these questions it decides if the feature stays or go. Is there lost work that way? Sure but it also keep the game fun to play as everyone plays the gme on a daily basis at the end of the work day to unwind and find any issues.
Theres no concert document that says all this stuff will make it into the game and is priority. No the priority is making a FUN game in the end.
Ageain though all fo this verys from company to company and team to team. I love doing work this way as my cell isnt tied down to a list of stuff that we HAVE to do. Each day we vote and decided what feature / work needs to be tried for the day and go from there.
Its what is called a living design document that is created on the fly as the game is made. Alot of companys go this route. As stated above alot of the Epic games go off this route of design as you go. Is it fun? thats the key and the goal.
#11
I found that documenting and keeping the documentation up-to-date as you go along makes you actually think twice on a certain topic, maybe even dropping it completely as you figure out "Hey, that's actually not as good an idea as i initially thought."
Documentation is a neccessary "evil", but your will be grateful for any documentation that was done and updated timely - especially if you have changes within your team (the evil word "handover" or "knowledge transfer" pops to my mind).
In professional projects (not only games, but any kind of software), you need quite a lot of documentation (Busines Case, Functional & Technical Requirements & Specifications, Architectureal Design, User Guides, Support & Training Documentation, ... ). For Fun Projects, this seems to be overkill, as it actually requires a lot of paperwork done before you can get down to code. But believe me, it is well worth it, even if you are only using a "crippled" version of those documents. Especially as a Fun/Indie developer, you have only very limited resources at hand, so time is your most valuable asset. Changing a feature in design phase costs you almost nothing, but the more advanced your progress already is, changing a feature after implementation will cost you double or tripple the time.
Off course, you can overdo it... I currently have the pleasure of working for Investment Banks, and their software development & documentation life cycle sometimes is just a pain in the a**.
You have to find the right balance, but ultimately, there should be somebody being able to tell you "when which feature will / will not be implemented into which milestone / release"... But then, everybody has to find/create the working environment best suited for him/herself.
08/08/2007 (8:21 am)
heres my 5 cent on that..I found that documenting and keeping the documentation up-to-date as you go along makes you actually think twice on a certain topic, maybe even dropping it completely as you figure out "Hey, that's actually not as good an idea as i initially thought."
Documentation is a neccessary "evil", but your will be grateful for any documentation that was done and updated timely - especially if you have changes within your team (the evil word "handover" or "knowledge transfer" pops to my mind).
In professional projects (not only games, but any kind of software), you need quite a lot of documentation (Busines Case, Functional & Technical Requirements & Specifications, Architectureal Design, User Guides, Support & Training Documentation, ... ). For Fun Projects, this seems to be overkill, as it actually requires a lot of paperwork done before you can get down to code. But believe me, it is well worth it, even if you are only using a "crippled" version of those documents. Especially as a Fun/Indie developer, you have only very limited resources at hand, so time is your most valuable asset. Changing a feature in design phase costs you almost nothing, but the more advanced your progress already is, changing a feature after implementation will cost you double or tripple the time.
Off course, you can overdo it... I currently have the pleasure of working for Investment Banks, and their software development & documentation life cycle sometimes is just a pain in the a**.
You have to find the right balance, but ultimately, there should be somebody being able to tell you "when which feature will / will not be implemented into which milestone / release"... But then, everybody has to find/create the working environment best suited for him/herself.
Employee Michael Perry
ZombieShortbus
Let me know when your book is published =)