The dialog system

Alright, this time we are talking about a core mechanic: the dialog system. Remember, in the first devlog of this series, I chose to focus on the story, and dialogs are a great way to lay out the story in a natural, interactive way. In my former games, I’ve been using different kinds of dialog systems, but they never satisfied me. They worked fine for a game jam, but I knew they wouldn’t scale well. So I spent some time making a better, more scalable dialog system. Below is a little sketch of how it works:

I use to store my dialogs in Resource-inheriting classes, so that my data stay away from my behavior. Hence the DialogLine class: this is where the text and the speaker are stored. Usually, I also make a Dialog resource, as an array of DialogLines - but not this time! I wanted to link my dialogs to a specific button on the map - which requires the class to be a Node, since buttons are Nodes. I also wanted the dialog to be proposed only when a set of conditions are met, which again required listening to Signals… so I ended up making Dialogs a Node-inheriting class.

This was the rightest decision in the development of this game : it makes it very easy to check conditions periodically. If the conditions are met, the DialogButton to which the dialog is connected is displayed on the map. Once clicked, the Dialog is pushed to the DialogManager, which opens the DialogPanel and displays the Dialog one DialogLine at a time.

Easy, right? It actually took me 2 days to develop, and it is perfectible, but it makes my workflow sooo much easier. Adding a new dialog can now be made in 4 steps:

• Instantiate a new Dialog object as a child of the DialogManager
• Add and fill new DialogLines
• Choose a DialogButton
• Choose a set of conditions (currently, only other dialogs are available, but see below)

Done!

I set up a general method for checking conditions: every dialog has a dictionary of conditions, with a name and a boolean set as false. I then check periodically if all my conditions are met. This means I could add almost anything as a condition, associate it to a Signal, listen to it and when it comes, set the condition as true. For instance, I think dialogues should be time-dependent (like from 11 PM to 6 AM, everybody went to sleep).

Another thing I did was improve the art of the user interface. I researched several styles, and ended up choosing a “white futuristic” style, but with some dirt on it. It will echo the architectural style of the park’s buildings - more on this in a coming devlog, I guess. In the meantime, I leave you with a short video of the brand new dialog system: