Archived

This topic is now archived and is closed to further replies.

Writing the Design

This topic is 5328 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
quote:
Original post by ahw
somehow, I feel Felonius was flaming me ? So maybe I should clarify.



No flaming intended ahw. It was more a general thing. But the new posting you made makes me think that you should know better and that actually gives me reason to flame you. So here goes... :-)

As said to DarkAngel16 notes is fine, but only if the project is small and you are alone. But if you are going to be amateur all life (and poor without a job?) then your solution is ok.

But someday you must have food on your table and become a "corporate slave". Even if you make your own company you have to compromise with other people and actual work together them and have to do with management.

In all types of educations/jobs there are good and bad people. There are good and bad lawyers. There are good and bad mediacal doctors. Good and made administrators. Politicians. And so on. Unfortunately it is all the bad ones that give them a bad reputation.

It is the same with Computer Scientists. The bad ones are those that fail all the large projects and give us bad reputation. If you choose to be an "amateur" in a professional job and mess things up because you don''t plan properly then you become one of the bad computer scientists.

But why, I ask, why choose the way to failure? I simply can''t understand why you would choose to be an amateur would you could work prefessionally. It is only because there is so large a lack of IT-professional that the employers can accept this.

Image an engineer building a bridge, but he really likes doing the drawing stuff and not the thing about examining the underground so he skips that - because he is an "amateur" by choice. When the bridge is done they find out it is built on a chalky underground and might not be stable. Who is blamed? The engineer. Because he chose to be stupid. In software development projects are cancelled for this reason - how fun is that?

Someday ahw you will leave the protective confines of college/uni and will have to work TOGETHER with other people (Oh No!) and you just can''t code it all yourself or everything will be a giant mess as it is many places where amateurs are in charge.

But of course, if you only intend to be a amateur programmer without a job, or doing small jobs, or being part of a messy team, then who cares? I just hope that I don''t know the client (or producer) that hire you for building products.

Sorry for the flame, but it really annoys me when people with education says as you do.

Jacob Marner

Share this post


Link to post
Share on other sites
felonius, you are the voice of reason, man (no sarcasm intended).
The thing is just that I prefer to learn and teach rather than work as in ''be professional''. It''s purely a matter of personal taste. You take the serious engineer goal, and I do the creative stuff. you go check the underground (which I know has to be checked), and I go crazy designing a cool shape for the bridge
Necessary evil

youpla :-P

Share this post


Link to post
Share on other sites
quote:
Original post by ahw
felonius, you are the voice of reason, man (no sarcasm intended).
The thing is just that I prefer to learn and teach rather than work as in ''be professional''. It''s purely a matter of personal taste. You take the serious engineer goal, and I do the creative stuff. you go check the underground (which I know has to be checked), and I go crazy designing a cool shape for the bridge
Necessary evil



Well, as a matter of personal taste I can''t say I don''t understand you. After all, it is the most fun to do fun things all the time. If it was up to me I would think about game ideas all day and make other people realize it, but ufortunately that is not a choice I have.

I have just worked on so many projects that ended after the idea phase and just stopped there because nobody really wanted to use the energy to realize them. Or because people began to fantasize about other games or was wildly ambitious. Coming up with game ideas is fun while realizing them is hard work (and not so fun), but when this has happened enough times - it it has for me - you really get depressed and just want to really see a project get be completed. This time I am doing it the "right" way and project is really better than anything else I have ever made and has reached a far further state than anything I have ever made.

So the conclusion I have made is that those Software engineering books are right and that I simply have to live with those ways of doing things if I want to get results - and in my actually getting to make the final product is really a priority. It is fun to think about games, but actually completing a real one is so much more satisfying (I hope :-) ).

Jacob Marner

Share this post


Link to post
Share on other sites
Ah yes, I have to support you on that one. People, read the Software Engineering stuff if you have a course on it. It *seems* to suck a lot when you read it first, but it''s DAMN useful in any industry type work. If you ever want to work in the industry, knowing software engineering is a plus.
I''ve been there, and done that, and it wasn''t very nice to see
Actually, don''t jsut drop some topic if you really intend to work in computing. It''s not that easy to know what you''ll need when you get there, so you''re better off learning a bit of everything. I learnt Soft.Engin. A year after I needed it, and I can tell you I LMAO when I realised how things might have turned if I knew all the techniques (but then again, if I had known the techniques, I''ll probably be a respectable network engineer by now, and that sucks ...)

Now you see felonius, that''s why I like teamwork more and more, I get to do the fun part, and I motivate the hard workers like you. I did that for most of the team projects I had for school (actually, I ended up doing the code as well most of the time...), and it''s nice. Now I would love to do it for a game. I am just waiting for the right people, it''s a long process, but I am confident it will happen. Patience is a virtue, in the meantime, I''ll do a nice Masters on game AI (''jeez, I even convinced the board that this was a good subject!), learn stuff, and have a lot of fun at school (that''s what school is for, learn and have fun, isn''t it ?)

youpla :-P

Share this post


