I was asked a question by a friend, the question was "Is there any software available that enables the user to write up dialogue in some kind of chart, making it easier to follow and easier to write in rather than just writting it in word" I was just wondering if theres any software that does this? At the moment hes handling it as Mr A: " Hello Blah Blah Blah" Mr B: "Ahhh! Blah blah" Choice A: "Yes I agree" Choice B: "No I don't agree" Choice C: "Goodbye" A Response Mr B: "Blurgh blurgh" Choice AA: MR A: "Hmmmmm" Choice AB: Mr A: "I agree again" B Response Mr B: "You don't agree?" Choice BA: Mr A: "No I dont agree" Choice BB: Mr A: "Ok, I agree" C Response Mr B: "Farewell!" End Convo Sorry for going on abit there, but I was simply demenstrating how confusing it will eventually get going through the different paths of dialogue options and actions etc. So just wondering if theres any software out there that makes this easier? Thank you for your time.

Thanks for the help, I word is sufficiant, just with gets annoying drawing flow charts after awhile :) nice to have something that does it for you and is built for dialogue planning.

Although I will check out some of the software you guys have mentioned and also will be interesting to view your Java program 5MinuteGaming.
Good luck with that

Thanks

I'm not sure if it will help, but TreePad allows you to write documents in a tree structure with editable "nodes" and export them in various formats.

Freeware and trial versions are available.

Maple is a similar product, but there is no freeware version available (although there are trial versions).

is this what you mean? because it shouldn't be hard to write something similar utilising xml.


EDIT: you can't use an img src tag to show a webpage

[Edited by - sunandshadow on June 13, 2005 5:06:29 PM]

I have been doing something that sounds like what 5MG is doing. The resulting structure is not a tree and it handles variables, choices, and transitions. You can run an interactive story using it.

It is not designed to handle dialogues but for prototyping plot elements, but there is not much difference. It doesn't seem hard to write.

I am wondering is there any benchmark story that I can use to evaluate the flexibility of my system. If not, maybe we can create a benchmark so to compare the design tools.

[Edited by - Estok on June 13, 2005 7:26:12 PM]

Re: 5MG

I used VBA in Excel, because I was just adding functions to the flowchart capability. This is a screenshot. I don't know whether I can upload the .xls because I am don't have permission to show the content used in the prototype. That was why I was wondering whether there is some kind of benchmark story I can use to determine what fundamental features are missing before I use that tool to map Cryo.



DATA STRUCTURE

Node - Every box is a node. Each node contains:

- A summary: such that when the box is clicked the description is displayed (to save space)

- Extended description: for the designer to write whatever and put extended notes related to the node.

- Story Text: the text that is displayed to the player for that node. Variables used in the story text are replaced by their values when they are displayed.

- Image: 1 image for the sake of having it

- AutoNode Flag: A boolean that determines whether the node will automatically transit to its next node when entered. AutoNodes are used to implement processing units and functions graphically.

- Entrance Rule: The Rule (a boolean function that accepts variables) that determines whether the node can be entered in situations where the node can be entered from multiple previous nodes.

- Choices: 4 choices per node (for simplicity) Each choices have the following fields: Lnk, Text, Rule, and two Transition Effects.


Choice

- Choice Lnk: The field that contains the next node of the selected choice. This field accepts variables and functions. (i.e. clicking on the same choice does not mean going to the same next node.) Two major functions for this field are "RET" and "TAJ". "RET" is the function that allows the node to transite to the top node of the return stack. "RET" is the basic requirement of modular implementation. "TAJ" (Test and Jump) is the function that allows the node to evaluate the Entrance Rules of a list of fanout nodes and select the first viable next node. "TAJ" is not a requirement because it can be equivalently implemented using AutoNodes, but it is convenient for situations when the fanout is high. For example, when you 'enter an inn', the inn can be in many states, and TAJ serves as the switch-case block to determine which state of the inn is entered.

- Choice Text: The text that is displayed to the player. Variables within this field are replaced by their values. (i.e. The same node may look very different depending on the values of the variables.

- Choice Rule: The perliminary rule that determines whether a choice is enabled. The rule accepts variables and function calls. When a choice is disabled, it is shown to the player in parenthesses and cannot be click on.

- Choice Transition Rules: The effects that the choice will induce when the choice is selected. The EffectVar field holds the variable being changed, and the Effect field holds the new value that accepts variables and function calls. A Transition Effect can be just a subroutine call without any return variable. Each Choice has two transition rules. For choices that induce more than two changes you can implemented the changes using a subroutine. When a Node is used as an AutoNode, all 4x2 effect slots are used.


IMPLEMENTED FEATURES:
(starting from the most crucial features)

1) Visual representation: Allows you to see the nodes and the relation among them visually. This is the single most important feature in my opinion. If it is not graphical it will be unmanageable. The current implementation kidnaps whatever excel already has, so you can draw arrows, change color, change shapes, etc for free. On top of that I skipped writing the code to save and load the graphical representation to and from files. Since this part of visualization obviously has nothing to do with the actual engine that runs the game.

