Ok. So I''m sick of chasing my tail when it comes to tackling larger projects. I can''t seem to fit everything in my brain all at once (If I do this what happens to that, which changes how you do that other thing, etc...) and I inevitably get off track, lose interest, time passes, interest returns, back to programming to fix mistakes I made first time around, rinse and repeat... I need a new approach. I hear that one of the biggest mistakes that new programmers (which I reletively am) make when tackling larger projects is not having a solid design doc. So my question... Does anyone know of good templates or examples of design docs that they have used and found success with? I''ve googled (isn''t it funny how this is a verb now?) and found a few on college CS course websites--but they are all pretty different--it''s hard to tell which are good and which are crap. While we''re at it...any thoughts on design docs in genreal? Thanks.

Aye, it''s right under your nose.

http://www.gamedev.net/reference/list.asp?categoryid=23#21

;-)

DOH!
Thanks...

You don''t NECESSARILY need a design doc, if you can grow whatever you need in a step-by-step fashion.

The trick is to set very very small, incremental goals for yourself.

For example, for a 3D graphics adventure game:
First, get a window on the screen.
Second, render a flat plane with a texture on it.
Third, load and render a character on it.
Fourth, make the camera/character move when pressing keys.
Fifth, make the character animate when moving.
Sixth, swap the plane for a model of terrain.
Seventh, prevent character from running through hills.
Eigth, add a sky box.
Ninth, parse a file which loads named meshes in named positions.
Tenth, add a text overlay "console" which you can print debug statements to.
Eleventh, get a script engine from somewhere and build it.
Twelvth, allow user to type in console and show response from script engine in console.
Thirteenth, remove text file description and use script callbacks to create/place objects.
Fourteenth, add ability of entities to sense when player is near, and perform a script action trigger.
...

You may find that you have to go back and generalize code as you move forward. That''s fine; that''s known as "refactoring" and a good thing, if necessary. Once you get the hang of programming systems with bigger scale, you''ll discover ways of managing complexity in design up front that will lead to less refactoring. The Contract/Interface/Factory pattern is a favoirite of mine, for example.

Well, I started with Chris Taylor''s which is availible here at gamedev and I started making a document for my RPG.

This is what it looks like now:
http://www.dtek.chalmers.se/~srekel/real/backup/Real%20Design%20Document.shtml

However, a month ago or so I decided that the "put everything in one long document" idea wasn''t that great really, so I''ve started with a new design which I came up with myself:
http://www.dtek.chalmers.se/~srekel/real/

One of the added benifits of changing the design was that I''ve rewritten almost everything

Here are some more design documents (well, more like design ideas) I''ve made:
http://www.dtek.chalmers.se/~srekel/DesignDocs/

------------------
"Kaka e gott" - Me
Current project: An RPG with tactical, real-time combat with a realistic damage system, and randomly generated world and dialogue.