Yeah, okay, umm, I never EVER said the design doc was about story. I''m not an idiot. The SCRIPT (as in dialog and scene description, no scripting) is about story, and the design doc contains the script.

Fer, please stop confusing me with a militant writer. I''m not even a writer. I completely understand that a wide variety of people are needed to make a game, I''m the person who finds those people.

Anyway, Wav, and everyone, you''re right, I am way underinformed to say anything in this forum. This is turning into a design discussion, and mind you one of the design discussions I usually avoid. Shall I move it?

Felonius, you obviously missed the anonymous post giving you both sources proving that the designers of both Duke3D and Unreal Tournament did not use design documents when making their respective games. I can confirm both sources Anon listed, because I happen to have both of them. (I will add that 3D Realms laid out the cinematics for Duke3D on paper before they made them, but this does not constitute a game design doc.)

No, a design document most certainly is not conclusive to a good game, and a good game most certainly does not require a design document. Both of the affore-mentioned games are excellent proof of this.

Landfish: Script does not constitute an entire design document. I agree that a game's script will suffer immensely unless you write it out and spend lots of time tweaking it, unless you're a superhuman journalist. Still, this is only part of your overall design document.

There are as many processes to game design as there are designers. Any professional in the industry will tell you this. For example, about half of my design docs are actual text, and the rest is pictures that I draw to exemplify my ideas. Personally, I think that's the best kind of design doc, and I'm sure a lot of people do this.

Design docs contain just as much information on interface and game mechanics as they do on the story. If you can envision your ideas clearly and share them such as anyone can understand how you want the finished product to look and play, then there's absolutely no need for a technical design document. You can get away with writing just the story.

And, of course, if your game doesn't have a solid story, then you don't need a design document at all. I'm not afraid to say that Felonius's original claim was very prejudgmental.

Edited by - Tom on October 9, 2000 11:25:58 PM

actually .. did you know that there was a pre version of DukeNukem done before the one released on the market ? THere was a jumpack with a massive trail, a cool laser marker, and other weird stuff ... it looked much much more amateurish than the final version. (I dunno, all this discussion jsut reminded me of that ...)
I think it''s somewhere on a demo CD, wish I could find it again.

youpla :-P

If you want to see some good examples of design doc's browse around the Digipen student project pages. Every time I do it inspires me to write a design document. Imagine haveing a reference book to make the game of your dreams and it is the game of your dreams because you wrote it and every step to creating it is detailed in that doc. Even if you dont get around to making the game, at least you'll have it with you in the years to come so you can make it at a later date.

Edited by - ironside on October 14, 2000 2:42:44 PM

Edited by - Ironside on October 14, 2000 2:43:38 PM

I''ve dropped too many projects cause they just got so disorganized I couldn''t handle them anymore. Always make a design document, even for simple games. I think it makes it faster and easier to program.

==============================
"Need more eeenput..."

- #5, "Short Circuit"
==============================

Keep in mind, too, that (1) there were already 2 Duke Nukem games out before DN3D was released; the character and theme had already been created, it was just a matter of writing up a Doom-clone game engine (which was done very nicely, considering all the "special effects" DN3D had that Doom did not). Not to mention that there was not really a large team of developers working on that project.

And (2) UT was written by the same group that did Unreal... I assume they used a modified Unreal engine (sorry, can''t back this up, but it makes sense that this is the case); there''s no plot in UT. So was a design document really even necessary?

Now if you were to claim that games like Baldur''s Gate or Ultima IX were created without design docs, I would have a harder time believing those statements, simply because those games are so huge. But then, there''s a *little* bit of a difference between those types of games, and the ones mentioned above.

As for myself, I wrote up a long design document about what features I want the game engine to support. And I work out "version feature lists" so that I know exactly what I''m working toward with each minor version of the game. (Currently, v0.01 will have very basic features that simply ''make it work''). And I will slowly work up to 1.00 which will be the final release. I know at some time I will have to take a step back and really write a long authoritative technical document, but that time is not yet, and no way in hell will anyone coerce me to do so prematurely, simply because there''s no point yet! 8)


MatrixCubed

(Take a look at the date this started, it lives again!)

Design Doco''s are extremly important. My first project had a very small amount of design. I had a folder with various sketches, notes and a few pages of general design

The result, the project went under. Now I''m properly planning everything. I''ve written down the overall feel and look of the rooms so that each locations are graphically correct and in the same vien. I''m writting NS diagrams and such so that when it comes to the actually coding, I will know EXACTLY what to do. Never underestimate being prepared.

Kyle Evans,
Artificial entertainment [Movie/Game Reviews]- Define reality...
Contact: kyser3152@yahoo.com.au

I agree that documentation is important for larger projects, but if you''re struggling with getting something down on paper then just start coding, sometimes it''s easier to translate something that''s inside your head directly to code than to translate it into class diagrams, specifications etc. But here comes the important part: What has been coded like that should *not* go directly into the implementation, instead it should be considered a proof of concept prototype, helping you understand better what it really is you want ...and what you need considering before you can create what you want, you learn a lot from what''s wrong in the prototype, than from what''s right. And then it''s back to the drawingboard again, document what you have learned, make the design clean and try to find solutions for what isn''t working right. I use this method all of the time, if you do all designing on paper before implementing then you will always discover details in the design that won''t work "in the real world".

Example: You wanna make a game, hm... what kind of game, you don''t really know.. maybe a 2d adventure game.. yeah something like that Ok.. you don''t know what you want, so start coding! Make a 2d graphics engine prototype, make it work, take notice of all of the difficulties you have, and most important: When you''re coding the graphics engine, and see it working, then all of a sudden you might just get ideas for the overall design/goals of your game, write those down ..fast, pen and paper, no computer..

***
For Java games and Java related resources, go to http://www.javaengines.dk
***