The Unity editor is actually quite hackable and can be used like that, but that's very likely a 'licensing grey area'.
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.
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.
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.
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.
...and yet Unity and Unreal are quite popular compared to "rolling your own editor", and very few people do it. Most people seem to be happy with the Unity/Unreal/Godot tools, with generic IDEs, with generic image editors, with generic 3D editors, with generic DAWs, etc etc etc.
A standalone scene editor doesn't have to be more generic than Unity or Unreal. The idea is providing a base for engine makers to work on, not the opposite.
Part of the success of generic solutions is due to cost. Not every game developer has the time and resources to make a tool like the two you mentioned. And also engine makers, not all of them have the time and resources to do an editor like Unity or Unreal.
A good generic editor is better than a shitty specific editor. It's also better than a non-existing editor.
> It's the same thing with IDE. The more plugin friendly you make your IDE, the less optimization chances you have.
Visual Studio Code, vim and emacs are actually extremely extensible and very performant. The sweet spot seems to be much more performant than you seem to assume.
So is Electron compared to rolling your native app. Electron is easier to develop for and pool of developers are bigger.
I'm taking about optimization opportunities.
> Visual Studio Code, vim and emacs are actually extremely extensible and very performant.
Eh. I don't use vim or emacs, but VSC isn't on par with something more integrated like JetBrains.
What I have in mind is Ralph Levien blog: https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...
And I completely disagree about JetBrains products being more integrated. Some integrations are MUCH better and deeper in VSCode. To give three recent examples I came across: Vue, React and Svelte. WebStorm doesn't even have some features offered by VSCode, like typechecking in templates. Not to mention that, at least to me, VSCode is significantly lighter than WebStorm and runs much faster in older laptops.
VSCode is also significantly faster and much much lighter than the ultra-integrated and native Visual Studio, so there's also that. I know because I use both, and I know which one locks up all the time and takes 40GB of disk. Seems like they just didn't use the optimisation opportunities.
Either way, this discussion doesn't seem to be going anywhere. There's doesn't seem to be anything for us to learn here. I'm addressing every new single point you make, while you keep moving the goalposts by cherry-picking my posts while ignoring the parts I cover :/
We started this discussion by saying "it would be awesome if X existed" to which you said "100% disagree". Sounds like you don't want me to have some tools, or maybe you're under the assumption that my desire is for Unity/Unreal/Godot to stop existing, which is definitely not the case.
The alternative isn't nothing. The alternative is either Java, Qt, Gnome, Slint, rolling your own, doing per OS UI, etc.
People don't want to roll their own (understandable) or don't mind paying performance tax for stuff they don't need.
I don't use WebStorm but yeah a browser (VSCode) is better at rendering JS than a Java IDE (IntelliJ). Ofc a browser will have an advantage on home turf.
That said quality differs, but honestly try debugging Rust in VSCode vs CLion. Worlds of difference. Even if CLion isn't the best Rust plugin. Or Java in VSCode vs IntelliJ.
> We started this discussion by saying "it would be awesome if X existed" to which you said "100% disagree".
Your idea is a generic game editor vs something specific like Warcraft 3 editor, I made an analogy between something like LSP vs more integrated stuff like IntelliJ.
And I showed you what you leave if you make LSP primary focus, there are going to be some use cases that won't work in generic case, that a more specific IDE (or Rappid Application Deveploer env) would work with.
I said IF the alternative is nothing. IF. Read that again. Read the whole context. Words are important. Don't skip them. Stop cherry-picking. Your point is only true IF I have money, time and knowledge to use those. I might not have it. Are you gonna come to my company and code all this stuff, for free? Most game teams don't have the budget, so they won't have a custom editor and will have to use something like Unity/Unreal/Godot. And most potential engine writers don't have the budget for writing editors, hence my mention that there is a place for something generic.
> don't mind paying performance tax for stuff they don't need
The performance tax is higher in some JetBrains projects. It is also significantly higher in Visual Studio Enterprise than in VSCode. "Integrated" doesn't mean "faster".
> Your idea is a generic game editor vs something specific like Warcraft 3 editor
It's not. My idea was an open-source scene editor that engines can choose to support when they can't make a proprietary and engine-specific scene editor. You're the one who brought Warcraft 3 into the conversation. I also don't understand the "vs" part. Let me try to simplify my point to you: People who have time and money make X, should have X. People who can't make X, would ideally have an Y option too.
If you don't want to use such an editor, just don't use it, period. Claiming it won't be helpful to people and a community that wouldn't otherwise be able to build an alternative is asinine.
> I don't use WebStorm but yeah a browser (VSCode) is better at rendering JS than a Java IDE (IntelliJ).
"Rendering JS"? This is nonsensical, the JS code is run either in a browser during dev time or in a separate process for typechecking. An IDE is not a runtime. Please inform yourself before making such ludicrous statements.
> And I showed
You really haven't demonstrated anything, sorry. The cherry-picked CLion example doesn't negate the fact that there are counterexamples. Your ignorance doesn't invalidate the counterexamples. To me it sounds as if you're completely out of your depth here and just trying to win a random internet argument, and has absolutely nothing to contribute to this conversation. What you propose already exists but costs money. Why can't we have the alternative?
Re-read it. It still is unclear. An app made in Electron could have been written in something else. What use case do you have where the alternative is nothing. The IF is almost never valid. Even if it doesn't exist yet, you can make it.
> Most game teams don't have the budget, so they won't have a custom editor and will have to use something like Unity/Unreal/Godot.
Sounds like excuses. Get a bigger team, smaller scope, or more money.
I've used Unity vs custom-made engines and ease, and just fun of the use of well-made customized engine beats Unity/Godot (I haven't used Unreal lately) in almost every way. Like time for Unity to start alone is 5min, plus Unity makes a certain style of games nigh-impossible to develop.
E.g. two similarily complex projects https://www.youtube.com/watch?v=BT1B4HkEhfQ
First is UnityStation in Unity, second is SS14 in C#. And Unity is a lot of pain to work with.
> Claiming it won't be helpful to people and a community that wouldn't otherwise be able to build an alternative is asinine.
I said it would be more helpful to focus on building a specific viewer for a particular type of game. Sure, you can make a viewer that is meh at being a top-down, isometric, 3D, hyperbolic, pixel art, vector, etc.
Or an editor that's great at just pixel art - Like Aseprite. Or a 2D Level editor - like LDtk.
Do one thing correct vs. do many things tolerable.
>"Rendering JS"?
Lapsus linguae. I meant to write debugging. So read it as, debugging JS in JS VM, isn't as good as debugging JS in JVM and vice versa (JVM in JS).
> The cherry-picked CLion example doesn't negate the fact that there are counterexamples.
Implying your example isn't cherry-picked? Really? How much have you used VSCode for languages with other VMs?
> Why can't we have the alternative?
I'm not saying you can't have the alternative; I think most of the time, it's a wrong trade-off.
I found myself preferring "the right tool for the job" over "everything and the kitchen sink" approach. And yeah, there are benefits to merging stuff and keeping it all in one place. See the link to Ralph Levinen's blog.
But, I tolerate IDEs because the integration of debugger and code help + highlight is obligatory, but I would lie if I didn't use a simpler tool if I need to quickly and speedily edit something.
Now compare Rider C# Ide to Unity IDE, that integrates even more into the mix. So it's C#, 3D Editor/Viewer, engine, etc.
That sounds ludicrous. A bigger team or more money are incredibly difficult, especially for hobbyist and open source.
And the whole goal of this idea is to reduce the scope of projects in the first place!
It's impossible to reduce the scope if it requires something that might be as big as the engine itself.
-
> Lapsus linguae. I meant to write debugging. So read it as, debugging JS in JS VM, isn't as good as debugging JS in JVM and vice versa (JVM in JS).
But the Javascript doesn't run inside the JVM or inside the Electron process. It happens in a completely separate process! It's the same for the syntax highlighting: it happens inside the Language Server for VSCode, and it's probably the same for JetBrains when using Typescript too.
-
> Implying your example isn't cherry-picked? Really? How much have you used VSCode for languages with other VMs?
Of course it's cherry-picked, but this is how counterexamples work. The point is that a JetBrains IDE isn't by definition "better integrated", there are several more factors.
StarCraft 2’s editor went even further with the game genres it was able to support (though they failed at building the community to utilize it)