Journal

Event Tools – Part 1

Posted by:

This post is the first in a series that examines the kinds of tools we are creating for the purpose of writing event scripts for our various NPCs and cutscenes.

Consider: you are creating an RPG, and you want to make simple NPC that welcomes the player to town. Since you are using Godot, maybe you add a custom property to that object called “Message”, and then you can edit it like so:

You then write code to hook it all up. It’s succinct, simple, and fast!

Mission accomplished… except, what if we want the name of the NPC to show? That would be another variable. What if we want to open a shop menu immediately after the text box is shown. Now we need another variable for the target scene. What if we want two message boxes in a row, or more? The interface gets cluttered quickly.

What we actually want is an “event” system that allows us to encapsulate things like message boxes, shops, and even (in some cases) movement into nice, well-understood nodes. Our previous engine (RPG Maker MV) had something like this, but it really did not represent flow well:

This represents an NPC that counts to five, then asks you if you want to have it count again. RPG Maker represents events as trees with “jump” commands that can break the flow. This is not a bad solution, but it is hard to follow once you start jumping around. Since we were writing our own set of tools from scratch, we thought we could do better.

The first thing we did was to take EmAlexander’s excellent “Dialogue Tree” plugin for a spin (https://github.com/EmAlexander/DialogueTreePlugin). This plugin adds a “Dialogue” resource type, and represents it as a graph instead of a tree. You can see an example dialogue resource below:

The nodes (black boxes) are essentially actions (like “show a Basic Dialogue”, or “present the user a Choice”), while the edges (white lines) represent the flow of the event (i.e., “if the user selects “I’m ok”, then go to this next node). Being a graph, the lines aren’t always so neat and tidy, but it generally looks ok.

We immediately set about to modify EmAlexander’s plugin to suit our needs. In fact, we re-wrote about 90% of it, and then added a bunch more node types. The message system ended up looking like this:

Besides being a little easier to follow, we now have nameplates to tell you who’s talking.

Messages are only the beginning; in later entries, we’ll talk about control and movement commands. Also, note that the message boxes are all misaligned and improperly sized at the moment.

Licensing notes: EmAlexander’s plugin is licensed under the MIT license, so our extensions will remain private (for now) while remaining in line with the terms of that license.