It''s a little late, but what helps me write things down is by starting with what''s going to make it great. "My game is going to be awesome, and here is why."

Next, well it all depends on what''s on my head. If I have a scene in mind, I try to scrawl it down while the inspiration''s there. Then look at it. What does each part mean? If I have a few elements in mind, I figure out what each of those mean.

The nice thing is that, typically everything attaches to everything else. If I can pick locks, that lets me know there are doors, and chests for the locks to be on. Similarly, those have some implications as well. Chests == stuff. Doors == walls and rooms. It''s looking sorta like a dungeon crawl.

From there, it''s usually tracing out each idea a little, Once I''ve got a little mess of stuff down, and I know what''s important, I try to divide things into general sections.

Gameplay (subsections: Actions, Controls, Rewards)
Enviroments
Characters (computer controlled, player controlled)
AI (Both for enviroments, game files, and computer units)
Equipment
Story
Actual Content (maps, pictures, weapon stats, etc)

Of course, the sectionds do depend on what''s being done, but that might be a helpful guideline.

Hope this helped you a little. IF there''s anything else I can do or explain, just say.

well there is something you can explain...

im not quite sure what to put in the A.I section, i know its about A.I. but my mind just goes blank when i think of what to put in there

"Those who serve no purpose, have no purpose. SSC the Super Saiyan Cat"

I didnt read all the messages. I just want to say someting about this. I think first you must clear the all dark places in your mind and then start to write it down. First let you r ideas fly in your mind. Let them go, and let them conquer new countries. Then put them together and write them down. I dont think the format of the documantation is very important. But I prefer clear and short definitions on paper. Hundreds pages of documentation is frusturating.
Shortly:
Imagine first. Dont hurry to write it down(believe me you wont lost any part of your ideas). Let them grow up. Then split them to paper when its time...

-------------------------
Hakan Yuksel
3TE Games

Hi there,
I think I might be of some help, if you mean what I think you mean... One of the major aspects of the course I am on at the moment is design documentation and learning how to plan out poorly defined/well defined projects before coding them (which is something I''m doing right now- writing a program based on design docmentation..). After youve scribbled down your ideas for your game or whatever, you then need to give it some structure, decide what functions it will need to perform, how it will interact with users etc. This is easily the most boring aspect of programming, but although I hate it, I recognise that it REALLY DOES help you write more robust programs. Methods of planning include SSADM, UML (urgh!), State diagrams, event traces, data flow diagrams, object modeling, etc etc. The list goes on. There are many books on the subject and I''m sure you''ll be able to find stuff online about it, just use whatever methodology you prefer.
On the other hand, if you meant you had problems writing down the raw ideas- it might help to close your eyes and imagine what the screen in front of will look like when your game is running?
Jon


In OOP no one can hear you scream..

This thread is too long. =)

Anyway, If you want some help, try this:

Grab paper and write down the following:

**
MAIN CHARACTERS:
MAIN SETTING:
TERTIARY CHARACTERS:
TERTIARY SETTINGS:
PROBLEM 1:
P1 POSSIBLE SOLUTIONS:
etc.

**

That''s how I, personally start, but you probably don''t want to do that... Anyway, I think I have to opposite of your problem: I can write everything down; Documentation, source code; But I can''t seem to type it all in a compiler... Even if it''s allready laid out for me!

Need more coffee, and can''t find me axe,
~Dwarf

poor dwarf

i finally put down all my ideas on paper( no design doc)
maybe i can just work from that

"Those who serve no purpose, have no purpose."- SSC the Super Saiyan Cat

Edited By - SonShadowCat on Your Girlfriends Birthday

can anyone show a skelital figure of what the layout is?

for example"
character:
how he controls,
what he has in abilities,
who he is,
etc..

stage:
where it takes place
how it looks
how u move around
etc..

is their a more planed out way? than guessing it all?

like a tree chart maybe?

I saw Taxi Driver last night at home. You know, with Robert DeNiro and Harvey Keitel-- among others. I''d never seen it before, but I guess the video was a special edition and it had a behind-the-scenes look afterward. Showed Robert DeNiro and Scorsese, all them, talking about the movie, which was, to say the least, weird.

Anyway, it also showed someone from the crew talking about Scorsese''s storyboards for the movie; said that, though this is hard to explain, storyboards should show no artistic value. They should not be good. I understood right there. It showed his storyboards-- looked more like child''s drawings. They had the stick figures and the arrows pointing everywhere, a lot of notes around the pictures, captions, blood and details were done in marker-- very sketchy, but they were very to the point, know what I mean?

There was one scene from the movie that had Robert DeNiro busting into a pimp house and violently killing everyone inside but a young girl he knew there. She was very young, and had run away and become a prostitute. He was here to save her. Well, there is one shot w/ DeNiro sitting down looking at some cops across the room; it shows his face, smiling; he holds his bloody hand up to his head like a gun, pulls an imaginery trigger... makes quiet gunshot sounds with his mouth.

The storyboard showed this shot perfectly. Just a stick figure sitting down with his hand against his head, very simple. But it was subtle, had the blood dripping slowly from his finger as he pointed. Very creepy.

After all, it was a creepy movie.

--

This was an inspirational moment for me. I woke up the next morning and had to get some paper. Started up a website for Jedi Knight mod-making, which I''m interested in, and had an idea start in my head of a mod of my own. I took out that paper and a pencil, quickly and briskly sketched down the beginning scene and shot for the start of the new level. I also began drawing some characters in my head, just anything. It all came clear.

