Generic Multiple Choice Dialog System.

Have you ever wanted to add dialogs or conversation to your games, but you don’t know how?
Or you know how to do it, but the boredom of entering lines and lines of text manually in to a spreadsheet or text file is so bad that you never finished?

Well hopefully this project will be of some use to you.


It is going to be made up of two parts:

An editor.
An in game dialog manager.

All you’ll have to do is write your dialogs and save them as a pickled text file, add a script to the characters in your game who are going to be doing the speaking and enjoy adding text based, multiple choice dialog style conversation to your games.


The main editor is pretty much finished, but the code is a mess and it’s completely untested. I’m going to need feedback and testing if I’m going to get it to work.

Here’s a short video showing how it works:

The basic idea is that when you meet a character you can engage in conversation with them. Either you or they can make the first contact. Right now the SPEAKER (AI character) is the default first speaker, but their first dialog can be skipped with a GO_TO action, meaning your first dialog starts the conversation. The speaker needs to be the first contact because they will be the in point of the dialog tree. A property on the NPC will match a dialog ID in the tree and conversation can start from there.

Actions will be handled by an in game function, they can do things like check for items in the player’s inventory, or give the player money or change their appearance or give them hidden tokens which close off future dialog options.

Several actions will be included, so far I have plans for:

PLAYACTION (do an animation, either the speaker or the player)
PLAYSOUND (makes radioactive kittens rain from the sky)
GO_TO (kind of loop back or forward to another point in the conversation)
CHK_INV
CHK_QUEST (check the player inventory or quests list to see if that dialog is possible)
CHANGE_STATE (make the player or speaker do something, like attack or die or something)
CUT_SCENE
CHK_REP (check personal reputation)
SET_REP
GIVE_OB_INV
TAKE_OB_INV (give or take objects from the player’s inventory)
TELEPORT (transport the player to another game location)

Any other ideas for actions?
Any other ideas or suggestions?

I’m already thinking of illustrating the GO_TO action on the display tree with lines to the relevant dialog.
Should the dialog boxes be bigger and show more text, or is graph comprehension more important in the overview scene? If you zoom out you can’t read the text, but if you zoom in you can’t see all of the dialog tree.

Maybe mouse over a dialog box to pop up a more detailed summary of that box?

Spent the evening today refactoring the code for the dialog editor.
I crushed 4 bloated functions in to a single streamlined class, cutting it down about a third of the lines and getting more functionality to boot.

Overall things are not as clean as I’d like, I’d love to be able to do that with the whole program, but I just don’t have the luxury of that sort of time. As long as it works, that’s all I’m interested in right now. Elegant code can wait.


I’ve added the option of setting dialog IDs to be custom. And for setting the dialog owner to be “other”. In this case instead of the dialog popping up over the speaker/player’s head, it will be shown in a kind of cutscene style. This is good for introducing a character, or adding descriptions of what’s going on.

For example, you walk in to an area and see a body. You interact and it goes to a cutscene;

“This guy looks like he fell out of an Airplane!”

Or you’re talking to someone and their phone rings;

“Alex turns rudely away to answer the phone. You could try again later, when he’s not so busy.”

The dialog mode exits.

Hopefully now it’s working, the next thing you should see is an in game example of the dialog system in action.
It might take a few days though as I’m pretty busy this week.

^^ I like it. Good luck! Will this be an add-on for BGE?

We will definitely need something like this in our game

I will personally use this for wrectified :smiley:

can you add a emotion for the response?

Anger + 10

or

Funny + 10 ?

this way the actor can have a action play (smile, frown etc?)

Sure. The actions are string inputs which are picked up by the action function in game. So if you had a SET_STAT action it would set the stat (strength, charisma, anger, etc…) by a specified value. Maybe PLUS_STAT and MINUS_STAT would be useful too…

This won’t be an add on, just an editor you can run as a game. It let’s you save to disk and then you can load the saved file in your game to get the contents of your dialogs.

There’s a few things I’m thinking of changing, for example, I’m going to try out actions as they are, but I may re work them to be a single input box where you can add lines of text messages to be unpacked by a translator function in game, like this:

entry_action = "GO_TO:0007"
do_function(entry_action_list)

Inside the function we can split the string to get the arguments for the function:

entry_action_list = action.split(":")

And it allows much more arguments to be used:

entry_action = "GO_TO:0007$PLAY_ACTION:PLAYER,wave,0,21,ONCE"

So you’d split at $ to get individual actions, then split at : to get the arguments of those actions.

And you could even take it a little further to have a kind of mini programming language all based on split strings…

entry_action = "ARG#1=CHK_INV:100_dollars@IF=GO_TO:0007@ELSE=PLAY_ACTION:PLAYER,wave,0,21,ONCE"

But that starts to get very complicated. :frowning: You’d need some kind of complex parser, and some kind of debugging tools. The chance of making a big mistake would be pretty high. once you start adding dozens of actions to your game you’re going to get huge headaches from such a system.

