Dialogus - A dialogue engine for Unity
I’ve been working on a dialogue engine for Unity (specifically, 2018.2.6) over the past few weeks that can be used in two different projects. I still have some work to do but I feel like I have a good starting point to discuss and post about it. If you want to see my progress, here’s a link to the Trello board I’m working on.
I’ve been working on a little thing called Dialogus which, as I said earlier, is a dialogue engine. It provides a large part of the back end for dialogue systems other than the actual dialogue UI itself. That part is up to the specific game to implement for things such as animations on the sprites, text animations, dialogue boxes, etc. Dialogus takes care of a lot of the heavy back end issues that are seen when trying to program your own dialogue tool in Unity. There are still a few things I want to add to the tool before I push it out and I want to test it on a larger game.
Originally, at least for one of the projects, I was going to use a system similar to what Brackey’s describes in this video. While this is in no way a bad system, if you’re using it for an expansive project, it can become quite cumbersome and disorganized. A few people from my college also tried implementing a variation of Brackey’s tool but quickly found that nesting things became ugly and worked poorly in the long run.
I knew I needed to write a tool that can be used in different types of games with different requirements. The project I am working on for Fishhead (a currently unnamed 2.5D platformer with dating sim elements) requires that it be useful in cut scenes and player/NPC interactions. For The Souls’ Sonata, from Mirror Studio, it’s going to be used in a visual novel setting. This means the engine will have to be optimized for lots of text, dialogue, and voice over work. In both cases, the dialogue tree presents a real challenge as it is the crux of both games.
The editor for Dialogus features a few things: a character creator, a variable declarer, and the all-essential dialogue tree editor. I’ll talk about each of these individually. I apologize now for only showing screenshots; I’m not too aware on the best way to record and make such in-engine presentations look good.
The character creator is a simple, lightweight aspect of Dialogus that has the sole purpose of containing each of the character’s names and sprites. It is a simple, inspector-based gadget that can automatically find the sprites of the character or allow you as the user to input your own sprites. I plan to expand this aspect to use custom folder paths but for now it works simply.
The Dialogue Tree Editor is the most interesting part to the entire tool. It allows users to build their trees up without code. The trees only rely on the Character Creator tool if you have sprites you want to use. You can still use the tool without a CHAR_X file or files, it just exists for the sake of making life easier when linking sprites to specific instances.
The editor currently supports three types of nodes: start, conversation, and choice.
The start node is the simplest of the three: it acts as the initial position to the rest of the tree. If all goes well, it should hopefully be Node 0 in the tree but some things happen and it isn’t. The editor does not allow you to place any other nodes until the start node has been placed.
The conversation node is the pivotal node as it is what most games will rely on. I also bet it will be the most nodes in a single tree unless you have a questionnaire or something similar.
The choice node is the next most interesting node and is the last of the three to have been implemented. The choice node currently supports up to 8 possible branches/choices/paths. Below is a sample from a quick test from within the editor.
The Variable Editor is a very simple tool, similar to that of the Character Creator. It allows you to create and initialize variables to specific values. Say you want a money counter or to see if the player has a certain item or if you want paths to be limited based off of a relationship with a given character, you’d use the variable editor to make these. As well, you can use these in the connection editor to direct pathing as stated just over a sentence ago.
The Connection Editor is a simple little window similar to that of the variable editor. You left-click on a connection and you can pull up the window to it. Here, you can add any number of conditions to the path as you’d like. For right now, the conditions must all be met but I do plan on allowing conditionals where one of the conditions need to be met. This will be implemented sooner than later, in fact.
Dialogus uses NetwonSoft’s JSON library as information is represented in the JSON format (because XML is just a pain for this case IMO). This is the library’s only dependency as it has been tested for years at this point and is widely trusted for JSON de-serialization.
Why not use Unity’s in-engine deserialize components? Simply because it’s support is far more limited. As the tool is further in development, and better ideas are found/implemented, the tool may switch to the lighter-weight Unity packages.
Dialogus has it’s own loader/tree traversal methods that you can call. The only function programmers need to worry about is NextNode(Node).
How does this differentiate from tools like Fungus?
Fungus is a general purpose engine that has the ability to be used in visual novels and games alike. The issue I found with it is it relies on Lua programming and it’s organization for conversations can be quite cumbersome. Dialogus removes a bit of these issues because it allows for each node to be seen and edited rather than hunting inside each of the nodes to find the specific conversation piece.
Why should I use this tool instead of something like RenPy?
You don’t have to use Python.
I kid, Python is a good language for certain tasks. It’s a tool in the tool belt that should always be considered.
In reality, it’s a good way to enable freedom for visual novel games. RenPy I find to be limiting in its own right. It’s documentation is something I also have an issue with as it is lacking compared to other resources. Of course, this will be improved over time hopefully. While it’s great for some types of visual novels, it is limited in its capacity to serve other functions for more ambitious VNs. Unity affords you such freedom to experiment and write your own systems. This tool takes care of the daunting task and question of “how do I write a dialogue tree in Unity?”
Are there any plans to support animations in the dialogues?
There are plans to support basic animation stuff (like ‘shaking,’ ‘jumping,’ etc.) however it’s a very, very low priority. There are better things that the tool can use over animations at this point but they may very well come.
What do I have to write/create?
The only scripts you have to write are a manager script to interact with Dialogus’s external facing tools. You have access to Dialogus’s node types (using enum values) as the traverser returns a generic Node object rather than a specific instance of the node. You also have to make your own GUI system (supplying Text for strings and RawImage objects for sprites). Dialogus acts as a way to hold data you need for interactions.
At the very end of the development, I plan on writing a basic dialogue manager so that way people who are not programming savy can quickly implement their dialogue trees while they wait for programmers to free up.
When will the tool be available on the Unity Asset store and will it be paid for?
Not too sure, but it isn’t gong to take another good month or two of development to get there when it’ll be available but I’m even more unsure of whether or not to monetize the tool. It will definitely go to the Asset store once I feel it is ready though.
There are a few things that I’m particularly seeing as obstacles the tool will have to overcome:
Translation/multi-language games: Currently Dialogus only supports one tree language at a time be it English, Arabic, Japanese, Spanish, or Russian. I need to solve the issue of how to have one tree with the ability to use any language. This may come down to reworking many of the lower systems in the tool itself.
Optimizations: While general optimizations can (and very much will) happen, the issue comes down to optimizing how files are saved, loaded, read, etc. These could potentially throw off older versions of Dialogus and prevent newer versions from being able to read old data. The basic solution to this is use only the version you have downloaded on the project but I want to do some more testing on this.
External Issues: My biggest fear comes down to managing the project properly. I’m still just a student at this point so exams and the like come first but, more importantly, dealing with burnout. With so many tasks to do outside of this project, Dialogus will be a slow growing tool until the end of this semester.
Breaking the Unix development style: I want Dialogus to be an amazing dialogue engine. That means I don’t want it to do anything else other than that. Some features will have to be tossed out that I plan, or others want, simply because it breaks the Unix cycle. I’m one person working on this right now.
