Earlier this year, I came across a section in a book on the role of the design document in development. Now, during my time in the games industry whilst Working For Other People (yuk), I came to the conclusion that only two of the plethora of attitudes towards The Doc was actually put into practice in genuine game development - (1) basically, there isn't one, or (2) it's researched, written, re-written, and then largely ignored while the game is actually developed. (I assumed that this happened because of the pressure involved - people simply didn't have the time to update it.) When I started work on my first game ack in February, I wasn't sure what approach to take. I spent the best part of two weeks full-time on the doc itself in an attempt to assure myself that every element sat nicely next to the others, brainstorming, adding twenty ideas, removing nineteen of them and so on until I felt like I had exactly what I wanted. Then: I started work on the game. At first I was obsessive, taking an "if it's not in the doc, it's not in the game" approach, leaving it on my desk where I could see it and altering it before I made any actual changes to the design. As time went on, it got updated less and less, and now it's basically fallen by the wayside. I think it's because I feel I can make better impulse decisions concerning the game, now that I've spent the best part of a year on it. Of course, it could be simply because I'm getting a little tetchy nowadays It'd be interesting to hear other people's attitudes towards design documents. Here in this forum I see that there's a good mix of newcomers like myself, people with strong and successful titles to their names, and all shades between. So - do people in general feel the need to use a design document? How extensive is it? And how flexible is it? And, does its relevance change as the project progresses?
First, unless you're trying to communicate changes to a number of people, a design document serves little purpose for the lone developer. Instead, keep a little notebook (or personal wiki) of things you'd like to add - and I mean everything - then every day ask yourself if each would enhance the game. If so, add it. If not, remove it. It may help to document your engine and interfaces as you're developing, but a game design document really just slows down the creative process. You can read more of my thoughts on evolving game design here.
I've never bothered. I think people get a bit obsessed doing a design doc. Designers do it, because its (I guess) evidence of work, more than a real development aid. If I think a feature would b cool, I code it, play with it, If it looks or feels wrong, I ditch it right away. You can write a design doc all day for 6 months, then on day one of implementing it, you realise it's all not going to work. Why waste the time? I think most one-man devs are the same. If you can't code, and are part of a team, maybe theres more need, but having someone write a doc, separate to the actual dev process of coding it, seems the absolute opposite of 'agile development' (or whatever the latest buzz word for that is).
The size of the design doc is a sliding scale from none to very detailed. If one person is doing the whole project, then the design doc can be skipped. At three team members there should be a basic outline. If you add even more people then it should be more detailed. I've done contract games for companies and some required a totally detailed doc, and some have required nothing. Tom
I think you should try making a few first attempts in making small games without a concept doc. You might end up with long periods of looking at the screen thinking what to do now/first and how. Also, you might finish a huge portion and then think you should have done it completly different. Or that you added so many new features that it looks like a big tower made out of patches. I think you *SHOULD* go without a concept doc to learn what you should include in it and how descriptive you should be. Write down what made you stop programming and think what to do, what made you rewrite the code, what made you step out of your timeframe and make your game over-featured so it will never be completed. learn by experience, that's my advice. I'm doing my third iteration at making a game and without the first two, I wouldnt have the experience needed to know what i need to think of. I'd definetly made the first two different by almost every aspect from design to implementation.
Curiously enough, I just wrote an article about this subject in an article called, 'You Can't Design Fun On Paper." Mainly, I consider the design document to be the "paper prototype" of a game. It is a vehicle to help bring ideas from the more abstract "in my head" stage to something I can look at a bit more analytically and check for weaknesses. It also serves to record a list of things to do. And finally, it serves to communicate these to other team members. The amount of detail that goes into a design document depends on the size / scope of the project and the number of team members. If you are a lone-wolf doing a match-three puzzle game, you might need nothing more than a rolling "to-do" list to serve as your design doc (I can't keep such things in my head, and I DO consider task lists to be part of a design document). If you are doing a sizeable, plot-heavy / content heavy RPG or adventure game, you will be screwed if you don't have a decent plan in place. I think too much detail kills a design doc as quickly as having one without enough information. I see "game designers" who seem to think they earn their pay by page count, and what they produce ends up being almost perfectly useless. The best design docs are short, sweet, to-the-point, and easy to use and find exactly what you are looking for. Since I believe design docs are the "paper prototypes" (even if you don't actually print them out on paper, but they are just a collection of notes, tasks lists, and cool ideas in a directory on your computer), I believe that once the elements of the doc get implemented (or even before then), that part of the design document becomes obsolete and the GAME becomes the design doc. I don't believe that "if it's not on the page, it's not on the stage." Design docs are a starting point, not a blueprint. No plan survives contact with the enemy, and no design document survives contact with implementation. If you are any good at what you do, you will quickly discover flaws in the original design as you implement, and improve on them as you go.
I began by not writing a design document for my first game, then I wrote a design doc for gameplay elements in Riotball. In my latest game Angkor (yet to be released, and its a match 3 game ) I included pretty much everything in the design document except art. My design documents aren't that detailed, they don't concern themselves with code or the nitty gritties of the game, except that I design gameplay on paper with full detail. I use design document in the following ways: 1. Design documents serves as a overall architecture, a guideline for the development of the game. It is easy to get carried away and add one feature and next, and end up with a game that looks like a jumble. Noting down the main points of the game design allows me to maintain continuity of the design philosophy of the game. 2. Whenever I realise that a game feature was fun on paper, but will be boring in practice, I update the design document first & then make the changes in the code. During the course of game development, I change the design document many, many times. 3. Design documents acts as todo list for me. I can't keep a todo list, because when I look at the looong list of things pending, I loose motivation and start procastinating. So I look at the design document, pick a feature to add, and then go to work. 4. I use it as a reference to tell the artist and the musician what to do. 5. Writing a design document helps me to crystallize my design ideas when I am still designing the game. I find that putting things down in writing helps in clarifying to me as to what I really want to do.
On a personal reason, I use design doc all the time for many reasons : 1. To make sure I know what i'm doing. It's also a good way to know wether you'd be able to make the game or not. 2. To make sure I don't stray from the original plan. This happens when I usually have to left my game for other important things. 3. To break down all the resources I have to make and make sure no stone left unturn. Being an indie meanings that you'll have to work with freelancers and they don't like when you say "hmm.. can you add this later on" 4. It makes me look smart but sadly it'll only go that far In a project you need to have the so-called "BIBLE" and I've seen many of these bibles are 1K pages. It's pretty normal but of course nobody reads it.. WRONG. The project manager must know the content by heart but other members of the project only need to know what they need to know thus there are so many short version of the project documentation.
IME, the part played by design docs is mainly that of being a cats paw for publishers to fuck you about with, once they've decided they want out of their contract and see that feature "A.3" you did is better than the one in the doc, but not the one in the doc. I think that's about it.
Thanks for all your responses. The best thing about this place is the broad range of people here and the variety of opinions that you'll get in response to a question (plus ... nobody beat me up despite my having started this thread in the wrong section ) which of course you've got to take with a pinch of salt, or tabasco sauce if you're lucky enough to be still allowed to eat it. (Way OT) My doctor told me to give up spicy foods *and* alcohol this week. I thought she was joking. Dammit. Man, that's harsh. From 1997 up until this year. That was enough for me.
I agree with Coyote on this one. I never cared to use design documents in the past, but as I'm getting busier I just don't have time to bring the people I'm working with up to speed via talking or emails. I now just point them to the design document when they want to know what the project is about, how gameplay will work, and the expected scope. Nothing too detailed. Just an architectural roadmap to help everyone get started and stay on the same page. So far it's been a success.
I never use a design document, at least not in the usual "put there everything" format. I write design notes in a wiki-thing, just to make sure that i don't forget things, but nothing beyond that. I think that the game develops as i playtest it: there is a core idea ("heartbeat" as i saw it somewhere) that the game is all about, which isn't going to change, but the rest is simply fluid. I've tried to use a design doc though. But i ended spending much more time on the doc, revising it, modifying it, etc than the game. At the end it didn't helped me much.
Documents are essentially for communicating ideas to other people, or making notes for yourself. When writing my own games, I rarely use any kind of written documentation. I usually have the whole thing in my head. If the idea isn't solid enough to work like that, I haven't thought about it enough. So by the time I can write it down, I don't need to. I will occasionally make lists of things I want to put in the game, pickups and what they do, but it's only because sometimes I can sometimes forget an idea before I get round to implementing it. So these lists are really a brain dump. I will sometimes write a short document that outlines an idea for a game. This is usually when I've thought of it but don't have time to develop it. When working with other people, it is essential to have documents for them to refer to when developing assets. Without them, there is scope for people to become unfocussed and go off in a direction that is counterproductive. In the past I wrote design documents and expected people to keep to them. That doesn't work. People aren't robots to follow instructions. Now I allow people the freedom to do what they want provided they can communicate what that is before they start, then I write it down as part of the design documentation, so that the direction is available to the whole team.
Not sure I agree. I've been through the same "spend weeks making a massive tome of design that nobody reads" process as well, and I also went through the "Let's stop having a design doc at all" phase. Niether was a smashing success. Since starting casual games, I have moved to a slimmer, Powerpoint-based documentation, and that has worked pretty well. Being visual, it's easier to read/understand, so we get a lot of people involved with it, and since it's kept VERY short, it generally serves as a bridge to get us to a prototype quickly - hich we then free ourselves to mess with as much as we want. Then the design doc becomes a living document, where we update as necessary, often using scren shots from our own game with scribbles, etc. Especially when working with a lot of overseas contractors, having SOMETHING we can all put our hands on and say "this is our game" is helpful. Additionally, it makes publishers happy, which if you are using a publisher, is a good thing. You like them happy.
I don't write a full design document, but I find that writing something down or explaining something out loud to someone else is a serializing process that forces you to structure your thoughts and helps see the holes in your idea. I write things down for myself when I can't figure something out, and usually the solution comes before I'm even done writing a whole paragraph. As for working with artists, I'm lucky that mine originates a design or at worst, is very involved in it. Trying to figure out the game flow, balancing, and fun factor in general, an original, small scoping document, followed by e-mail, IM and sitting in front of a whiteboard (if you live close to each other, like we're lucky to) seems to work much better for our medium than pontificating a spec that will be quickly irrelevant and never updated. Best regards, Emmanuel
I refer to my docs as 'the bible'. When you make up a concept for a game, you put it on paper. You add it to it. You continue to add to it, you change it, you remove things that won't work. If you're a smart developer, your design docs for a particular title will change all the time - because rarely we ever get it right the first time. You also use these docs as a reference. Hopefully your designer has some knowledge of what the engine can do, or what the programmers can pull off - a lot of times you`ll scratch stuff off because of this reason. A fully realized game document (for me) is roughly 25-200 pages long depending on the genre, features, if i include a publisher pitch, all that kind of stuff. Basically, we use this as a reference because paper has more memory that our brains oddly enough.
This is also discussed here in relation to casual games. http://forums.indiegamer.com/showthread.php?t=8626 Not as deep as this thread but perhaps more inline with your typical indie developer (small scale games).
During my last game I vowed that the next I worked on would have a thorough design doc, as I was wasting so much time chasing dead ends all through development. Surprise, surprise, I've started my next game and still no design doc! I'm trying to create something very different this time around, and I just can't see much point in a design doc if there's no clear precedent demonstrating that the gameplay will actually work. It really has to be a case of: think up an idea, and then prototype it to see if it works in practice. If it doesn't, ditch it and be thankful you didn't waste time on a comprehensive design doc. Perhaps it would be different if I were working with a team though...