Hello everyone! I'm part of a small group trying to create a free, open-source, point-and-click adventure game in the spirit of Monkey Island (how many times have you heard that...?) We have already gotten our game engine working, and we have managed to assemble enough people to actually pull this off (we've got programmers, (amateur) voice actors, graphical artists, musicians, etc.), but one thing we're currently lacking is a proper script. While we have a general idea of the overall plot, we need to really get to writing a complete non-linear script for at least the first part of the game. However, I'm not sure how to go about writing it, as writing a non-linear game script is completely different from writing for example a screenplay. I'm sorry if this question has been asked a million times already, but the search function gave me nothing. How would one go about writing a script such as this? Are there any conventions or widely used tools to keep track of all the dialogue - with all the triggers, characters, rooms and objects that could affect what dialogue options that are available? With the character able to freely roam quite large scenes, the order in which the player talks to people and solves puzzles is also important. Code-wise we've got it all set up to handle these problems, but we need some kind of way to keep it all in order, so that it's easier to spot potential problems. If you want more information about the project, feel free to ask me here in this thread, on our IRC channel (#subterranean on freenode), go check out my blog where I frequently post information about the project, or you can go to the project page itself at github.

Quote: Original post by Nevon
Are there any conventions or widely used tools to keep track of all the dialogue - with all the triggers, characters, rooms and objects

No. You get to create your own conventions in writing your script.

I personally make a flowchart for the whole conversation. Then each 'card' or conversational unit gets a 'filename' consisting of the character speaking it, the facial expression they are supposed to have at the time if any, and a number. And in comments you can make notes about what the prerequisites or effects of that piece of dialogue are, if any: should it be automatically added to a journal? Does the character speaking it gain or lose affection points? Are there dialogue choices, or does the conversation end?

Quote: Original post by sunandshadow
I personally make a flowchart for the whole conversation. Then each 'card' or conversational unit gets a 'filename' consisting of the character speaking it, the facial expression they are supposed to have at the time if any, and a number. And in comments you can make notes about what the prerequisites or effects of that piece of dialogue are, if any: should it be automatically added to a journal? Does the character speaking it gain or lose affection points? Are there dialogue choices, or does the conversation end?

That would certainly help keep track of the dialogue logic when programming. I guess it could be used to write the entire manuscript - even if you would have to reformat it before giving it to the voice actors.

I'm not sure why you'd have to reformat it before giving it to a voice actor beyond adding more notes about what emotions each should be spoken with. Each voice actor just has to separately record each 'card' with their character's name on it.

I tried using a flowchart for the script yesterday, but it got incredibly messy once I had more than three characters. But I'm going to try and see if I could just make a flowchart with the requisites for each dialogue option, any items you get or lose, any trigger changes, and an ID number for the line. Then I'll make a text document where I write down all the dialogue lines and their ID lines. That way I'll keep it nice and tidy.

Flowchart, and further abstractions:

Flowchart could work, but you need to introduce abstraction layers to make them useful when your design is big.

Another related structure that looks like a flowchart is a mix between a process model and finite-state machine. I think to do this properly, you need to know the major plot axis. The changes in the major plot are your states of your FSM. Within each state, you would have a process model per interactive entity or event. The interactive entity may not be an actor.

The actual text is store in a database/spreadsheet, such that you could query/sort by actor, or plot point whenever you want.


The major axis of a story:

The major axis is a set of variables that marks the intensity of the overall plot. For example, if your story is about a boxing match, then the major axis could be the stamina/health of the protagonist and that of the antagonist. You could imagine that when the story begins, both you and your opponent have the max HP. As the match progresses, HPs decrease and you intensify the story accordingly. The natural climax occurs when the PC has low HP. The maximum climax occurs when both the PC and the opponent have low HP.

If your story is about traveling from point A to point B, which is not difficult, but the door of point B requires 10 keys that the player needs to gather, then your major axis could be the number of keys that the PC has. As the PC gathers mores keys, you make the story intensify by changing the way the world reacts to the PC. For example, if the world has only 10 rooms, each with a key, and each with a village that the PC can talk to, as the PC gets keys, the themes and dialogs of each village becomes more urgent.

If your story have multiple endings, you could design them to share the same major axis, or use separate major axes. If you use separate major axes, at some point in your story there could be a point of no return where the player can no longer progress on the other axis, or design the axes such that the two can co-exist till the end.


Scripting features:

The script I used had these features:

o The data is stored in the form a database. This allows me to organize however I want afterwards.
o The data fields support embedded variables and function calls.
o Each entry has these data fields:
= Node ID
= Comment
= Pre-display processes (these are function calls and variable operation scripts)
= Displayed Text (with embedded variables access, and function calls)
= Accompanying multimedia resources (with embedded v&f)
= Variable changes (w/ v&f&o)
= PC Choices, choice enable conditions, immediate effects, and destination nodes (w/ v&f&o)
= Automatic transition enable flag
= Preview function
= Integrated object-oriented variable system that allows dynamic variable creation
= Variable table showing instantaneous values.
= RAM save and load
= Log of nodes traversed


For the last few points, I guess I am basically saying that your game engine should allow you to modify the script in-game when you are running the edittor version, so that when you see something that needs to be change you could just change it on the fly.

The point of automatic transition is that once the engine is built, you could program the story without recompiling the engine, because automatic transition can handle all branches you need for your story.

Quote: Original post by Wai
The point of automatic transition is that once the engine is built, you could program the story without recompiling the engine, because automatic transition can handle all branches you need for your story.

Wow! That is a great reply!

I certainly see how that method of storing dialogue could be useful for big productions, but that won't be necessary for our game. First of all we're doing it in Python, so nothing is really compiled. Secondly, every room is it's own file, and the dialogue is stored within those files.

What I'm trying to accomplish is to write a script to work around when designing the game, as well as material for the voice actors to work of off.

For now I'm writing it in the same way I would write a screenplay, but with color coding and ID-numbers for each line. That way I can later create a flowchart that represents all the dialogues and shows how they are interconnected.