next »

[nqe]

Hello, first post, so I'm sorry if this is in the wrong place 

I'm currently writing a branching dialogue system for an RPG type game (Star Control 2 type to be more accurate  ) since I couldn't find an already implemented easy to use system which impressed me.

Several questions for my fellow (tigsource-rs, tigers?):
1) Any links to well known branching dialogue systems I can take a look at and steal ideas from?
2) The branching dialogue system will have the option of voice-overs and bgmusic. I have zero experience with sound so I'm wondering which is a better way to handle it: many small sound files for each line a character says, or a large sound file perhaps for an entire dialogue where I would have a table and jump to the right place when needed. Sound tutorial links for programmers would be welcome.
3) Any ideas on how to visualize a branching dialogue with it's different outcomes and changes made to other dialogues?

I would appreciate any input on this 

[increpare]

Writing a system ... mhmm - using what tools?  As in, are you designing on on paper, or programming one with a particular language?

I've seen a bayesian-style branching dialog editor here that used a flowchart system, but I can't remember where...

For basic dialog setups that are nonetheless extensible, I actually would recommend checking out renpy if you haven't already.

Any ideas on how to visualize a branching dialogue with it's different outcomes and changes made to other dialogues?

Visualizing changes made to other dialogs?  Probably a flowchart, allowing for boxes like 'set flag such and such = whatever".

[nqe]

I plan on writing the dialogue editor in c++ with Qt and OpenAL for sound.

The idea of the system is that it would be reusable for many different games. Each character has its own dialogue file (XML) and then there is a player Dialogue file which remembers which options have been selected from previous conversations and uses that to determine which options you will have in future conversations. The player file more or less acts as storage for global variables.

I'll take a look at renpy, but I'm not sure it's what I'm looking for.

Flowcharts for visualization might not be a bad idea (hopefully I can do them in Qt).

[increpare]

The idea of the system is that it would be reusable for many different games. Each character has its own dialogue file (XML) and then there is a player Dialogue file which remembers which options have been selected from previous conversations and uses that to determine which options you will have in future conversations. The player file more or less acts as storage for global variables.

So you wouldn't be able to have the same conversation twice?  I think it's easier and more efficient to have the ability to set flags over the course of conversation myself (it's more descriptive  to say 'is JohnAngry' than 'did you say X or Y or Z to john that').  If you want to view it in a more static light, maybe allow people to 'tag' particular pieces of text with flags (though better still allow them to attach scripts to them), in a way that would let you refer to them later (maybe have some branches be tagged, and they only appear if you've encountered/not encountered those tags before).  Remembering everything is not necessarily something that's very useful.  What's more useful, I think, is a way of processing and distilling memories, so I'd personally recommend you give the latter precedence.

It should be said that, in terms of conversational technology, that the IF people are miles ahead of most others.  They've moved beyond trees, so maybe their stuff wouldn't be too relevant to you (or maybe that makes it more relevant...). 

[nqe]

Sorry for the long post.

I am not trying to make this anything much complicated. This is a rough example of how I plan the XML dialogue file to look like:

Code:

<root>
  <character>
    <name> Max Delmonte </name>
    <alliance> Human Federation </alliance>
  </character>

  <dialogue>
    <heading id="0">
      <!--Normal meeting-->
      <part id="1">
        <l> Hey Capt'n! How's it going? </l>
        <c id="1" goTo="End"> I have to go </c>
      </part>
    </heading>

    <heading id="1">
      <!--First time meeting with Delmonte-->
      <part id="1">
        <l> Captain Hart! I've heard so much about you. How are ya? </l>
        <c id="1" goTo="p2"> What is a human doing so far from Federation space, and how do you know my name? </c>
        <c id="2" goTo="Battle"> You are a dead dead dead man! </c>
        <c id="3" goTo="p3"> test1 </c>
        <c id="4" goTo="p4"> test2 </c>
        <c id="5" goTo="p5"> test3 </c>
      </part>
      <!--Who are you? -->
      <part id="2">
        <l> Oh, my apologies captain. I am the one and only Max Delmonte, merchant and ladies man extraordinaire. </l>
        <l> I am a merchant of all things useful, be it food or weapons. There is surely something you will find interesting. </l>
        <c id="rem(p1)" />
        <c id="1" goTo="DelmonteShop"> Let me see what you have. </c>
      </part>
      <!--What are you doing here, how do you know my name?-->
      <part id="3">
       

      </part>
    </heading>
  </dialogue>
