Out of curiosity, how many of you write a design document when you think of a new game idea? How many of you use the document while you are making the game, as opposed to keeping the whole idea in your head? If your game has plot and character, do you write out the whole plot and give the characters in-depth descriptions, or do you do something else? Do you ever re-write?

If the game is really simple, like an arcade or puzzle game, then I''m less inspired (read "more lazy ) when it comes to writing up a doc. But for larger design I think it''s essential. I find when you put everything down on paper it forces you to work out parts you forgot or ignored, and it''s a great way of catching your errors.

--------------------
Just waiting for the mothership...

I hardly write anything down. I''m the most unorganized programmer there is. My writing on this forum is the closest thing to writing my ideas down as I get. I know I should write my ideas down, but I don''t anyway. That''s pretty much how I am in every other area of life too.

"'Nazrix is cool' -- Nazrix" --Darkmage --Godfree

I write down notes, thoughts, synopsis, titles that will remind me of a whole story I came up with. I draw, draw, draw, scribble, dabble ...
I put everything in a big notebook, and leave it on low heat, for a variable period of time. Once in a while, I check it out, and see if I come up with something new, or if I can do it technically.
It''s all a big junkyeard on paper and in my head.
As for design doc. If it''s clear in my head, then the design doc will write itself. I guess I still have too much Artsy influence in my creative process ... but that''s the way I am
*very* unproductive.

youpla :-P

Sorry for being so frank, but:

People that does not make design documents are a bunch of amateurs!

Said that, you cannot make anything worth anything if you don't do a design document - and not just a few notes - a proper one - at the very least 50 pages worth - very much depending on the size of the project. The project I am currently on uses a 300+ pages design document and it is still growing.

I doesn't have to be all done before you begin. Tge development process is also a creative one where things must be allowed to change underway. And the final document doesnøt have to a formal one, a organized set of hand written notes might also do - how the design document is done is a matter of style - but it must be there.

If you don't have a design document, either:
* The project is so small and simple nobody will play it anyway when it is done.
* You don't know what you are doing so you will have to rewrite it several times and chances are that it will never be done.

Do you think people begin building a bridge without making a drawing first? No.
Do you think people weave a beautiful carpet without having a design sketched out? No.
Do you think a carpenter makes a chair without a drawing? No.

What makes amateur programmers think that that making software is any different?

You must all have heard how big software project fails or go miserably over-budget. In my country there is a big scandal right now with the unemployment office software that doesn't work and cost 10 times the estimnated price. All because people did not properly think and write down before they started and properly examine the user's needs.

Just sitting down with an idea in your head and coding is what in software engineering is called "code and fix" strategy for making software and it has been proved as been the worst strategy possible and is something profesionals have not done since the sixties.

We have courses at computer science in our university teaching about this. You cannot do anything serious without a design document. And thats final. If you think otherwise you are naive and stupid.

(Flames are welcome!)

B.Sc. Jacob Marner
Graduate student of computer science

Edited by - felonius on October 4, 2000 6:34:35 PM

The game I am working on is being almost complete redesigned from scratch. We barely got a good demo ready in time for the gdc contest, but we did, now we are redesigning pretty much the whole thing. The original game play design that the artist/designer made was pretty bare bones and I didn't have time to design anything. I am currently designing the main architecture for the engine, the script system, the AI system, and all that other stuff. I'll be designing for atleast another week. The current design is about 12 pages.

The game play / story designer is doing the same thing. I want to have the most complete design possible, so by the end, the total game design doc will probably be between 25-100 pages. It may sound like overkill, but I have made stuff, with out the proper planning, and it never turns out good.

The new game will use D3D and it can run in different screen modes. I redid my old four elements contest entry, and its 100 times better. One of these days, I'm going to put up some more screen shots.

Been a long time since I posted.

Domini
Rastagon 2 Engine

Edited by - Domini on October 4, 2000 6:45:28 PM

quote:Original post by DarkAngel16

I Agree, for any decent project a Game Design Document is essential.... Although my Design Document''s always end up being thought''s, note''s, idea''s etc... ahh well better then nothing ey ?

Absolutely, it is much better than nothing.

But again, it depends on the scope of the project. The more people you are and the larger the project the larger and more formalized design document you need.

If you just work on a project alone a note book full of notes is just fine, because you are the only one reading it, but as ahw mentions he does above, it is important to review past notes and discard some, rewrite some with improvements and generally keep organized as a orginaization keeps you thought organized and you are much more sure that you will not miss something or make a contradictory design.

I will just add a few reminders of things that beginners must remember when writing documents. This isn''t just empty talk.

Make sure to distinguish clearly between WHAT you want you game to do and HOW it should be done. You should divide the document into at least these parts:
1. The so-called Requirements Specification document: What should the program do. This should be very concrete things that after the program is done can be looked at to see if the program really does what it is supposed to do.
2. The so-called Systems Design document: How should the program do things - and how should the code be organized.

Another thing to remember is to write down WHY some decision is made. By doing this you will be able to remember it later on why some decision was made - and yes you will forget no matter how clear the ideas are in your head now. By describing WHY every decision is made it is easier to make a consistant design. Furthermore, make sure not to make cyclic arguments as this is sure indicator that your design does not hold. Finally, try always to consider alternatives before deciding on something. Never take things for granted.

Try writing the design document so they can be read in-order without knowledge of text later on. This also helps to ensure that there are no cyclic arguments.

It may seem like a lot of work to write such a document, but believe be if you start code immediately you will use much more time later on fixing things that could have been done correctly from the outset.

This is just a few pointers. Read a book on software engineering to get all the details and a in-depth insigt to this subject.

I have my knowledge from university classes and from the book:
"Sommerville, Ian: Software Engineering" from Addison-Wesley, but there is a lot of books out there. You may think at first that most is just empty talk, but it really is not. If you think so, you haven''t understood it.

If you want a real word example of how a in-depth design document can be go to www.rolemaker.dk and in the navigation tree look into the documentation directory.

Jacob Marner

somehow, I feel Felonius was flaming me ? So maybe I should clarify.
I am doing a Masters in Computing, so yeah, I know a lot about engineering and doing this kind of paperwork. I just choose not to. I am not an engineer at heart.
I am an artist.
And that's a whole lot different. Now, don't get me wrong, as long as you don't do paperwork, you *ARE* an amateur, and that's exactly what I intend to be, for another long while.

felonius is right in his examples ... you hardly make anything without any planning. But you hardly ever create anything by sitting on a table, planning it. It's just a question of choice, and finding a middle of the road. My middle of the road is just much more on the creative and "do-something" side of the road than yor everyday engineer.
For your information I passed my BSc and Diploma without giving any sort of report (instead of the recommended 60 pages minimum each time), and still passed honorably (more than 60%), though the writing of a report was a good 30% of the mark... yeah, I got l33t skillZ LOL
If I had chosen to spend more time on the design, and report writing, I would probably have got *better* designed stuff done. But I wouldn't have learnt as much. Nor would I have enjoyed it. It's really a question of what better fits *you*.
Why bother writing a design doc if you fall asleep doing it ? If you are just learning bits and pieces like I do, the only thing you'll gain in doing design docs is, well, how to do them properly. I guess it's a good thing (tm).

It's just I couldn't be arsed As I said somewhere else, I don't have anything to prove to anyone except me. When I have to prove something, then I'll bend to the rules, that I know as much as you. Until then, I'll be called an amateur. I take that as a compliment.

Rather be an unproductive amateur, than a worthless corporate slave.

mmm

ps : jsut in case : Design Doc == Good Thing (tm). it's just i don't care about paper work. (it's deeper than that, actually, but if you're an engineer type, you won't get it)

Edited by - ahw on October 5, 2000 3:48:14 AM