It seems better to have a very restrictive input method of just single arguments which I can check against a predefined list of variables and highlight the text as an error if the input is wrong.

For example if you enter GET_TO instead of GO_TO the editor can flag that by changing the text color and adding an icon to the node in the outliner view to show that the dialog box has an error in its action definitions. Just looking at the outliner you can see that some nodes are not correct and you can go in and fix them.

I’m going to try this out and see how it works. having some kind of debugging tool with actions is vital.


OK, I’ve finished prettying up the interface, time to get on and make a demo.

I think I’m going to leave the actions pretty basic for now.
Just GO_TO and GIVE_TOKEN.

GIVE_TOKEN can be a very powerful action, because you can get a token; a property or a string and use that to trigger your own function in game. In that respect it’s pretty weak too. You have to do all the work with your own program.

For example you might get a token which says “GIVE_PISTOL_AMMO” and you then have to activate a function that gives pistol ammo to the player. Or “OPEN_KITCHEN_DOOR” or “RAT_HUNT_QUEST_DONE” would be quite good tokens which you can use to run the required function in your game. I’m starting to think this is the best way to handle actions, but I’m going to try the original idea as long as I get time.

I’ve also set up the dialog boxes in the overview so they can display more text. They now show around 78 characters of text. That’s enough to see at a glance what the dialog box contains.

In game dialogs now working.



Awesommmmmmmmm

You sir, are a gentleman and a scholar,

This look really cool, I would definitely play around with it. I think it would also be awesome to have some sort of similar system for creating and fulfilling game objectives, like: player does something, property is or item is added, then player can do something else, and that is automatically updated. Looks really similar to the dialogs.

There is nothing stopping you from randomly selecting using variables right? Ai could run behavior trees…

The output from a tree could even be messages or ?

If choice is x do y.

Roll for x using adjustments based on variables.

Am I wrong ?

Yes, you could build a similar AI tree based on nodes and behavior. It’s like a very specialized custom logic brick layout really.
I think an AI tree would have it’s own requirements though, so it would be best to make a fresh design for that.

***RANDOM…

I’ve definitely got plans for a RANDOM entry_action. Right now, when you make a dialog choice the manager checks each possible AI response for validity (using GET_TOKEN to see if the required token is in the token dictionary) and then chooses the first valid one on the list.

RANDOM would replace that last step by adding all the dialog boxes with the RANDOM entry_action in to a list and then choosing the next dialog randomly. So it could be given to fairly generic NPCs and they would choose a generic response to your greeting:

“There are ghosts in the old castle!”

“Speak to Old Bob the Mayor before you leave.”

“All your base belong to us!!!”

***OTHER IDEAS…

Some other ideas I’m working on adding right now (before I start cleaning and optimizing the system I want to finish adding new features):

  1. Quick select dialogs based on number key presses or up down arrow keys.

  2. A DEFAULT exit dialog. Right now every dialog must end with a player input, otherwise there’s no trigger to end the dialog mode. Marking a dialog as DEFAULT_EXIT would allow the program to pick it up in case you forgot to add an exit point to your dialog (currently it just escapes out of dialog mode if there are no valid exit points in the next branch of dialog). This could be combined with RANDOM to pick from a selection of potential default dialogs. Could also use GET_TOKEN to check validity of the default exit dialog, like if you are in a hospital bed then:

“You turn and walk away.”

Would be an invalid default reply.

  1. More visual feedback to show when you are in dialog mode. Black bands along the top and bottom of the screen? More animation options for the dialog boxes. A short exit animation after you click the leave dialog confirmation box.

  2. Word highlighting. Something I wanted right from the start but I’m having trouble getting it to work. If you find a code, or a person’s name, any of the dynamic format entries basically, it should be highlighted. I’ve got some ideas on how to do this, but not implemented yet. I think string.find(word) should work, but what if there are more than one occurrence of the word?

  3. Character portraits. Easy enough to do, just have to integrate it.

  4. Automatic format dictionary creation and saving, based on dialog contents. So you get a text file with all the format arguments you used in your dialogs. So if you’ve used {player_name} to automatically enter the player’s name, that string will be added to the text file. The same for ACTIONS and TOKENS, so you can easily keep track of which tokens or actions you’ve created.

  5. Anything else?

***CORE CONCEPT…

Really I want to limit any functionality of the in game system to a single overlay scene with a couple of global dict entries for passing messages (in the form of TOKENS) to and from the main scene. If you want to use the system, then you only have to import that single scene along with its scripts. You could then adjust the font and dialog box visual representations easily enough by accessing the overlay scene. Setting up the game side of interactions is pretty easy. Just pass an entry dialog ID to the global dict and add the overlay scene. The dialog system will do everything else automatically, even removing the overlay scene at the end of the dialog. You can then handle interaction with the dialog system through the global dict TOKEN dictionary, like how I changed the character’s clothes in the above video.

