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.

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?

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.