</root>

l stands for line
c stands for choice
Each c has a goto which determines what happens once the choice is selected.
Dialogue is separated into headings and then parts. A heading constituting a major part or persistent dialogue such as a seller might have (in the example <heading id = "0"> is the default conversation you would have with an npc, in this case a merchant).

Special commands such <c id="rem(p1)" /> will take all the remaining options from part 1 (p1) from the parent heading. There of course can be more special commands to make this robust.

The player class will remember which options have been selected by their unique overall id obtained by concatenating the heading id, the part id, and the choice id.

Right now my rough version of the parser handles timing of the dialogue by the count of characters of a certain line, but it shouldn't be too difficult to add a value for voice-over timing.

Writing all the dialogue of a branching game would of course get really hard if done by hand (considering it would be really hard done with a proper tool as well) which is why I plan on writing an editor.

The biggest weakness of my plan is that it doesn't allow for multi-NPC dialogue but I am thinking that would make things more complicated than I would like them to be.


In reality very few games do branching dialogue. In fact the only ones that I can think of are Arcanum (<3) and Fallout.

I believe the way IFs handle dialogue is not appropriate for a standard visual rpg type game, but correct me if I'm wrong.

Suggestions on how to improve the format or potential pitfalls would be welcomed.

[BorisTheBrave]

The way AGS does it (last time I checked), is you basically have a series of coversation options, and what results from each, stored flatly. Only a subset are initially available, and each choice dictates how the available subset changes. Usually it is a complete replacement, or set subtract, but (assuming arbitrary logic is allowed), you can get any possible structure from that scheme. This is important, as a lot of conversations we'd call branching actually covers quite a few different structures, such as.

[increpare]

Don't keep us in suspense, Boris!

[nqe]

Haha, yes, the suspense is killing me!

But what you said makes sense. When you mentioned sets, I realized that my method is almost congruent to them, which might mean that I can eliminate/simplify the XML structure and straight up use sets rather than a hierarchical approach which would make it easier to write a corresponding dialogue decoder 

Time to put some more thought into it.

[muku]

Another thing to keep in mind is that your XML, with gotos and flags you can set, is starting to look a lot like actual code. Maybe you could just use a scripting language (Lua comes to mind) and write your dialogue in that, losing the XML? This would give you all those control constructs for free, plus powerful text formatting capabilities.

[Aik]

Eh ... I'm going to recommend you take another look at Ren'Py. Not that there's anything wrong with what you're planning, but Ren'Py's scripting language can easily do what you're thinking and it's quite pleasant to use. Writing dialogue editors isn't much fun (been there...).

Also it might be worth stealing WorldMaker's idea/script from this Script Frenzy thread. It's a simple Python script that converts Celtx scripts into Ren'Py's language. Celtx is a supersexy program and I can't imagine you can make anything better than it for doing lots of writing. If you wanted you could probably write a script to convert it to your own XML setup pretty easily.

[nqe]

Thanks for the responses.

From a very quick scan, I can see that Ren'Py has some interesting ideas such as character expressions, and filters/transitions which I might try to implement as well.

The game I'm working on is in AS3, which has a decent XML parser so I'm not too worried about parsing the dialogue files. As far as writing the dialogue, I'll try coding a GUI to help with that. I guess it's time to buckle down and see what I can manage.

Once again, thanks for all the responses.