***BENEFITS OF A NODE BASED SYSTEM…

I should have a testing version available soon. I think this kind of system; the logic brick/nodes type setup can be very flexible. It could be used for a lot of things, but you need quite a specific system for each usage (though I’m sure people could find a way to adapt a dialog system to fit other uses).

Such a system is also much more intuitive than using raw code. For example, I’ve heard that when it comes to certain programming concepts, such as recursion, people either naturally can or can’t understand the concept, and for those who can’t it’s never going to be possible, no matter how much they study. Actually I think this is BS. If you can represent the concept visually, I think anyone can understand it.

***ENTER AND EXIT…

Again I’m still thinking about entry and exit actions. There are very few cases where it makes sense to discriminate between entry and exit behavior, and usually in that case you couldn’t use them in the other position at all anyway. For example, checking of tokens has to take place on entry, it can’t be done on exit, likewise giving tokens must be done on exit, not entry. Perhaps being able to add any number of actions to a dialog box would be better than having a single set enter and exit action.

There’s also the issue of tokens being only boolean properties. Theres no reason not to use ints or floats, which would make stat checks possible using get token. Hmmm have to think a little more.

I’m putting some finishing touches to this and I’ll soon have it available for testing.
After playtesting it myself I’ve made a few changes:

Only one action per dialog entry. Actions have been simplified from my original plan, I’m now just using TOKENS, RANDOM, and GO_TO.
You can now give each dialog entry a label. It shows up on the outliner, but not in your game dialogs. Good for organizing your dialogs.

Here’s the low down on actions:


SET_TOKEN is for adding tokens to the TOKEN dictionary in game.
GET_TOKEN is for makign checks against tokens which have been added to the dictionary. If you leave the optional CHECK argument clear it will just check if the TOKEN is in the dictionary. Else you can get quite complicated, checking scores, names, timers and a lot of other stuff if you wanted.

SET_TOKEN will add or subtract from an existing token, or set a value if it is not already in the dictionary. You can delete entries from the dictionary using DEL_TOKEN.

I think the token system is a very flexible way of adding actions to your game, because it’s up to you how to execute those actions. There’s no need for me to know what you’re going to be doing in your game, this just provides a flexible framework.

For example, you have a TOKEN named ammo.
Picking up ammo in your game adds to this TOKEN value in the token dictionary. People might ask if you want to buy some ammo, if you don’t have any, or they might give you some.

You could have a reputation system, with rep points added or subtracted as the game goes on and people reacting to your reputation during dialogs.

The other great thing is that you can make it as simple or complex as you want, either using GET/SET TOKEN without any arguments and just checking True or False, or using complex checks to maintain a more detailed system.

The finished system is almost ready for testing.
I’m going to attach it to a simple moving cube based scene for testing rather than make a bulky download by including my own character set up. I’ve added keyboard support so you can select dialog options by pressing a number key. I’ve also done a little work on optional visual styles:


Here’s a kind of paper/wood/leather based dialog view, for RPGs and the like (you can change the material easily to be one or the other). I’ll be adding metallic sci-fi types too as well as a generic colored rectangle type I showed earlier.

I do need testers, so if anyone would like to try it, please tell me.
It’s very easy to use and I’ll do a couple of tutorial videos too.

I’ve got a version of the dialog editor and in game implementation ready for testing.
I’m now going to be moving on to using it in my own project, but if anyone wants to test it, I’ll be happy to help with some demonstrations and tutorials as well as try to help with integrating it in to your projects.

Here’s the files:
dialog_tester.zip (309 KB)
I’m pretty sure everything should work OK. Please tell me if any textures or other things are missing.
it’s made with Blender 2.72 so that’s the best version to run it with.

It’s pretty easy to use, but I’ll make some tutorials over the next few days on how to use the actions, TOKENS and how to use the dialog editor as well as how to make custom dialog objects in game, so you can control the look of dialogs in your own projects.

For tutorials I can make videos or I can make powerpoint presentations.
Which would be easier?
Depending on your feedback I’ll be posting this in the resources forum soon with accompanying tutorials and reference files.

I’ve written a manual in powerpoint format for anyone who want to try the system. It covers all aspects of the writing your own dialogs and implementing the dialog overlay scene in your own projects.


I’ve also uploaded a new file because I forgot to include the spellchecker trainer file in the original upload. So spellchecking wasn’t working.
You can download the new folder here:
DIALOG SYSTEM

First off…awesome stuff!

Is there a way to change the location where the chat pops up?

So instead of it popping up bottom left it pops up above the character?

I’m currently using blender 2.71
(started this project at work in blender and don’t want to upgrade for fear of having to go back and make a lot of changes)

thanks so much, this is really useful, thanks to put it all so well and easy to use.

Smoking Mirror, you are AWESOME :slight_smile: