• Projects

  • Structure of quests in simple RPG

Hi everyone, I am a math teacher and recently dwelled into the hobby of learning to make (very simple games) on Godot! However I am encountering my first serious challenge where I properly need to think of the coding design. I understand coding design or structure of a game is a very broad question so it is hard to find specific tutorials or techniques that directly solves my problem. Therefore I decided that the best would simply be to post on the forum describing my particular case:

I am currently making a simple RPG: it consists of a character moving around a town and can talk to a bunch of NPCs. The current structure I have is one scene that is the scene manager that loads the current scene I am in (the main town, or a house etc.) and also possess some GUI properties.

To handle dialogues I use this really great plugin called Dialogic, if you do not know it you should check it out! https://github.com/coppolaemilio/dialogic I have one single NPC script that I attach to every NPC node, and using the plugin, depending on the NPC's name, it will trigger a different dialogue. (I attached two images at the end of the post)

To handle quests, I have a global script, that possess a bunch of bool variables that get triggered if the player performs certain actions (finds the key, speaks to a specific npc etc). I trigger them using signals. To save and load a game, I save the global variables into a dictionary and then can load them later if I play the game later.

The problem I have is that all the emitting signals handling the quests are in this one NPC script and is slowly getting very long. Because of the plug in, any signals that are emitted during a dialogue need to be caught by the NPC's that is talking. But now my NPC script is a very long file that handles both the dialogues mechanism and also the quests! This does not seem to be a very appropriate way to do things.

What could I do to make my game structure "healthier" and more consistent? Any links to tutorials or some documentation is always appreciated. Thanks a lot for your time.!

Image 1: Implementation of the dialogue using the plugin

Image 2: Emitting signals to advance in the story

I don't see a problem with any of it other than you need to keep the code related to each npc on a script connected to it. If one script handled all the npc inputs, that would be a problem, but you would want to change variables on a global scale so it would be easy to save the game.

I have indeed only one single script that handles all the npc inputs. Are you saying that a more appropriate way would be to create separate scripts for each npc?

@bioplankton said: I have indeed only one single script that handles all the npc inputs. Are you saying that a more appropriate way would be to create separate scripts for each npc?

It would depend on the size. If you are going to have hundreds of entries that would be hard to maintain unless you are careful about how you can identify and find problems. Personally, I would just keep one on each npc because as you are working on the scene, you are going to design for a specific npc and debug a specific npc. It's easy to go right to that problem and fix it. Even 50 entries would be too much for me, and the problem is you are going to be adding as you go. Of course, you would have to have the variable named in a global script before you changed it. That's just what I would do personally. Some people like to have a lot going on in one script, but I prefer to break it up into logical places.

One thing you could do, though I don't recommend it, is to keep all of the dialog and quest information in a database. That's how big projects like TrinityCore do it. The advantage is that your data is actually separated from your code, and easier to maintain. The disadvantage is the difficulty of making the code to interpret the database entries.

If you've got lots of dialog, and lots of quests, you save a great deal of effort by not having to use basically-the-same code a thousand times for different quests. It might slow down the proliferation of signals, too.

I was thinking of making a smaller-scale version for my own games, but I've never made a start on it. :)

@duane said: One thing you could do, though I don't recommend it, is to keep all of the dialog and quest information in a database. That's how big projects like TrinityCore do it. The advantage is that your data is actually separated from your code, and easier to maintain. The disadvantage is the difficulty of making the code to interpret the database entries.

If you've got lots of dialog, and lots of quests, you save a great deal of effort by not having to use basically-the-same code a thousand times for different quests. It might slow down the proliferation of signals, too.

I was thinking of making a smaller-scale version for my own games, but I've never made a start on it. :)

Those are good points but they can be overcome by using repetitive code in a base class. Signals can be only activated during the conversation. I'm pretty sure dialogic uses some kind of system already that's similar to a database, so you could probably use that. Actually, all you need at the NPC is a tag to the timeline. It doesn't really matter where it is, then you can just load it or use it. You can kind of see what he was up against because more and more signals would be on one long script. While you would want something like that for the stored variables, it would be hard to find what you are dealing with for the individual NPC. All this, of course, is my personal preference. For me, I like to have the code broken up into places that logically are easy to find. There are so many ways to program and there isn't a right or wrong. Also, I've only briefly used Dialogic. At the least, it's another way of looking at the problem. While I do deal with dialog in my games, it tends to be more individualized. It might be different if you are using some kind of template or something.