Consider this situation: One is working on their first game engine and eventual game in their basement. All by themself. This game probably will not go to market as it is a "test" game whose purpose is to increase the game programming skill of the author. Perhaps a "real" game will be developed after all the growing pains have been experienced on this "test" game. Should a formal design document be written for this project? Or is it just a waste of time in this partuicular instance? Opinions???

No, you don't have to.
But then, given that this is a learning experience, wouldn't it be a good idea to learn to do it properly. Do the doc as a learning experience too.

Quote:

Original post by Breaka Consider this situation: One is working on their first game engine and eventual game in their basement. All by themself. This game probably will not go to market as it is a "test" game whose purpose is to increase the game programming skill of the author.

Hey! That's what I do!

Quote:

Perhaps a "real" game will be developed after all the growing pains have been experienced on this "test" game.

...probably not.

IMHO, the design document is to guide others in your ideas. So that your team knows where you want the project to go. You, as the designer, should already know this, thus a design document really isn't all that necessary.

However, I do strongly recommend that you take the time and design your game. You don't have to write a full-blown design document, but map out all the classes and inter-class dependancies, all the features of the game you need (I realized one night my RPG didn't have any support for items/weapon upgrades...[bawling]). You can work fine without this step, but trust me, it will save you a whole lot of frustration with more complex projects.

No problems with Tetris or Pong sorts, though [lol]

---

Mushu - trying to help those he doesn't know, with things he doesn't know.
Why won't he just go away? An question the universe may never have an answer to...

Design document *isn't neccessary*. It is complete detailed summary of game. Most usefull before starting the project so that teams can syncronize their tasks, disccuss what is possible and what is not, etc.

For an indie developer, it isn't needed. However it is good practice to write it after project or before large scale projects (which don't happen).

Also, it is good to present your demo with document to your publisher.

Quote:

Original post by Breaka Consider this situation: One is working on their first game engine and eventual game in their basement. All by themself. This game probably will not go to market as it is a "test" game whose purpose is to increase the game programming skill of the author. Perhaps a "real" game will be developed after all the growing pains have been experienced on this "test" game. Should a formal design document be written for this project? Or is it just a waste of time in this partuicular instance? Opinions???

I think if you nail (given some changes will occur as you build) your documentation for the project before you start to build, not only will you have good production practice for professional presentation (because everyone's documentation is challenged, and if yours isn't, it's the one aspect in your job search that might stand out, not to mention you'll know more about the overall project by documenting it than just about anyone, giving you first heads up on developing changes successfully) later, and, you'll add to your own talent and luck the professional practice approach.

It will really give you a taste of what it is like from the top, too, which, in a sense, if you are going to be a game designer, you might as well start with that view early anyway. I find keeping it all in structure with documentation keeps your head above a big project, yielding adaptation fortunes.

Click has three documents that were nice to read, and here at <glint>Gamedev.net</glint>we have.

I used a couple of templates from that resource and hammered together a custom one adding integration into one CPM goal. It's an ongoing work order, but a key resource in guiding a game production process. I also use a website for updates and talk among team members.

If a project is big enough, remembering it all can be hazardous to your time and money, but for something small, I am sure you can run it all with just a few documents or less. Considering how projects can grow in size and investment unexpectedly sometimes, maybe some feature you can't leave out due to progressive competition or internal innovation, the more you are willing to put on the line for your game design goals will probably be the driver in how well you document.

It's just too advantageous not to do some core docs. Helps you get tracked in on your plan and play. I make room for a story bible, and art bible, specific sections for Gigafeature development, all kinds of attachments, powerpoint files, excel spreadsheets, word docs -- you can see that even though that is a lot, in the end it is still a finite set of fact and fiction.

I believe the adage that you can overdocument because of change, but I think you can plan your document structure for changes, and not have to compromise on feature creep or production problems of other sorts if you document structure far enough out on the curve of development, so the drilldown in doc is leading the data.

Addy

I would say that a design document is necessary, regardless of how many people are working on the project.

However, if you're working alone this does not have to be a leather bound tome with parchment pages and illuminated letters. It could just as easily be three dog-eared folders stuffed with scraps of paper and marked "Must have features", "Optional features" and "It would be cool if I could figure out how to add these".

Do some sort of documenting and record keeping/version control. Do it now, get used to it, make it a habit.

Good luck.

PS. Dan I thought you would have told him "YES, YES, YES!!"

;-)

Keeping documentation helps the creator by allowing him/her to keep their ideas on a "shelf" where they can be recalled if forgotten or changed if necessary.

Having documentation is also useful for the other members of the development team. It can server as a guide in case they get lost -- although I personally believe discussion with the writer of the document is the best method of getting more information.

It sometimes helps to have more than one person contribute to the document as well, especially considering in most cases the writer of the base document isn't in control of all aspects of creating the game. Adding new resources to the document during the development stages is a good method of keeping tabs on what milestones have been toppled.

Write down your ideas as they come to you. Once you think you have enough information to produce a solid gaming experience develop your existing ideas until you have what it takes to write a compelling Game Design Document. Make sure you remember your ideas, too -- forgetting things along the way never helps anything.

Quote:

Original post by NexusEnt Do some sort of documenting and record keeping/version control. Do it now, get used to it, make it a habit. Good luck. PS. Dan I thought you would have told him "YES, YES, YES!!" ;-)

Yup ...I have been doing informal documentation all a long. I have been using a simple exercise book. And some other random files. I have also been using version control. I swear by it.

When you get about 75% done with the game, and don't know what you're supposed to be doing next, you'll be glad you have the design doc.