Dialogue

Game Engine Game Engine Support and Discussion
1

SO i’m working on some test to make 3rd person RPG top down game. I’m to the point where i’d like to create dialogue, and i’m having some trouble thinking through the process of what this might entail. :spin:

At this point, the only python that i know that might come in handy is globalDict.

My setup: you go to the person and click on them. This adds a new overlay scene called “Dialogue” It is a simple scene with just a text object and a black plane to act as a backdrop right now. I’m thinking the best way to do the talking is to have many strings on the person you are talking to and each string contains a response/declaration that is triggered by the player. But how can i list the options the player has to say and make it so that the globalDict loads the right response? basically i just need help thinking through this because i am very confused. Thanks

2

globalDict is not Python. It is an attribute of module bge.logic. It is a dictionary that is created on starting the game. It is supposed to be used to feed the save/load-actuators. It is not supposed to serve as anything else even when some people recommend that. There is really no problem to create your own dictionary, or other container to keep data that is not supposed to serve the save/load-actuators.

Your current situation is a typical example that globalDict is no good choice. Using it for dialog options denies the option to use load/save-actuators as it conflicts with them. More important, a dictionary is most-likely not the best object to manage your dialogs.

I suggest you design a separate dialog option object. You could call it dialog provider.

Think about what it should do and what it should not do (because other objects can do it better).

Here are some thoughts:

  • keep the status of a dialog (current node)
  • provide options for the current node
  • transit to a connected node (switching the current node)

Your dialog nodes can be a tree, but most-likely you want a graph (a tree has no loops).

A dialog has a start node, and several final leaves (where there are no further options). Usually the graph should always end in a leaf (no endless cycle).

A graph is easy to draw with pen and paper. But this is not really sufficient when you add the textual information. Electronically graphical representations are not really sufficient especially on larger graphs.

I suggest to use tables. It is harder to see the connections but easier to edit and maintain.

You need at least two tables:

nodes and edges

Nodes describe a single text statement
Edges describe the transition between test statements. You will need directed edges.

So a node can be a question. The connected nodes are the possible answers. Each of them leads to other questions/statements.

I suggest to fill Nodes with keys rather than with full fledged texts. This keeps the graph abstract and allows to use textmapping to several different languages. If aiming for single language systems you will still benefit from key to text mapping as it support the authors much better than a confusing graph.

What structure to use?

Nodes can be defined in a table (of keys). Edges can be defined in a dictionary with node keys as key and node keys as next state:


nodes = [
"greetings",
"welcome"
"ask.for.shop",
"ask.for.shop.type",
"ask.for.shop.bakery",
"ask.for.shop.food",
...
]
edges = {
"greetings": "welcome",
"welcome": "ask.for.shop",
"ask.for.shop": "ask.for.shop.type",
"ask.for.shop.type": "ask.for.shop.bakery",
"ask.for.shop.type": "ask.for.shop.food",
...
}

In this simple example you could skip the nodes list. In a more complex design, you would feed each single node with more details.
This graph is pretty simple. It starts with single alternatives. The ask.for.shop.type node results in tow options that the player or the NPC needs to chose from.

Now you need a text mapping (which should be kept separate from dialog design):


greetings = Hello
welcome = Hello
ask.for.shop = Where can I find a shop in this city?
ask.for.shop.type = What kind of shop you are thinking of?
ask.for.shop.bakery = A bakery.
ask.for.shop.food = A food shop
...

with that structure you can easily create translated text:


greetings = Moin
welcome = Guten Tag
ask.for.shop = Wo finde ich in dieser Stadt einen Laden?
ask.for.shop.type = An welcher Art Laden, denken Sie?
ask.for.shop.bakery = Eine Bäckerei.
ask.for.shop.food = Wo es was zu Futtern gibt.
...

I hope you get the idea.

3

#MindBlown… i feel a little more confused now. Idk if i undderstnad you all the way, but i feel like that method wouldn’t work when i have lots of people and scripts…

4

May I ask why? I’ve been using dicts (in external files) to manage my dialogs for ages. I use a web-style system for navigating dialog similar to, say a Bethesda game, in which you have multiple pages of dialog and different selectable options that basically change the NPC’s dialog page (and apply any effects, like “give the player a quest” or “open the shop screen”).

5

I meant a single dictionary. You will need much more data than that what the dictionary allows. Even my example suggest a dictionary … but in conjunction with more data.

A dictionary maps a key to a value. This is perfectly fine to build the proposed graph. It is perfectly fine to translate node names to strings. It is perfectly fine to map node keys to node data. Suddenly you have three dictionaries. This means the system is not a single dictionary anymore. Further on you need to track the current node. This can be a property or an attribute at a object or module.

Unfortunately when you end up with dictionary of dictionaries you are halfway to chaotic structure (I did that in the past, see my saveLoader). This can be fine, but processing on such structures is pretty hard especially when it does not work as expected, or your code uses the wrong dictionary.

That is why I think before you limit yourself to a single dictionary, better think about the architecture that supports your requirements. It can result in a dictionary. But I guess it will result in more than that.

6

There are two pre built dialog systems in the resources section. Search for dialog or quest editors. Mine has a built in editor with spell check which runs as a blender game. The other one uses blender nodes and might be easier…

7

Thanks for the recommendation @Smoking_mirror. I’m looking at Doc Holidays node based one, but i can’t quite figure it out. has anyone gotten it working in english that i could look at? I cannot figure out how to make the system so the text displays the NPC talk, and then the options, and then how to let teh script QnD_Mailer.py know what option i chose.

8

Maybe you can PM doc about that.
My own system has a ppt tutorial but even I dont remember how to use it well since I made it quite a while ago.
I’ll make a new one one day with proper classes and a google based spellchecker…