working on a godot addon that provides a nice base to build various in-game editors with.
Could be stuff like level editor, some mod tooling, visual unit assembler, whatever.
mostly just because i've needed something like this in several projects so may as well make one nice one.
im aiming to keep it pretty modular (though the default modules will closely mimic how godot does things), currently theres a single Editor² (EditorEditor) node with a bunch of EditorNode children. The Editor² acts as the main interface for modules to attach to, and the EditorNodes are the datapoints they can act on. In this setup data is only stored on the EditorNodes with all the widgets and whatnot connecting to signals to detect changes.
Modifiable data on the EditorNodes are exposed by extending EditorNode with a custom script & using godot @exports as usual. This is the most straight-forward, and it'll just (mostly) work out of the box. There's a lot of methods you can overwrite to customize this behavior though. I've also made 2 variations on this node:
ResourceEditorNode, which takes a resource and allows the user to customize its parameters instead. This is probably easier to integrate with existing projects.ProxyEditorNode, which takes a reference to another node in the current scene & passes its parameters from that node. This one is pretty similar to the resource one, but a very neat thing is that it lets you very easily interact with godot's in-built nodes. If the user is supposed to be able to build their own UIs this could come in very handy i think.
right now the main modules (as seen in the video) are:
EditorTree (left)
Godot-like tree view of all the child EditorNodes of the connected Editor². You can allow the user to re-arrange the nodes as they wish (it follows & alters the actual SceneTree structure), select nodes, & in the future probably add & delete selected nodes too
EditorView (center)
Main visual module. Each EditorNode has a getter method that returns a EditorViewNode (which is just a GraphNode with the theming stripped out), These are then instantiated by the EditorView to build the visual scene. This should allow for pretty arbitrary visual representation & gizmo implementation, though i dont think i can provide a very great default experience for these since the addon is supposed to be easy to adapt to whatever project. Depending on GraphEdit and GraphNodes does mean that the editor itself & the performance is not something i need to think of a lot, and it comes free with resizing, moving, & selecting mechanisms :)
EditorParameterInspector (right)
Hey did you know EditorInspector is a native godot class? lol lmao
This is ye ol' inspector. By default it follows the current Editor² selection, though that can be turned off.
It collects the list of parameters from whatever EditorNode its pointed at (using mostly get_property_list(), which provides a lot of useful/important type hinting information) & instantiates a custom EditorParameterWidget that matches a parameter's type. Custom widgets can easily be added & existing ones overridden, though i think i can streamline it a bit more. They're basically just tiny collections of standard godot Control nodes. An important thing to note is that they can "attempt" to change an EditorNodes parameter, but will wait until that node actually says its changed to confirm its value. A nice by-product of using @exports by default is that you can use setters & getters for input validation if you want (or just overwrite the set_parameter_value() to go hog wild)
I added support for quite a few standard types last night, im particularly happy with the enums having correct labels which i was not sure would be possible (in godot, user-created enums save they keys in a dict-like structure so you can retreive names at runtime, but engine enums do not, thankfully the get_property_list() provides these for us anyways with the caveat that you can only retrieve them by looking at an instantiated object).
Im still a bit unsure as how to handle stuff like Resources and Node references. Resource nesting would pose a slight technical challenge, but more importantly i wouldn't want to give the user any control the dev wouldn't want them to. Perhaps add some settings on Editor² as to what to allow and what not? As for resources, it would be a bit tricky to figure out where to source the available resources a user may create from. Should this be an authored list by the dev? can i even do generic resources with this system so based on this specific node type? And theres like a bazillion types of resources, so theres no way im making widgets for all of them.
I still gotta implement some types like Vector3 & perhaps also stuff like Array and Dictionary (seems a bit complicated though, and the godot editor UI is also kind of bad at those). If the dev really needs some specific widget i've made it easy enough to implement whatever though, so it probably would not be a huge deal.
anyways. still tinkering away at this. I may return to some older projects if i get this working nicely. also can you believe how dumb that name is im a big fan. two of them. also can you believe godot let me register Editor² as the default node name even though you can't do that with a normal class_name. lol. hopefully wont cause issues down he line
