@mgoolong
I like the imagery (:

@Gnollrunner
That sounds more like it, yeah - will look into it! ?

@juliewilhelmine One of the thing is - you need general graph (generally they should be acyclic (but general might be good - i.e. including cycles in graph - for some specific cases - like a quest where you can repeatedly bring iron ore to iron smelter).

I personally made a small node editor for dialogs in Unity and then extended it to be used for quests too (eventually I'll split those). Currently it still misses quite a bit of features for my purposes - but for the current state of development it is enough. An example of how it would look in document (instead of actual files - which are binary and open-able in node and list editors - I've just grabbed a screenshot of node representation):

Upon reaching blacksmith in town and entering in conversation with player, this file is being used:

During the conversation - player can obtain the quest to get Blacksmits's hammer. The quest defined as BlacksmithHammer has this file:

BlacksmithHammer quest has the following states:

10 - Quest obtained in conversation with blacksmith
20 - Found hammer in woods, taken into inventory
21 - Found hammer in woods, destroying it before picking up -> Quest failed
30 - Returning with hammer to blacksmith and giving it to him -> Quest finished (receive reward)
31 - Returning with hammer to blacksmith but keeping it -> Quest finished (no reward)

You can add some additional lore, full dialog lines (which are in my case part of the dialog graph), and eventually scripts (which I have as a todo to link node editor to scripting … there is still possibility to add them, although by text editing at this point). The game design “document” is not a document in my case per definition, but rather a structure viewable with web browser internally on my server through web browser with data and files stored there.

The system itself allows for creation of markup documents, linking between them, attaching files (images, dialog files, quest files, etc.) to these documents - each allowing for text-based comments of users, and even allowing to mark status (in-progress, implemented, etc.). Most of the things are stored in database. It is still work in progress though, and to some extent commented to in-house tools I use. It's not in state to be presentable (it's in state of “usable”) nor released to public - not sure if it will ever be, it really is an internal tool at the end of day.

To the second question - “As many as is needed for you to tell the whole story. But not a single more.” Additional details can and should be packed into secondary quests.

What is the desired level of formality of these quest descriptions? The two obvious extremes are

• partial and/or abstract text descriptions in a design document (e.g. in the quest about catching escaped prisoners they are supposed to avoid inhabited places to minimize extraneous encounters)
• rules operating on the representation of game state during play (e.g. IF the character whose AI is being evaluated is tagged as an “escaped prisoner” THEN exclude all regions tagged “inhabited” from long-range pathfinding).

Being able to perform valuable automatic reasoning at design time (e.g. in the prisoner-catching quest, what possible but unlucky player starting locations allow the escaped prisoners to run away without the player making mistakes?) would add value if quests are complex.