Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Dudeldei]

Hi,

ok, so I found a subject for my game, I know the graphics type (rendered 3d) and am starting to write the design document.
I have read the Leisure Suit Larry design documents (I didn't find more)

My problem is that I don't really know how to fit the story, the puzzles, the dialogues etc. into one working logical structure.
How do I prevent chaos? how do I add systems like when you enter a location several times and you have different behaviors each time?
How do you actually structure or organize this in your design document? I mean when I program I have UML, classes etc, a visual structure, but in an adventure game?

The method I am using now is to have a sort story synopsis as guidance and then simply start writing the adventure like a story or a walkthrough. Then I intend to give it more flesh and then finally adding the puzzles or minigames or dialogue choices. Of course, if I have a direct idea for a puzzle or minigame while I am typing the story I add a note.

I would be very glad if some of the pros here (or anybody who has actually finished a working design document successfully ) would post their hints&tips or share their knowledge.

BTW I actually use Treepad for my design document. I own the Busines version but there is also a nice free version here.

[sychron]

At first glance:

http://brasslantern.org/writers/design/gdreview.html
http://inst.eecs.berkeley.edu/~cs162/sp06/design.html

The software you're actually using to write the document is irrelevant for the process of writing, it merely eases it a bit. ;-)
I prefer celtx (http//www.celtx.com), a video preproduction/scripting tool.

For structural itegrity: Just use ONE method of ordering stuff. Either by timeline, OR by locations. I prefer to reference things by location, a method derived from writing Adventures for Role Playing Games.

Something like this:

Location a

general description

IF Player has yet managed x:

special discription
i.e. "NSC 1 is available."

IF player has gathered information y:

special description
i.e. "this item is clickable"

The location descriptions are gathered in logical story chapters.
NSC's are described after all Locations

So, in general, I have the following TOC:

Title
Abstract
The Game
  Goal
  Player
  Interface
The Interface
  Interface Philosophy
  Interface Description
Chapter 1
  Location a
  Location b
  Location c
  Location d
Chapter 2
  Location e
  Location f
  Location g
Chapter 3
  Location h
  Location i
  Location j
  Location k
Chapter 4
  Location l
Characters
  NSC 1
  NSC 2
  NSC 3
  NSC 4
  NSC 5
Special Items
  Item 1
  Item 2
  Item 3
  Item 4
  Item 5
  Item 6

I could post you some examples, but as I usually write them in german language, I don't know how useful they might be.

[Dudeldei]

du wärst erstaunt wie sinnvoll das sein könnte   

ok much to read, the first link is very helpful.

Do you create the locations you would like first, or do you, like I do know, simply have a goal, a rough idea, and while you are writing the story evolves.

About the chapters, aren't chapters an ordering by time rather by location? Why didn't you make the structure

Location1
  chapter1
  chapter2

Location2
  chapter3
  chapter4

...

What are NSC's 

[sychron]

Ok, ich suche was kontextfrei verständliches raus.

Usually I come up with a plot idea. Then I evaluate this idea, look at it from different angles, including the most important: Would I like to play this plot?
Then, I set up the plot, using the w's: where, when, who, why. WHY is the most important question! If you cannot answer the WHY, your plot usually gets very thin and tends to be illogical.
If you come up with a good why, this why tends to need some story before or beside the main plot. This is how the plot idea evolves into a storyline.
Other details are added while writing the plot.

@NSC: mea culpa ... NSC is in fact a german abbreviation for NichtSpielerCharaktere, in English you call them NPC for Non Player Characters.

@Ordering: This may be useful, but normally story chapters are separated, so separating the story into chapters reduces the information load for a location in this chapter.
Remember: If you close a chapter, there is no going back. Information, Equipment and Plot can (and should!) be carried to the next chapter, but you cannot go back. So Information on what can be done in the location in a previous chapter is an "over-information", which will slow down the retrieval of relevant information.
Just think of all your chapters as separate games finished at the chapter end. So you write multiple design documents in one.

[Dudeldei]

Ok, ich suche was kontextfrei verständliches raus.

supi!

Other details are added while writing the plot.

yes that's how I do it too. It's the best way for me to make the story logical and not forced. Of course I have to edit quite a lot, so there is a chance making an error too.

Do you normally draw a map or a flowchart after you've got the plot in detail?

How do you embed the puzzles and the dialogue-trees, I mean technically in your design document?

@NSC, yes of course, I thought in english, don't ask me why I didn't do a mind translation 

@Ordering, ah yes, well I'm not sure if I want to disallow going back to the old locations, and if it's only for playing the minigames again, hmmm

[sychron]

You can allow going back to old locations. But this is independent from closing a chapter! If plot relevant things habe been done in the last chapter, they cannot be repeated ;-)

If you are preparing an adventure with more freedom for the player ("nonlinear"), be sure you know what you're doing. In this case, you can add a Section containing "generic locations to be visited independent of the current chapter".

For Dialog-Trees I use a reminder of the goof old CASL Language, which is a text language to describe text adventures. You can do them however you like, but organizing them in blocks and trees like WME does is the most comprehensive approach.

I do not draw a flowchart for the events used in the adventure. I use some other technics, like R-Maps etc, to visualize a plot, but when writing it down, this R-Maps are just a guide for the writing. I use R-Maps as quick reference when game mastering classic role playing games.

[Dudeldei]

It's still  linear adventure. I have several chapters that are be closed within. But I can return to play the minigames or ask some questions I forgot to ask for the big context.

Couldn't find any info the casl-language. Do you have any links?

With RMaps, do you mean mindmananger maps?

Do you have any examples you could show?

[sychron]

CASL is as outdated as text adventures are, we developed this in 1988. For we only spread it into mailboxes, you may find something on the usenet, but it never made it into the internet.

R-Maps are Relationship-Maps. You can misuse them to show a whole plot, if you put in plot objects and their relation to the NSC.

To your timeline: If you can go back to do minigames, just refer to the previous chapter or describe the minigames in their own mini-design-documents. But if you can go back to ask questions not asked yet, think twice: Either, you could not have asked the questions before, so the old dialogue is independent from the one described in this chapter -- or your last chapter is not closed.

[Dudeldei]

Do you have any examples for dialogues and r-maps?

Well I have two solutions, one is completing tasks and the other is gathering information. And for the latter one I intend to keep the chapters open.

[sychron]

I have to find a simple design not requiring much game system knowledge, and put it into computer readable form. I like to design RPG plots on paper ... old table gamers habbit.

[Dudeldei]

I have to find a simple design not requiring much game system knowledge, and put it into computer readable form. I like to design RPG plots on paper ... old table gamers habbit.

oh , but only if it's not too much work... (I couldn't read what I have written after a while )

