The Unity editor is actually quite hackable and can be used like that, but that's very likely a 'licensing grey area'.
Different engines will have different requirements. By making an editor for generic case, you'll end up Jack of all trades, master of none.
Integration makes more sense, but the price you pay is inflexibility.
That's a generic enough core feature set to be applicable to be useful for most types of games, yet the UI is already tricky enough to "do right" to justify a standard tool (especially when it comes to things like searchability and bulk-editing of data.
Additional game-specific functionality can be provided via a plugin mechanism.
Most DCC tools have actually a fairly basic 'core idea' which is then extended through plugins (e.g. in Maya the core idea is "everything is a DAG node").
For a lot of functionality, they need plugins or something similar. See Unity editor scripts for an example. Something unified would be able to take advantage of those plugins in a more generic way. Need a tile editor? Plugin. Need retargeting? Plugin. Need a special exporter for your game? Another plugin. Need a custom editor pane? Plugin, like Unity.
Another proof that current engine/editors are masters of one is that most people is already using a separate IDE for code, a separate 3D software, a separate texture painter.
That's an editor for single game.
The more generic you make it, the worse they are to use.
It's the same thing with IDE. The more plugin friendly you make your IDE, the less optimization chances you have.
It would also help tremendously in standardising file formats and other conventions. We've kinda settled on either ECS or Node-Based architectures, so there's an obvious starting point, concept-wise. Just have each engine provide a configuration file telling which components (or node types) are available, and how they can be configured. Or provide a language-server-like API so it's extensible.
There's no need to worry about high-fidelity, physics, sounds, or scripting during the editing (only during debugging), so some editor that just knows the 3D formats is enough. If debugging is needed there should be an optional way, like with code editors.
I've been looking for a big project to tackle, maybe that's something I can try to start myself :)
I had a similar thought. I was thinking maybe this could even be some web-based system where you could have multiple editors talking to the same engine session, or vice versa.
> Although good UX has been historically the Achilles Heel of open source
Completely agree. Perhaps the best way to go about a project like this would be to establish a few mock use cases up front (i.e. actually try to build a dummy game with your own tools). The magic of UX doesn't appear until you have actually used a thing and start tweaking stuff like animation delays, font sizes, tab order, modal positions, et. al.
> Completely agree. Perhaps the best way to go about a project like this would be to establish a few mock use cases up front (i.e. actually try to build a dummy game with your own tools). The magic of UX doesn't appear until you have actually used a thing and start tweaking stuff like animation delays, font sizes, tab order, modal positions, et. al.
That's true! However, there's some good prior art for engine editors, in the shape of Unity, Godot and Unreal.
This makes no sense at all to me. Part of what makes different game engines interesting is that they have different ways of modeling the world. How can you make an editor that's agnostic to the model? What's it even editing?
Unless your notion of 'game engine' is restricted to a subset that happen to use a very specific model. Like for example...2D tile-based platformers with finite maps.
You can usually abstract the 'data model' down to a generic "spreadsheet-like" representation of object types which are described by typed attributes (or in Unity lingo, game objects, components and properties). Anything more specialized (like modelling-, animation- and material-system tools) can be brought in through a plugin system. But at the core it's essentially a stack of Excel sheets with different view panels on the same data (like a property editor, or the 3D scene view).
A few minutes using Unity3D are able to demonstrate that: Unity's interface is quite transparent about the abstractions it uses.
Also, Unity3D itself uses the extensibility of its own editor to add advanced editing features, so it's already something industry-proven.
Agreed, and this is on my mind as I work in this direction.
By the way, I was really inspired by The Nebula Device back in the day, and even used it for some side projects. Thanks for working on it.
