# Unity Dialog and Event trees

This topic is 744 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Game Engine: Godot Game Engine

Language: GDScript — Syntax very similar to Python

My questions are obviously within these bounds. I am very happy with Godot as an engine; and I do not think that my limitation to GDScript prevents me from any of what I aim to achieve: many have done so before me. It is almost entirely a matter of logic and the implementation of that logic within the bounds of resources available. With that said, let me propose my problem.

I am by no means an adept and fluent programmer, but my knowledge has been sufficient enough to make games in the past and I feel that I am capable of implementing whatever structures, systems and logic trees are suggested to me with some thought and exercise.

I have created a dialog system in Godot Game Engine which I am (somewhat) happy with, but does not achieve my core goal. Keep in mind this system was completely created by me and I was not following any examples, which could contribute to why it is so awful.

The first thing to note is that this system only allows any sign or enemy to have two states of text: An intro, and if specified, a continuation of that text. An exported variable lets me check a boolean to say "This character has two lines of dialog." — Upon speaking to the character they might say "Hello [player], my name is [entity], nice to meet you!" Then be flagged to say that the character has spoken to them.
Upon "activating" them the second time, the script will see that it HAS a second line of text, and then the NPC might say "It's a nice day today!"

The main core of this is done through three systems:
- Checking if the player is next to an interactive object.
- Passing the character details to a function which will query an external config file for appropriate dialog.
- Displaying the text on screen. (This part is fine, I'm totally happy with how it turned out)

Let's say that I have a Skeleton that the player can talk to. Its external parameters are this:
SECTION: GRAVEYARD (Its location)
KEY: SKELETON (Its identifier)
EXTENDED: True (Does this NPC have two lines of text?)

The script would then query a .cfg file which contains a dictionary of text; it would look like the following.

[GRAVEYARD]
SKELETON = {"INTRO": " Why don't skeletons fight each other?.","IDLE": "BECAUSE THEY DON'T HAVE THE GUTS!."}

The first time the player talks to him, the script would see that it has two lines of text. It would automatically search for "SKELETON" in "GRAVEYARD" in the config file. (See above.)

The script would then retrieve the dictionary value held in "INTRO" and flag the NPC such that the next time the script is called it searches for the "IDLE" dictionary value.
The player then activates it again, the script sees the flag, and then looks for "IDLE" instead of "INTRO".

This is the best that I could do. And it's god awful. It serves no purpose, other than to display two different mundane pieces of text.

So why don't I use the system to enable more?

This is where my logic runs out. Bam. None.
The way that Godot (and MANY other engines, including Unity) handle objects are through nodes. These are the equivalent to Unity prefabs. I create an object and I have the luxury of attaching a script to it, which defines the way that ALL of those objects will behave, which saves me a lot of coding. Obviously there is a ridiculously easy solution to this, but my experience doesn't allow me to think of one, which is why I am here.

If the script searches for an invalid dictionary, the whole game crashes. If it searched for "IDEL" instead of "IDLE" — it's game over. (No pun intended.) So a solution would be to create a different script for each NPC in the entire game, but this doesn't work. What I need is a dialog tree which can be safely called by all NPC's in the game to get different text based on the situation. Is the player low on health? The NPC could say "You look sick!", is the player on a quest? The NPC could say "I hope you've killed those pesky Goblins!", has the player just saved someone's life? They could say "Wow, thanks for saving me!"

I will probably never use such complicated trees, and my current system could pass for this game as it's only a Castlevania-esque platformer. But it does me no favours, and while it has taught me a lot, is a huge bottleneck not only for creating dialog, but for my event system (flipping switches, opening doors with keys etc.) which works very similar to the above.

I have researched dialog trees, but they're all in the context of LUA/C++ which I obviously can't use. I'm pretty sure Godot supports XML but I don't think it can read XML files in the usual way — in that XML is specifically just a format for saving scripts or prefabs. I have a Config File system which can store any kind of variable or dictionary, and a surprisingly powerful scripting language that can do just about anything that Python can do.

I guess the best way to describe my limitation from my point of view is that I don't know how to create a system where entities or interactive objects behave differently while still using the same script. Obviously, there are other factors, and dozens of ways around it, but I really really really need a push in the right direction. Please give me some logic advice, or ways that you tackled similar issues. Thank you so much for taking the time to read this.

##### Share on other sites

if the engine you're using is limited to one behavior script per object type, you'll need a script and object type for each desired behavior. if you want 100 different npcs, you'll need 100 different scripts and 100 different types.

if the scripting language has the power to query an instance of a type for instance specific data such as an ID #, and can do branching logic on that value, you can use a single branching script for all instances of a type. the script would use the instance ID to figure out which NPC its was controlling. from there, hopefully the scripting langue is powerful enough for you to figure out where that npc is, whats going on, and thus what they should say.  this would basically fold your 100 scripts into one big branching monster script, but it would eliminate redundant lines of script code, IE having the same lines of code in 100 scripts. so it would be somewhat easier to maintain.

if you can't do a branching script, there's still the possibility of making a script generator. you would give it a list of high level behaviors, and it would generate the script code for them. a slightly faster way to generate and maintain 100 scripts.

a variation on that would be to have script code snippets for each behavior, and use batch files with the the copy+ command to concatenate them into whatever kinds of scripts you need.

obviously, any script will somehow need to know which NPC its controlling, via some ID info its passed or looks up, or by the object type (for one type = one script).

##### Share on other sites

if the engine you're using is limited to one behavior script per object type, you'll need a script and object type for each desired behavior. if you want 100 different npcs, you'll need 100 different scripts and 100 different types.

if the scripting language has the power to query an instance of a type for instance specific data such as an ID #, and can do branching logic on that value, you can use a single branching script for all instances of a type. the script would use the instance ID to figure out which NPC its was controlling. from there, hopefully the scripting langue is powerful enough for you to figure out where that npc is, whats going on, and thus what they should say.  this would basically fold your 100 scripts into one big branching monster script, but it would eliminate redundant lines of script code, IE having the same lines of code in 100 scripts. so it would be somewhat easier to maintain.

if you can't do a branching script, there's still the possibility of making a script generator. you would give it a list of high level behaviors, and it would generate the script code for them. a slightly faster way to generate and maintain 100 scripts.

a variation on that would be to have script code snippets for each behavior, and use batch files with the the copy+ command to concatenate them into whatever kinds of scripts you need.

obviously, any script will somehow need to know which NPC its controlling, via some ID info its passed or looks up, or by the object type (for one type = one script).

This reply was very constructive. This scripting language is more than powerful enough to test for an ID (or any variable) of a an NPC and can have virtually limitless scripts to reference from, or call functions from. Are you saying that I should create a separate script (such as a singleton) that will always be running, or listening, and for the NPC script to pass its parameters to a function on the external script signaling it the details it needs to make things happen?

I guess my question is, how could I use that external script to manage 100 different behaviours for 100 different NPC's when they all have very different conditions? Or am I missing the point?

##### Share on other sites
I guess the best way to describe my limitation from my point of view is that I don't know how to create a system where entities or interactive objects behave differently while still using the same script. Obviously, there are other factors, and dozens of ways around it, but I really really really need a push in the right direction. Please give me some logic advice, or ways that you tackled similar issues. Thank you so much for taking the time to read this.

Here's how I'd do it. In your NPC node, export a new variable called "conversation" (or whatever you like).

export(String) var conversation

Then when you add that node to your scenes, you'll see the Conversation variable in the object property panel. You can type in the name of your conversation config file in that variable for each NPC node in your scene. Importantly, you'll be able to type in a different file name for each node. Each NPC could have their own separate conversation file.

Then, in your NPC node, you just need to script it to load the config file assigned in the Conversation variable. That way, each NPC can use the same code, the same functions for parsing the conversations, but each NPC will have different conversations based on the config file. One NPC node, one NPC script, but many conversation files.

You can use the export keyword in a lot of different ways. For example, you can have an Enemy node with a single behavior script. But you can export variables for Speed and Turning Radius that allows you to have many different types of enemies all with different attributes from that one node.

• 12
• 10
• 10
• 11
• 18
• ### Similar Content

• Hello. I'm newby in Unity and just start learning basics of this engine. I want to create a game like StackJump (links are below). And now I wondering what features do I have to use to create such my game. Should I use Physics engine or I can move objects changing transform manually in Update().
If I should use Physics can you in several words direct me how can I implement and what I have to use. Just general info, no need for detailed description of developing process.

Game in PlayMarket
Video of the game
• By GytisDev
Hello,
without going into any details I am looking for any articles or blogs or advice about city building and RTS games in general. I tried to search for these on my own, but would like to see your input also. I want to make a very simple version of a game like Banished or Kingdoms and Castles,  where I would be able to place like two types of buildings, make farms and cut trees for resources while controlling a single worker. I have some problem understanding how these games works in the back-end: how various data can be stored about the map and objects, how grids works, implementing work system (like a little cube (human) walks to a tree and cuts it) and so on. I am also pretty confident in my programming capabilities for such a game. Sorry if I make any mistakes, English is not my native language.
• By Ovicior
Hey,
So I'm currently working on a rogue-like top-down game that features melee combat. Getting basic weapon stats like power, weight, and range is not a problem. I am, however, having a problem with coming up with a flexible and dynamic system to allow me to quickly create unique effects for the weapons. I want to essentially create a sort of API that is called when appropriate and gives whatever information is necessary (For example, I could opt to use methods called OnPlayerHit() or IfPlayerBleeding() to implement behavior for each weapon). The issue is, I've never actually made a system as flexible as this.
My current idea is to make a base abstract weapon class, and then have calls to all the methods when appropriate in there (OnPlayerHit() would be called whenever the player's health is subtracted from, for example). This would involve creating a sub-class for every weapon type and overriding each method to make sure the behavior works appropriately. This does not feel very efficient or clean at all. I was thinking of using interfaces to allow for the implementation of whatever "event" is needed (such as having an interface for OnPlayerAttack(), which would force the creation of a method that is called whenever the player attacks something).

Here's a couple unique weapon ideas I have:
Explosion sword: Create explosion in attack direction.
Cold sword: Chance to freeze enemies when they are hit.
Electric sword: On attack, electricity chains damage to nearby enemies.

I'm basically trying to create a sort of API that'll allow me to easily inherit from a base weapon class and add additional behaviors somehow. One thing to know is that I'm on Unity, and swapping the weapon object's weapon component whenever the weapon changes is not at all a good idea. I need some way to contain all this varying data in one Unity component that can contain a Weapon field to hold all this data. Any ideas?

I'm currently considering having a WeaponController class that can contain a Weapon class, which calls all the methods I use to create unique effects in the weapon (Such as OnPlayerAttack()) when appropriate.

• Hi fellow game devs,
First, I would like to apologize for the wall of text.
As you may notice I have been digging in vehicle simulation for some times now through my clutch question posts. And thanks to the generous help of you guys, especially @CombatWombat I have finished my clutch model (Really CombatWombat you deserve much more than a post upvote, I would buy you a drink if I could ha ha).
Now the final piece in my vehicle physic model is the differential. For now I have an open-differential model working quite well by just outputting torque 50-50 to left and right wheel. Now I would like to implement a Limited Slip Differential. I have very limited knowledge about LSD, and what I know about LSD is through readings on racer.nl documentation, watching Youtube videos, and playing around with games like Assetto Corsa and Project Cars. So this is what I understand so far:
- The LSD acts like an open-diff when there is no torque from engine applied to the input shaft of the diff. However, in clutch-type LSD there is still an amount of binding between the left and right wheel due to preload spring.
- When there is torque to the input shaft (on power and off power in 2 ways LSD), in ramp LSD, the ramp will push the clutch patch together, creating binding force. The amount of binding force depends on the amount of clutch patch and ramp angle, so the diff will not completely locked up and there is still difference in wheel speed between left and right wheel, but when the locking force is enough the diff will lock.
- There also something I'm not sure is the amount of torque ratio based on road resistance torque (rolling resistance I guess)., but since I cannot extract rolling resistance from the tire model I'm using (Unity wheelCollider), I think I would not use this approach. Instead I'm going to use the speed difference in left and right wheel, similar to torsen diff. Below is my rough model with the clutch type LSD:
speedDiff = leftWheelSpeed - rightWheelSpeed; //torque to differential input shaft. //first treat the diff as an open diff with equal torque to both wheels inputTorque = gearBoxTorque * 0.5f; //then modify torque to each wheel based on wheel speed difference //the difference in torque depends on speed difference, throttleInput (on/off power) //amount of locking force wanted at different amount of speed difference, //and preload force //torque to left wheel leftWheelTorque = inputTorque - (speedDiff * preLoadForce + lockingForce * throttleInput); //torque to right wheel rightWheelTorque = inputTorque + (speedDiff * preLoadForce + lockingForce * throttleInput); I'm putting throttle input in because from what I've read the amount of locking also depends on the amount of throttle input (harder throttle -> higher  torque input -> stronger locking). The model is nowhere near good, so please jump in and correct me.
Also I have a few questions:
- In torsen/geared LSD, is it correct that the diff actually never lock but only split torque based on bias ratio, which also based on speed difference between wheels? And does the bias only happen when the speed difference reaches the ratio (say 2:1 or 3:1) and below that it will act like an open diff, which basically like an open diff with an if statement to switch state?
- Is it correct that the amount of locking force in clutch LSD depends on amount of input torque? If so, what is the threshold of the input torque to "activate" the diff (start splitting torque)? How can I get the amount of torque bias ratio (in wheelTorque = inputTorque * biasRatio) based on the speed difference or rolling resistance at wheel?
- Is the speed at the input shaft of the diff always equals to the average speed of 2 wheels ie (left + right) / 2?