2) Variables, Simulation, and run-time editing: Allow you to declare simple variables, and that all the variables are displayed all the time (on the 'RAM' sheet). Allows the designer to step through the story as if he is playing the game. This and variable are second most important features. There is nothing to simulate without variables and nothing to verify the variables without simulation. Allowing the variables and structures to be editable during run-time also saves a lot time. The data structures variables are accessible any time on the 'ROM' and 'RAM' sheets.

3) Scripted functions: Each node is capable of having its own rules and calculations. If this is implemented in normal language, this correspond to implementing a parser and the corresponding library of functions. Designing, editing, interpreting, and running scripts can be a large part of the programming. I skipped all of these because I didn't know exactly what kind of data structure I need. The way I am doing now allows me to change the data structure and functions pretty easily.

4) Modulization and Return Stack: allows the nodes to be grouped by functionality and be transited to for multiple times. This is the fourth major feature that allows the design to break away from the branching tree and flowchart implementations.

5) Queues, Lists, and high-fanout nodes: More data structures to implement 'visited list', 'priority list', 'schedules', 'timelines', and 'possible transitions'.

6) Processing Nodes (AutoNodes): overloaded fancy implementations to implement functions visually (i.e. don't need to go to the 'code' to implement functions. The 'code blocks' are graphically represented.)

7) Story Text with variables and Text composition: Allow the text to have variables and uses the autonodes to compose a page of text before it is displayed. This avoids the situation where each node only display a small amount of text and the player has to click every line. Allows more reuse of nodes (to reduce the number of nodes)

8) Renaming variable names: This is kind of important, and since the data are all laid out, to rename a variable all I need to do is to click on replace all, and it changes all the references to the variable.


More about the screenshot:

Near the upper left there is map of the game world drawn in boxes. Due to the limitation that each node only has 4 choices, each box there touch at most 4 other boxes. Each transition from a yellow box to a green box is a multi-fanout transition. This is the situation where, when LittleRedRidingHood enter the Inn, there is a list of events that can happen, and the engine chooses one of the events (or a series of events by enqueuing the events) to present.

Near the middle there is the group of boxes where one of them is named 'heartbeat'. It is the representation of the normal ProcessIdle function that advances the states of the NPCs. All transition of time are linked to the Heartbeat module, which determines whether an event is triggered. So everything below the 'Heartbeat' box are triggers implemented as AutoNodes. For instance the Ance box is the trigger where the mayor makes an anouncement at 8am. And the 'Egg' box is the trigger where the hens at the farm lay egg at 3am.

In the lower left corner there is the 'Kitchen' module. It is the part where LRRH bakes. Below the first green box are three blue boxes denoting the kind of bread she can bake, and below each of the blue box is a grey box and the sequence of shared templated story elements. This whole module could have been a hard-coded subroutine in the actual game.

On the right of the kitchen module is the bed module, and on the right of that there is the node called 'basket'. The 'basket' node is a node that display the contents in LRRH's basket no matter where she is at, and returns to wherever she came from. The in-game implementation of this node is just the 'inventory' icon.

Overall by the first glance I don't think you would like the image of the system, mainly because you probably are not used to seeing representations without arrows. What you may not realize is that arrows are practically useless in this situation, because there will be too many and too many crossing over. What you see is probably holding more information than you are imagining.

For example, under the 'Bed' module, the box 'set' is connected to the box 'slp' below it. When you look at it it seem that there is only one choice. But 'set' actually has four choices, one of them is the return choice, and the other three are choices that lead the the template 'slp', each with its own transition. Within 'slp' (sleep), the node calls two other modules to present the sleeping sequence and to 'Heartbeat'. So events (Interrupts) can occur while LRRH is sleeping. Boxes are shown for elements as high level as possible to minimize the number of nodes (so that when i change something i only need to change it at one place). None of the nodes have similar or equivalent contents. This is a major reduction from tree-type representation.

[Edited by - Estok on June 15, 2005 5:19:56 AM]