• Ei tuloksia

Creating a dialogue editor for the Unity game engine


Academic year: 2023

Jaa "Creating a dialogue editor for the Unity game engine"



The goal of this thesis was to develop a prototype dialog editor for the Unity game engine. In addition, this thesis touches on the history of dialogue in digital games and compares currently available dialogue editing tools and solutions for digital games. Originally, the end product of the dialogue editor was going to be a plain text-based editor that had to look like Neverwinter Nights 2 game's dialogue editor visually and in terms of the basic functionalities.

Finally, the latest lightweight dialog editor can be used to create branching dialog structures with several optional conditions and actions for each dialog line. Little real research has been done on the dialog editor's solutions for producing, testing, and customizing the dialogs. In addition to exploring current professional dialogue editor solutions, the aim of this thesis was to create a lightweight dialogue editor for the Unity game engine for a game development company, Plush Pop Soft, that commissioned this thesis.

The dialog editor developed for the thesis was created as a plugin for the Unity game engine. To optimize their games, they need a dialog editor that doesn't affect the performance of their games and is easy to extend. The thesis then explains the criteria and goals for the solution of a lightweight dialog editor, describes in detail the phases of programming and implementation of a lightweight editor, and finally evaluates whether the result is a viable alternative to already available tools.

While dialogue in games can occur between different human players, the focus of this thesis is on the dialogue between the player and other non-playable characters or entities within a game.


Both Aurora and Electron tools had a proper dialog editor in them, which became the first inspiration for finding a new dialog editor solution for Unity. Dialog files can be imported and exported as xml files, allowing them to be edited outside of the toolkit. The benefits of the Electron toolkit dialog editor are simple basic usage, xml compatibility, and a shell-free editor view.

While the dialogue editor is not complicated, the Electron Toolset never became as popular as its predecessor Aurora Toolset and as a result learning resources are scarce. However, many of the dialog editor's features are almost identical to what was already in the Aurora toolset, which contains a lot of learning material. The ease of use and clean look of the Electron dialog editor were considered key factors in designing the Unity dialog editor plugin.

Like the Electron toolkit, it is based on an older game's modding tools and offers a complete dialog editing solution. The dialog editor is visualized as a node tree with different color-coded nodes for different types of dialog nodes (see image 4). While Fungus is one of the more lightweight dialog editing solutions on Unity's own asset store, it also has some extra features and plugins integrated into it that are often unnecessary.

It is also the dialog editor that this thesis' client has used in their game development workflow so far (Plush Pop Soft 2019). The dialog system has many of the same features as Fungus, such as Lua script, node-based dialog editor, and localization (see Image 5). It's also easy to separate parts of the dialog into different groups by organizing the nodes on the screen – the Creation Kit also offers a similar functionality, but is less simple and intuitive.

Based on the discussions with the client, the most important functions of a dialog editor from their perspective are visualizing the dialog flow, adding and displaying conditions, and the gameplay actions that can be triggered from dialog lines. It's this universal dialog editing approach that makes these tools unwieldy and difficult to use. This conclusion is convincing enough of a reason to create a simple dialog editor with only the essential functions.

Additional time to create or add previously created functions may not be the most optimal solution, but if a dialog editor is too specific, it will limit the way it can be implemented. If the dialog editor is made too universal, it will eventually run into the problem of having unnecessary or obsolete features, and this can lead to human error, slower development time, and unstable performance.


The Unity game engine has two easy ways to create a container for the data and classes that the dialog files need. In the end, an open source solution called Node Editor Framework for Unity (later referred to as the Node Framework) was chosen to become the dialog editor's framework. In the first solution, the dialog nodes will only have a small piece of the dialog line's text with the full dialog line information visible on the side panel in the Unity game engine.

Each dialog node has an image slot that you can use to distinguish the dialog nodes in the editor, or you can use it as an avatar for the speaker in the game. The condition and comparison type are stored as enumerations, which will allow them to be displayed as a drop-down list in the dialog editor. In the UI, if dialog nodes belong to the player, the available dialog lines will be represented as buttons.

The dialog manager is responsible for returning the correct line of dialog for the game's UI and will know how to navigate the dialog based on input from the interface. In the demo scene, the dialog display script is responsible for starting the dialog and allowing the user to progress through the dialog. Writing and testing the condition system along with the dialog manager took longer than expected and the demo scene ended up missing some of the features that were planned for it.

This was not considered a key part of the presentation and was replaced by simple on-screen instructions on how to start a dialogue. In addition to personal testing, the final prototype of the dialog editor with a demo scene was delivered to the client for testing. The developer, who was previously in charge of implementing the dialogue in the client's games, performed the testing using a demo scene and short verbal instructions.

It just took a moment for the developer to get used to the text area being in the canvas compared to the Dialogue System for Unity asset where the text area was located on the side panel. The biggest flaws and areas where the dialog editor is lacking are related to the interface and the controls. As long as the edit values ​​for the conditions and actions were set correctly, the dialog behaved as expected.

The main drawback noticed during the testing phase was the increase in file size as the dialog grows larger. The performance of the dialog editor and manager was good on all platforms tested, but the Node Framework's data format is very memory intensive and is not suitable for creating multiple long dialogs.