Link to post
Share on other sites
quote:
Original post by ahw
Actually, don''t jsut drop some topic if you really intend to work in computing. It''s not that easy to know what you''ll need when you get there, so you''re better off learning a bit of everything. I learnt Soft.Engin. A year after I needed it, and I can tell you I LMAO when I realised how things might have turned if I knew all the techniques (but then again, if I had known the techniques, I''ll probably be a respectable network engineer by now, and that sucks ...)



I am learning bit of everything. But there is so much to learn. *sigh*.

If you had learnt Soft.Eng. before you needed you would probably have thought it to be nonsense. You must have tried and failed in projects a appreciate it.

quote:

Now you see felonius, that''s why I like teamwork more and more, I get to do the fun part, and I motivate the hard workers like you.



If you can get a job like that I think you are lucky. I would like that too but I really do not think it is realistic. If you are part of a team the other members expect the same of you as they do themselves. If they code - you code.

To motivate people at tell what they should do, you really need design docs. Don''t expect the ideas in your head magically to be trnasferred to their heads. It isn''t possible just to say it. Teams need reference material that they can look up in when in doubt.

[qoute]
I''ll do a nice Masters on game AI (''jeez, I even convinced the board that this was a good subject!), learn stuff, and have a lot of fun at school (that''s what school is for, learn and have fun, isn''t it ?)


It is really surprising how games are being accepted in the academic word these years. I am writing an authroing system for Computer Role Playing Games as my Master''s thesis. My professor is into RPGs and games himself and the censor is a developer at a local game developer. You can see the work in progress at www.rolemaker.dk. I think it is great that this kind of work is possible. Good luck with your project.

Jacob Marner

Share this post


Link to post
Share on other sites
Not that this is important to anyone, but whenever I design a game there is a process I go through. It is as follows.

-After breaking out MS word 97 I start brainstorming. I type out idea after idea. Anything that I can come up with. There is no set order to this. All the ideas don't even have to fit together, but the process usually starts because a specific concept has hit me like a brick.

-After that I start organizing as many of the ideas that can into a whole. Molding ideas into a game that would appear to be fun to play. All of this with out regard for what is possible technically!

-Once that has happened I develop the overall concept and prepare the Treatment.doc (things like story, plot, main characters, basic game play, etc...)

-Next is the Design.doc (anything and everything that is planned for the game. Including a design strategy that allows for extensiblity and change).

-Finally the Technical Design.doc (lots of psuedo-code and architectual design of all techincal components and underlying structure for the mechanics of the game)

Note: I never start the actual development process until all of this is down on paper and the team is on the same page. Hope this helps...

Nathan Dumont
Game designer/Project lead
Cerebrum Software
www.cerebrumsoftware.com -please excuse the site. It's being re-designed.

Edited by - Nathan D on October 5, 2000 1:56:19 PM

Share this post


Link to post
Share on other sites
What I do is very similar to what Nathan D does. I open up Word pad and type a list of the features that I want to implement first. Then when I design the code and the architecture, I write down everything that was going on in my mind at the time. Writing down why you chose to do something is very important. I always ask myself, why did I decide on this? What was I on? All I have to look at the code design doc and there it is.

Share this post


Link to post
Share on other sites
One thing to note. I don''t plan out the story or the plot for the game, someone else does it for me. I just design the technical stuff (how the code is organized and how it works). I don''t even design the interface. This adds responsibilty to the guy that does design it, because if it is not thorough enough, it makes it very difficult to do what I do.

Domini
Rastagon 2 Engine

Share this post


Link to post
Share on other sites
quote:
- 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.




As if the number of pages has anything to do with it. Better quality and short. If you can write a design document in 15 pages I''d be impressed. I feel sorry for the people that need to read your 300 page novel, I bet it''s a bestseller. wink.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Just a passing reply. Duke Nukem 3D and Unreal Tournament were created with no design document. Not to say if you don''t write one, you''ll succeed like they did, but by the same token, not writing one doesn''t necessarily make you an amateur.

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster

Just a passing reply. Duke Nukem 3D and Unreal Tournament were created with no design document. Not to say if you don''t write one, you''ll succeed like they did, but by the same token, not writing one doesn''t necessarily make you an amateur.



Do you have a source on this? I find it very hard to believe that they had no design document. When you are working by yourself a design document is good but when you are on a team it is critical. Even if it just a list of specs that everybody has to follow.


--------
Andrew

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
"Just a passing reply. Duke Nukem 3D and Unreal Tournament were created with no design document. Not to say if you don''t write one, you''ll succeed like they did, but by the same token, not writing one doesn''t necessarily make you an amateur."


sources:

Duke Nukem 3D - Game Design : Secrets of the Sages

Unreal Tournament - Game Developer Magazine

Share this post


Link to post
Share on other sites
Duke Nukem 3d and Unreal tournament SHOW that they did not have design docs. These games do not feel terribly unified, Nukem is a pile of purile drivel and UT is a disjointed (though somewhat entertaining) amalgam of random experiences that show off the game engine.

Needless to say, the lack of unity and purpose is the foremost reason that MOST gamers can''t play these games for extended periods without being bored to tears.

Share this post


Link to post
Share on other sites