I decided that morning that I''m a natural at game design. It was all coming clear. Characters, ideas-- shots. I could draw all the shots from the level from the player''s perspective in a very quick and easy fashion. I could move very quickly through the level. And I could look into the game from a very cool perspective-- mine and yours. =)

So, what does this have to do with you? Well, look at what I''ve said. Storyboard everything. Draw everything from the top of your head. Anything. Draw first. Write notes second.

Think later. And draw.

Here's my "buck and a quarter":

First thing first:

Game Concept Design and Software Architecture Design are two entirely different concepts that are tightly coupled and for the sake of your own sanity and that of your programmer you should treat them as such. They each deserve their own documentation and their own development life cycles.

There are several stages to the software creation process. This means that both your concept design period and your architecture design period should take place in parallel stages of ever-increasing complexity based upon previous design criteria (As in, you wouldn't code you collision detection algorithms before you decided upon the dimensions of the game.)

Sometimes the game concept design will place criteria upon the architecture design and sometimes the architecture design will mandate that certain design concepts can-not be entertained.

While it is possible and 'OK' to develop the architecture after the concept design process is finished, it is, in my opinion valuable to do them in parellel. In this way software designers can make sure that concept design doesn't get too ludicrous in their vision (as in, an idea so bizarre as to be impossible to code,) or too far in their mechanics document, possibly requiring discardment of work.

Concept Design Process & Documents
1.Game Overview Document
2.Game Concept Document
3.Game Mechanics Document

Software Architecture Design Process
1.Requirement gathering/analysis
2.Infrastructure/Module interaction Design
3.Module Specific Design

First and foremost a concept designer MUST think realistically. Can this be done? What is my schedule? Always think about your schedule and determine if your feature set is realistic. What is the basic set of functionality that this game can support to make sure it can be delivered.

As a professional programmer I can tell you that "feature creap" can be the most dangerous aspect of development and is the most risky aspect as well. By the time the coders start doing their Module specific design a concept designer should not be making any large changes to the concept document. Mechanics document changes are ok, but the more features you tack on late in the design process, or god forbid the coding process, the more nails you pound into the coffin lid.

If nothing else this following bit should help you get some of your ideas on paper. In your concept document just state what the game is going to be, how it will play, what it will look like, etc. This is a very high-level view of the concept design.

In the concept design document the first thing you NEED to do is create an OUTLINE. An honest to god outline which bullets and numbers the different topics of the game. Put all of the major concept ideas in there and organize them. Here is an example:

  Introduction:Player Info: 	User Data:	Account Info: 	Character Name:Game Concepts: 	Character:		Class:			Fighter:			Wizard:			Theif:			Barrel Maker:		Attributes:			Strength:			Dexterity:			Intelligence:		Skills:			Actions based on skills:			Awarding Skill Points:			Skill Bonuses:				Racial Bonuses:				Environment Bonuses:				Class Bonuses:			Skill List:				Basket Weaving:				Fletchery:				Moose Handling:		Demographics:	Race Factors:		Races:			Elf:			Dwarf:			Halfling:			Human:			Troglodyte:		Racial Bonuses:		Racial Attribute Modifiers:	Fighting:		Initiative:		Defense:		Attacking:		Weapons:			Ranged Weapons:				Bow:				Sling:			Melee Weapons:				Slashing Weapons:				Bludgeoning Weapons:			Damage Computation:			Weapon Modifiers:	Movement:User Interface:	2D:	Main Windows:	Sub Windows:etc.....  

Then what you do is write small descriptive bits about every topic. You don't have to go into too great of detail yet. You just want to describe how things work and how the topics interact.

You can cross reference information with other elements on the list. The ordering of the info is up to you. Every time you come up with a new idea it should have a header. The introduction alone will get very large, but that is ok. It works great to do the introduction be an html document and have each topic reference a specific point in the target html document. You can also use a table of context in MS Word or similar products.

Finally the mechanics document is started once you have some solid ideas about the concept design. Don't get too eager to start this document because this is where you will write down specific values like how much damage a specific weapon does, how far a specific weapon can shoot, exaxt racial attribute modifier tables. Many of these may change as play balancers attempt to balance the game.

Well enough of my rambling.

Too long as usual,
RandomTask

Edited by - RandomTask on January 29, 2002 12:29:48 PM

Edited by - RandomTask on January 29, 2002 12:31:47 PM

I''m not to the point where I can actually implement any of my ideas into programs yet (just starting out) but i''ve been writing scripts and comics and the like for years. What helps me is this: I wrote the extreme basics down on what type of game I want to make. For me, that''s the deciding factor on what the basic layout for the story and how it will be portrayed to the player. Then i get down to designing the main characters who will move it along, along with the major plot points, etc. When i''m finished with this, I have a very bare bones skeletal treatment of what''s going to take place if the player moved straight through the game at breakneck speeds. Depending on the game, i''ll go deeper into detail and design the locales, items, and dialog so it resembles a basic script of a movie. Then I story board the whole thing, with camera angles and special effects and whatnot. Good graphics, bad graphics, it''s all the same to me, I have to mentally be drawn into the story to enjoy the game. I think of it all as a giant choose your own adventure comic book. To me, designing it is the most fun part, I can''t wait until I can finally start coding. Rambling aside, I treat all my game design docs as a giant storyboarded choose your own adventure book. (if player does this, move to this panel, etc.) I try to make stories that branch out giving replay and maybe different outcomes.