Dialogue Graph System Unity
Intuitive Unity Editor Tool for implementing dialogue
Embedded Files
Project Description
The Dialogue System for Unity is a node-based solution to implementing conversations in games. This system is designed for designers, artists, narrative writers, or anyone else on the team to quickly and intuitively add conversations to the game without relying on programmers for implementations. Documentation Website Link
🔵 Roles: Programmer, UX Designer
🔵 Collaborators: Solo
🔵 Year: 2023
🔵 Timeline: 4 months
Design Goals
Intuitive to Use - so anyone can pick it up easily and quickly create dialogue in their game.
Visually Pleasing - so it's not overwhelming and information is understood clearly.
Programming Free - so anyone on the team can implement dialogue without programming.
Open Source - so people can use it and redistribute it as they please! All code is commented.
💬 Initial Rapid Prototype💬
This prototype of a dialogue system will include being able to create a custom graph editor with the ability to create, delete, and connect nodes together. To the right is a visual of how nodes work with Unity’s current UI Toolkit systems:
Below (and to the right) is an image of how I expected the prototype would look to the developer. Each node would have a title and a space where you can input your own custom dialogue. Then, each node will have an input and output where you can connect it with other nodes, but not to itself or to the same type of port (input/output). My main focus with this prototype was to experiment and learn how tools are created using Unity’s UI Toolkit rather than converting the node's data to in-game dialogue.
Result
This prototype resulted in a custom editor window, with the ability to create nodes and connect them together, all wrapped with a custom grid background.
Lessons Learned From Prototype
To view my learnings with this prototype, clock the headers below!
How to create a custom Window Editor
It’s very simple, like Creating an Asset Menu (Scriptable Objects):
Nothing will open if you just have this, so you would need to Open the window using the GetWindow<> Function. Make sure the [MenuItem] is above this method
Manipulators in the Graph Editor
Manipulators allow users to perform certain actions in the graph editor. Some manipulators include:
Selecting Nodes and dragging them around
Selecting multiple nodes with the rectangle select (dragging the mouse)
Dragging around the graph editor using the Middle Mouse Button
Scrolling in and out
and more!
Adding Stylesheets to the Graph Editor
To create a style sheet, right click -> Create -> UI Toolkit -> StyleSheet.
Stylesheets are elements used to adjust the visual aspects of Unity’s UI. You can edit font colour, font size, element spacing, background colour, and much more. Since I previously learnt CSS, this was familiar to work with. You can even create your own variables which is what I’ve done to the right of each line (--ds-colors-grid-light-grey-1)
Once you complete the stylesheet, you must call it in order to activate its effects:
Now instead of showing a plain dark background, the Window Editor will appear to be graph-like with the coloured lines we set in the StyleSheet.
💬 Main Features 💬
Designers can create dialogue conversations through the use of a custom-built graph editor. Currently, there are 4 nodes to create conversations.
For more information on the node types available, visit this page.
An in-depth interaction system was created to be able to interact with the NPCs when the player is either:
Closest to an NPC
Looking at the NPC
💬 Greatest Challenge 💬
This system was the most difficult to implement and is integral to converting the graph nodes to conversations in the game. I use scriptable objects to store all of the information in a conversation tree, and then read that data when an NPC is interacted with. The data below is stored in every node:
Node GUID: a unique identity that is specific to this current node.
Target Node GUID: the ID of the node that is connected to this node and comes after.
Pos: The position of the node on the graph editor
Each type of node also stores unique data. The dialogue node must store the dialogue text, audio, choices, an image, and more while the event node just stores an event Scriptable Object. Below is an example of how we save the data in a dialogue node:
💬 Skills Used and Gained💬
Commenting Code
Since I want this project to be open source, I add comments to my code to help developers understand the functionality of specific lines.
UI Toolkit Debugger and USS
Hovering over a GUI Element will direct the user to its html-like properties seen in the bottom left.When designing these nodes with USS, the debugger assisted me in knowing which elements I must assign classes to so I could modify their properties.
Empathy
Empathy was practiced throughout the entire process of developing this tool. I want to make this tool for others, for a variety of scenarios, while still being simple and intuitive to use.
Creating the
💬 Documentation 💬
I begun the documentation process by first analyzing how other companies document their work and which methods of documentation are used (website, YouTube video tutorials, pdfs, etc.).
Similar to the Unity Documentation, Node Canvas has its own website where the documentation is held. There are different sections (in the left), and each section can be jumped to. It gives a description of the node along with how to use it, and a screenshot for what it’s referring to. At the bottom of the list (the left container), there is a link to the full API in a pdf document with the same information found on the website.
Strengths: Organization of features, simplicity of website, variety of documentation methods
The Nav Bar:
Stores links to all other documentations and information about NodeCanvas.
The Heading:
Holds the name of the nav bar tab the user is currently on.
The Features List:
Contains all the functions, references, added elements, and basic information of Node Canvas that is readable, scannable, and searchable. Spacing makes the list easy to read, users can scan it based on heading and sub-heading to narrow down where their problem lies, and they can search for whichever specific function they want more information on.
The Content Information:
Holds all the information users would need to understand the function and how to use it. Screenshots are provided and important words are bolded to help users visualize the necessary details.
One flaw of the website however is that there’s A LOT of clicking involved to find the information you want. First you must click a header, then there may be additional (+) subheadings where users can reveal more information. The problem is that if you select another (+) heading, the one you already have open collapses, meaning to go between information you must keep expanding different subheadings and it could be frustrating especially if you cannot find the desired information.
Similar to the Unity Documentation, Node Canvas has its own website where the documentation is held. There are different sections (in the left), and each section can be jumped to. It gives a description of the node along with how to use it, and a screenshot for what it’s referring to. At the bottom of the list (the left container), there is a link to the full API in a pdf document with the same information found on the websitThis is another Dialogue System available in Unity’s Asset store that has a plethora of features. With each feature there is a video tutorial on how to use it, and an example of it in action. The person walks through each step from scratch usually, so some actions may seem repetitive but that helps tremendously when learning new tools.
Strengths: Feature demonstration, in-game examples
The structure of each tutorial goes as follows:
Introduces feature explored in this video.
Communicates the objective example – what the viewer will be completing by the end of the tutorial.
Starting the project from scratch, or with specific assets pre-prepared for haste.
Teaches feature throughout completing the example.
No coding is used in the tutorials, it’s all visual scripting.
Feedback and Changes
Feedback 1: Adding Numbers to the Sections
Feedback suggested for better organization and searchability to add numbers for each section. There are many different sections in each main category for the documentation, so to make navigation easier and be more organized, I included numbers so users can now tell how far they are into the page.
Before
After
Feedback 2: Front Page Hierarchy
Feedback suggested that the attention of the reader is being split between the text and the image, creating a weaker front page that is supposed to be easy to follow. The front page has been re-mapped to have the text in the middle, with a carousel image panel below it. With this setup users can now read about what the dialogue graph system is and search images of it without focusing their attention to the left and right sides of the screen.
Before
After
Feedback 3: Limit Scrolling
In my initial design, each image for each step was very large and this required users to scroll a significant amount to get to the next section. It could easily be tiring having to go up and down in search for the desired section, and so to lessen this issue I moved the images from below the text to the side. This way users can see multiple sections per screen and don’t have to scroll far to find the next one.
Before
After
💬 Project Documents 💬
Process Work Pdf.pdfWith all my projects, I first start by writing down my ideas and notes on paper. In the pdf above you can see my brainstorming process as I try to understand the system/tool I must create.
Project Proposal.pdfThis file documents my research on dialogue systems and is where I break down and analyze my findings. These findings are information gathered from many references including GDC talks and articles.
Project Documentation Research.pdfFor my project's documentation, I researched other systems' documentation pages to understand what information should be included, and any potential benefits to certain layouts. I also gained valuable feedback from friends and professors which I took and iterated my webpage on.
Code Review Feedback Response.pdfDuring the development of the dialogue system, I participated in peer code feedback sessions. Mentors and classmates would take a snip bit of my code and provide suggestions and feedback on any improvements to be made (the summary sections in the document).
💬 Next Steps 💬
Here are all the features I would like to implement before releasing the tool publically:
Barks
Conversation Conditions
Cutscene Support
Quests
Text size, speed, colour, styles
Custom events (before, after, during text)
Context-driven/ dynamic dialogue support
Saving and loading dialogue to and from an Excel sheet
Character profiles
Using interfaces for the Interaction system (instead of inheritance)
Google Sites
Report abuse