> Different engines have different ways of handling the same (or similar things).There is already a lot of common ground, and this is what I'm after. It can even be just component-based, like Unity, which is a great abstraction understood by a lot of people. Engines that are too different from don't have to be supported by such an editor, or would require some extension.
> Either your IDE would need to provide an abstraction on to of all the engines
Why? I don't care if engine X uses this editor or not. I can't force them. I probably wouldn't be able to legally make this work with something like Unity, that uses proprietary file formats.
What I want is a generic editor that can provide enough functionality to be used by future engines, not a Unity/Unreal/Godot replacement. Engines have to do heavy lifting too if they want to support the editor. If they don't, it's their choice.
It's like bob1029 said above: "code your engine against some common editor API rather than the other way around".
> or the game makers would need to specify a lot of attributes for each game object in multiple ways, often one for each supported engine.
This is trivial to do with computers: just do what Unity does with Reflection. Just provide metadata for the types of components, containing the list of attributes. It can be a JSON file or something like that. Or provide something similar to VSCode Language Server where properties can be queried with an API.
Your mistake here is assuming that such a tool would be complete from the get go and replace all competition, without needing to talk to other software. I'm not a venture capitalist, I'm a software engineer. I'm fine with limitations in my tools.
