3 ms·

Gonna disagree 100%. Different engines will have different requirements. By making an editor for generic case, you'll end up Jack of all trades, master of none

by Ygg2 4y ago

Gonna disagree 100%. 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.

flohofwoe 4y ago
When you look at the Unity editor, it's really mostly "just" a tree of game objects, which have components attached, which have editable properties of a handful of data types. 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").
ratww 4y ago
Engine editors are already “masters of none”. 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.
- Ygg2 4y ago
  I recently played with Songs of Conquest editor and Warcraft 3 editor, and they are easy to use but for single purpose. 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.
  - ratww 4y ago
    > That's an editor for single game. The more generic you make it, the worse they are to use. ...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.
    - Ygg2 4y ago
      > ..and yet Unity and Unreal are quite popular compared to "rolling your own editor" 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.html https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...
      - ratww 4y ago
        Sorry, but Electron is amazing if the alternative is "nothing". Same for game-specific editors. Some companies can't do it, so in this case Unity/Unreal editors are indeed better. And some engines also don't have the manpower to do engine-specific editors, so if something already existed it would be by definition better to the world. 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.

by Ygg2 4y ago

flohofwoe 4y ago

When you look at the Unity editor, it's really mostly "just" a tree of game objects, which have components attached, which have editable properties of a handful of data types. 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").

ratww 4y ago

Engine editors are already “masters of none”. 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.

Ygg2 4y ago
I recently played with Songs of Conquest editor and Warcraft 3 editor, and they are easy to use but for single purpose. 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.
- ratww 4y ago
  > That's an editor for single game. The more generic you make it, the worse they are to use. ...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.
  - Ygg2 4y ago
    > ..and yet Unity and Unreal are quite popular compared to "rolling your own editor" 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.html https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...
    - ratww 4y ago
      Sorry, but Electron is amazing if the alternative is "nothing". Same for game-specific editors. Some companies can't do it, so in this case Unity/Unreal editors are indeed better. And some engines also don't have the manpower to do engine-specific editors, so if something already existed it would be by definition better to the world. 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.