4 ms·

> but I don't see why it would be impossible. Different engines have different ways of handling the same (or similar things). Either your IDE would need to pro

> but I don't see why it would be impossible. Different engines have different ways of handling the same (or similar things). Either your IDE would need to provide an abstraction on to of all the engines (making it sort of an engine by itself), 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.

ratww 4y ago
> 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.

ratww 4y ago

> 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.