An editor for creating Non-Player Characters
Before you continue reading, the NPC Editor is being further developed to be a standalone tool that any project can use, if you find this useful, consider giving me a hand or a coffee:
Code repo: https://github.com/RiseRobotRise/CharacterStudio
Patreon: https://www.patreon.com/dev_atl
The Development Process
Warning, heavy read ahead!
The first logical step was to create the Behaviors Editor, and with this in mind I proceeded to create the UI.
The Behavior Editor
At first, the nodes were predefined GraphNodes with variables embedded, but to allow the use of this tool as an addon I had to make sure all the nodes could be modified, and how would someone modify and handle so many scenes? The approach rapidly left me with a Scene clutter in a bad folder structure.
The solution was to make the nodes via code, I created a demonstration file, where my goal was to provide just enough functions to create a simple NPC that would use Moonwards’ systems to interact with the world. This code wasn’t actual GDScript but a structure of dictionaries and subdictionaries, containing titles, types and keywords.
First all that code would also contain the function to execute too and then build a GDScript out of the “compiled” text, but being Moonwards a MMO, security was the priority and letting user embed code wouldn’t be safe. Users must create these behaviors using the provided nodes only, but anyone modding the game or using the addon can make nodes for their own code.
These dictionaries are contained in a file named Definitions.gd, which is looked up by a singleton that then turns its contents into GraphNodes and packs them for later.
Nodes used in the Editor would be saved along the variables they store to be loaded later into an NPC that uses them. The files would be read as signal and function names, so the Script that loads them creates, connects and disconnects signals with their variables as bindings to the functions existing in the extended file. The script also has to keep track of these connections, as it’s important to disconnect them later for the next behavior tree to be loaded, which is determined in the next layer: the States Editor.
The States Editor
Differing from the behaviors editor, the states editor didn’t need defined nodes to work with, it reads the directory where behaviors are saved and creates GraphNodes using their names only.
This Editor would create a simple State Machine, which has states that can be connected to any other and randomly pick the next state from their connections (In technical words, a nondeterministic finite automata with ε-moves that only uses empty transitions).
It will also display any exported variables in your NPC script and let you set their values.
After creating the state, it is saved referencing the Behaviors it uses and containing the exported variables you set.