Reasoning, Research and Design
I started this project as a Minor in my university programme. I initially wanted to create a full RPG toolkit in Unity (and even before that a full 3D game engine) – so I researched multiple computer role-playing games (most of them AAA). That led me to my first goal, which was the Dialogue Editor, and as part of that a Node Editor.
I looked into node-based tools, some of them narrative, such as articy:draft, ChatMapper and Twine, and others more generic, such as Unreal Engine’s Visual Scripting*, most commonly referred to as the Blueprint system, xNode, and a few other Unity 3rd-party plugins with node-based systems. xNode was the key inspiration for my approach, and did a handful of the things I wanted to achieve at the time, like a good graphic user interface (GUI), creating graphs as assets and customizing your own Nodes.
I prototyped a couple of implementations without a GUI, but they did little to help with the design aspect of my project, as I couldn’t test the effect it would have in a user’s hands without a GUI and asset system. Eventually, I ended with a few key ideas:
- Nodes should only connect to other Nodes;
- Nodes will have only one Input;
- Non-branching Nodes will have only one Output;
- Nodes are only Data Containers;
- Nodes represent progression through the graph (or flow);
- Instructions (or Modifiers) are the inverse of Nodes – they may contain data, but only to execute an action.
In a programmer-manner of speaking, Nodes were meant to be the getters of the system, and the Instructions the setters of it.
The existence of Instructions, however, is a problem. Since Instructions are not Nodes, they weren’t so-to-say corporeal – they existed only within the Connections formed by the Inputs and Outputs of the Nodes. I theorised that this would provide a better way to discern Data and Actions (I was so so wrong!).
*Note: At the time, I didn’t have much experience with Unreal’s system, so even though I initially wanted to do that approach, I was advised to create a different system based on my own pillars of design for the node system. I see now that my key pillars seemed somewhat reminiscent of how Flow works within Unreal Engine’s nodes.
Future Plans
I plan to rework the entire plugin by:
- Simplifying the variable system, strip out of the plugin and release it on its own;
- Entirely rewriting the Node structure to mimic Unreal’s more. The point of this is to make the code base cleaner, and possibly simplify the Editor back-end (the View-Controller portion if you think about it from a MVC pattern);
- Simplifying the light scripting portion by turning Instructions into Nodes. This serves several purposes: Connections are “lighter” and may not necessarily need to exist as an object altogether, and custom Instructions will be easier to create, and finally they’ll share a similar Editor back-end.
Currently, I am reworking the variable system. It’s inspired by the variables proposed by a specific 2017 Unite talk about Unity Scripting Objects.
In the far future, I also wish to finish my original endeavor, which was to create several Node Editor-powered systems, such as:
- Inventory and Item system;
- Character system;
- Combat system.