[Jyujinkai]

I use a tree based document to represent sets, items, characters, story context, background infomation , notes and story.. etc etc etc (cletix)
http://www.celtx.com/

I use a fow chart to represent scene relationships and game progression.



The problems i have how to represent tree bases dialogs in a way so it can be read on paper... the dialouge scripts look like a total mess and I havn't figured out a nice neat way of representing this.

Also if you use dialouge to create game circumstance having scene discovery, item discovery, item use and dialouge discovery all represented in a single flow chart for scene progression you end up with a very messy chart... Still i see no otherway to do this?

Be interested in your solutions.

[Sally (MG)]

I use Wikipad for outlining. I'm not sure if anybody else uses it for this purpose, but I find the "wiki" interface very suitable because I can link my thoughts and dialogs from one end to the other, and have "related" topics very quickly. It's also open source so I guess some would want to modify it to suit their needs.
(yay, my first post on the Wintermute forums!)

[sychron]

Tim Schafer celebrated the tenth birthday of Grim Fandango by releasing the original Grim Fandango Puzzle Document:
http://www.doublefine.com/themes/site_themes/default/freestuff/GrimPuzzleDoc_small.pdf
Happy reading ;-)

[heribertovalle]

 A design document must always be tailored to the game. There's no template, and there shoudln't be as every design has it's own quirks, goals and challenges. But if you want to get a good headstart, do head to Al Lowe's page and download his docs. Check out some good information in Gamasutra too.