Sign in to follow this  

Unity Dialog and Event trees

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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.

Share this post


Link to post
Share on other sites

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

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Forum Statistics

    • Total Topics
      628644
    • Total Posts
      2984012
  • Similar Content

    • By arash khalaqhdoust
      hey guys i hope you doing all well. last night i released my first game in google app store, i really appreciate you guys  to download it. and share your reviews about it
      the idea of game comes from mini hackgame of Bioshock.
       link of download:
      https://play.google.com/store/apps/details?id=com.RVBinary.piperist
      many thanks
    • By ForgedInteractive
      Who We Are
      We are Forged Interactive, a small team of like-minded game developers with the sole purpose of making games we love! Currently, we're progressing very quickly with our first project and there are plenty of opportunities and work for new interested programmers. With this project, our development platform is Unity 5.5.2 and C# as our behavioral language. Since this project is our first release, the game itself is a smaller project though progress is moving quickly. We are looking to finalize the current project and get started on future projects in the near future and are expanding our team to do so.
       
      Who We Are Looking For:
      Programmer Level Designer  
      About the Game
      Ours is the tale of two siblings, thrown into a world of chaos. Living in the shadow of their parents' heroic deeds and their Uncle's colorful military career, Finn and Atia are about to become the next force to shape our world. How will you rise through the ranks of Hereilla and what will be your legacy? Once defeated your enemies turn coat and join you in your adventures. Players can enjoy a range of troops and abilities based on their gameplay style which become more important as maps introduce more challenging terrain, enemies and bosses. Strong orc knights, dangerous shamans, and even a dragon are out on the prowl. Knowing when to fight and when to run, and how to manage your army is essential. Your actions alone decide the fate of this world.
       
      Previous Work by Team
      Although we are working towards our first game as Forged Interactive, our team members themselves have worked on titles including and not limited to:
      Final Fantasy Kingsglaive FIFA 2017 Xcom 2 Civilization  
      What do we expect?
      Reference work or portfolio. Examples what have you already done and what projects you have worked on academic or otherwise. The ability to commit to the project on a regular basis. If you are going on a two-week trip, we don't mind, but it would be good if you could commit 10+ hours to the project each week. Willingness to work with a royalty based compensation model, you will be paid when the game launches. Openness to learning new tools and techniques
       
      What can we offer?
      Continuous support and availability from our side. You have the ability to give design input, and creative say in the development of the game. Shown in credits on websites, in-game and more. Insight and contacts from within the Industry.
       
      Contact
      If you are interested in knowing more or joining, please email or PM us on Skype. A member of our management team will reply to you within 48 hours.
       
      E-mail: Recruitment@ForgedInteractive.com
      Skype: ForgedInteractive
       
      Regards,
      David, Colin and Joseph
       
      Follow us on:
      Facebook: https://www.facebook.com/ForgedInteractive/
      Twitter: @ForgedInteract
      Youtube: https://www.youtube.com/channel/UCpK3zhq5ToOeDpdI0Eik-Ug?view_as=subscriber
      Reddit: www.reddit.com/user/Forged_Interactive

    • By dell96
      I'm trying to make my first project but I'm stuck i don't know how to make my crate to start to spawn again when i hit the start button after i die.
      hoping someone can help!!!
      Crate.cs
      CrateSpawn.cs
      Cratework.cs
      GameController.cs
      GameManager.cs
  • Popular Now