Ok this is the question. How should a design document for a RPG be written. Lets say theres a character, a monster, a weapon, an armor piece, a healing potion, a key that opens the door to win the game, and the plot is you wake up in the room and you must kill the guard to get the key to get out or choose to play a game of poker with the guard to win the key. simple right? well i have no idea where to start especially on things like choices the character makes main plot------>more plot | / \ choice one---/ \---choice two | | more plot- -more plot \-main plot-/ | choice two----more plot----choice one and on down how do you describe a story like that in a design document with enough detail to give the developers a good idea clearly? ------------------------------ I shall fart in your general direction. - I said so ------------------------------

Wrong approach. Every RPG should have an overarching story even if it''s very nonlinear (even Morrowwind has such a thing). Write that first, in a standard, linear format but without getting into much detail. Then individual choices can be mapped out via flowcharts and that sort of thing.

However if you are speaking of a dynamic, overrarching story in the RPG, then you could have some difficulties (e.g. the plot changes based on choices and any number of combinations are possible)

Of course this would be incredibly difficult to implement in gameplay anyway.

Thats what the game is about. The ability to affect the way the game is played from the users standpoint based on choices you make along the way. However that isnt the hard part. The really hard part is going from my brain to paper. If anyone can take the example i gave and put it into a descent readable design doc i would be grateful OOOOORRRRR you could point me to some descent and in depht tutorials on design docs for game/rpgs. The docs in gamedev.net are NOT helping me any. thanks

------------------------------
I shall fart in your general direction. - I said so
------------------------------

the correct way is the one that links your ideas in a logical and complete way, whatever is easiest to read, write and tweak is the best.

personally, i do my logical organisation in typed files after madly scribbling incoherent ideas on paper. it works for me because i can sort bare ideas according to line-of-thought on paper while sorting complete ideas according to how they will work together in the game.

i have a similar branching structure, it is simplified by saying that there is one coherent world and story of which the player experiences various parts. the variations in path can be written in a script or tree-like way whereas the overall game environment gets the plot details (which are fundamentally seperated from game flow)

********


A Problem Worthy of Attack
Proves It''s Worth by Fighting Back

The way I am creating the design doc for my game, NightRise, is to go into more detail about game mechanics than about plot. A basic outline of the plot is good, but what''s more important is for whoever reads the document do know how the game is played. For example, in my game, in battle, spells are cast using the keypad numbers, and items are used using the keyboard numbers. Left clicking the mouse will attack while right clicking can be used to perform special attacks. Go into detail about what the play mechanics are. How does the battle engine work? Who are the characters? What weapons do they carry? What is there lifestyle? What are their good and bad attributes? What kinds of weapons are there in the game? How does the battle engine work? Etc. etc. Plot is important but a publisher isn''t interested in reading a 200 page story. Sum the plot up in a page at the beginning of the doc then go into more important details like play mechanics, graphics, and sound. At the end, maybe, you can write out the entire plot but only at the end. If the publisher reads the doc first and you start with the plot, they may become bored and not even play the game.

However, if you''re worried about forgetting the plot, start writing the dialogue script. This way you can develop the plot in a document you can keep to yourself. Afterward you can put the plot into the design document.

Well, those are my suggestions. Hope they helped.

I dont think you guys are understanding my problem. I understand your points however my question remains unanswered. My question was basically what is the format for the basic rpg. Is it something like this?

Mechanics
Plot
characters
Items
Weapons
Monsters

If thats correct then how do I go about designing the characters without designing weapons and I cant design the weapons without knowing the stats of the game (mechanics) and I cant design most of the plot without doing the monsters and items. HELP.


------------------------------
I shall fart in your general direction. - I said so
------------------------------

I think I had the same problem when I started.You want to find a concrete sure fire template to design your game around.But the problem is that there really isn''t one.You can ask a thousand different people here what they do and each of them will give you a different answer.But that''s not necessarily a bad thing having a flexible basis means that you can add on and take away from what you learn from others and create something completely your own that works with your writing style.

What I did was look at others design documents(some people do have theirs on site).Find a basic structure that I think I can live with and start writing.If I run into a snag here and there ,if it''s not as in depth as I want I add categories.If it ask too many questions in another area I take out those that are irrelevant to my project.

The road to hell is paved in good intentions