9 ms·

IMO this coupling happens mostly on purpose. It's just vertical integration, Apple style. It seems to be in the interest of "engine" makers to make people think

by ratww 4y ago

IMO this coupling happens mostly on purpose. It's just vertical integration, Apple style. It seems to be in the interest of "engine" makers to make people think that a smaller engine without an editor can't succeed, and that there's no possibility of having a standalone editor. They want control of the whole stack. Game development in general has been plagued by those things. Everything uses proprietary formats, little interoperability, lots of custom stuff. All the parts that aren't proprietary came from the outside (eg: audio/video/image formats) or was leaked by generous developers (Quake MD? and BSP formats being used in newer games/libraries). I would personally love to see more people working on editors that can be used by multiple engines, so that we can see more focused engines grow too, without having to create a whole editor ecosystem. And also editors would grow themselves, and editor-makers would make one without having to make a full engine. I really think it's possible. > ...controversial indeed :D I think the article writer is flat out wrong on this one. The Doom and Quake engines are definitely... well, engines, even though they were only reused later. Sure you can have a more spaghetti "game without engine", but I'd draw the line whether it's reusable/logically separated or not.

flohofwoe 4y ago
100% agree. A popular "bring your own engine" editor would be awesome and would make a lot of sense (just not a lot of 'business sense'). The Unity editor is actually quite hackable and can be used like that, but that's very likely a 'licensing grey area'.
- ratww 4y ago
  I think the open source community can definitely do something cool like this. Although good UX has been historically the Achilles Heel of open source, I believe the focus would help a lot in this regard. No need to worry about the engine part itself. Godot's editor for example is already quite good, and it's only a portion of the engine. Imagine what a team with more focus could achieve. 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 :)
  - bob1029 4y ago
    > 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.
    - ratww 4y ago
      Something web would be really cool, indeed. Not only collaboration, but imagine integrating source control with all that too, that would be an awesome experience. Source Control is not something I enjoyed when I worked in a mainstream engine. > 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.
- 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
- cloudmike 4y ago
  > that's very likely a 'licensing grey area'. 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.
- TOGoS 4y ago
  > 100% agree. A popular "bring your own engine" editor would be awesome and would make a lot of sense (just not a lot of 'business sense'). 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.
  - flohofwoe 4y ago
    > that they have different ways of modeling the world 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).
  - ratww 4y ago
    For most 2D/3D games using ECS, which is something somewhat popular right now, you can definitely easily abstract the editor, in the manner flohofwoe mentioned for example. Same for other systems. 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.
Jare 4y ago
> It seems to be in the interest of "engine" makers to make people think that a smaller engine without an editor can't succeed Phaser for a long time was a runtime engine without an editor, and many people missed that type of capability. Same with Cocos2D. > and that there's no possibility of having a standalone editor. Tiled (for 2d maps) or Spine (for 2d animations) are 2 examples of well known standalone editors. There's no chance to "make people think" that such things can't exist. > It seems to be in the interest of "engine" makers to make people think There's no hidden agenda going on, it's that integrated tools are often much more effective when building things out of multiple different pieces. Wouldn't it be cool to place animated objects in Tiled and see their animation states to properly gauge how they interact with the rest of the scenery in different states? Or use Spine to animate a tilemap going through an earthquake? Custom file formats exist because features differ, and even for similar features, the semantics differ.
- vvanders 4y ago
  Yep, it's been a while since I've been in the industry but with med-large teams your the composition of staff is such that Art/TechArt/Design are where the majority of the time/effort is going to be spent. Last team I was on of ~60, we had 9-10 devs, if I could build tools that made our design or art team more effective that was a better use of my time(within reason of course). Integrated engines just reflect that composition.
- ratww 4y ago
  > Tiled (for 2d maps) or Spine (for 2d animations) are 2 examples of well known standalone editors. Those are a 2D map editor and a 2D animation editor. Apples and Oranges compared to what the editors in Unity/Unreal/Godot do. > There's no chance to "make people think" that such things can't exist. A lot of people in this very thread seem to be under this impression. > it's that integrated tools are often much more effective when building things out of multiple different pieces Integration can happen in different ways. Complete integration (aka being made by the same team and tightly coupled) is not necessary for a great experience. For programming itself we’re already free to choose our editor of choice, and they often integrate quite well. People used to say the same about Visual Studio and C#. > Custom file formats exist because features differ, and even for similar features, the semantics differ. There is a lot of common functionality in modern engines. Not to mention that formats can be extended to contain additional metadata coming from customised parts of the editor. And editors can be extended to allow new formats too. Starting with the automatic assumption that there cannot be a common format is incorrect.
bob1029 4y ago
Decoupling the user interface from the actual engine seems like an excellent idea on the surface. Aside from your post here, has anyone even proposed an "engine agnostic" IDE experience for game dev? I can kinda see how it would be possible to do this - code your engine against some common editor API rather than the other way around. The idea of being able to swap to an entirely different engine but keep all my content, tools, etc is pretty fantastical, but I don't see why it would be impossible.
- vanviegen 4y ago
  > 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.
ohgodplsno 4y ago
It's not just vertical integration for the sake of it. There are many, many, many things that are simply made easier by having every component able to talk to eachother. UE5's particle system can talk to the sound system back and forth, which can trigger gameplay events and send data to the renderer, etc. This leads to extremely complex interactions being rather easy to do, and that is exactly what large games want nowadays. You don't want to painstakingly time your cutscene to begin exactly 2m15s after the beginning of the level because you know that's where the song will begin but shit wait the intro can loop, no, you just have a gameplay event that starts the sound, the sound regularly says "hey, if you're ready, please trigger the cutscene now" and everything works together. Getting this with a bunch of libs glued together is simply impossible. This is a design that was thought of for years before it happened properly.
- ratww 4y ago
  The components are a concern of the engine and the game code, not of the editor. There is nothing preventing components from talking to each other when a generic editor is used. Have you ever played with Unity? Their modular design is generic enough to allow different components to be connected to each other. Not to mention that interconnection between components is often also achieved via code inside each component (example: gameObject.GetComponent() in Unity), which is not really the concern of the editor, but rather of the engine and the game code. > Getting this with a bunch of libs glued together is simply impossible. I really don't see what "bunch of libs glued together" has to do with my comments at all. Are you sure you answered to the right person? Are you answering to the article in general?

by ratww 4y ago

flohofwoe 4y ago

100% agree. A popular "bring your own engine" editor would be awesome and would make a lot of sense (just not a lot of 'business sense'). The Unity editor is actually quite hackable and can be used like that, but that's very likely a 'licensing grey area'.

ratww 4y ago
I think the open source community can definitely do something cool like this. Although good UX has been historically the Achilles Heel of open source, I believe the focus would help a lot in this regard. No need to worry about the engine part itself. Godot's editor for example is already quite good, and it's only a portion of the engine. Imagine what a team with more focus could achieve. 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 :)
- bob1029 4y ago
  > 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.
  - ratww 4y ago
    Something web would be really cool, indeed. Not only collaboration, but imagine integrating source control with all that too, that would be an awesome experience. Source Control is not something I enjoyed when I worked in a mainstream engine. > 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.
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
cloudmike 4y ago
> that's very likely a 'licensing grey area'. 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.
TOGoS 4y ago
> 100% agree. A popular "bring your own engine" editor would be awesome and would make a lot of sense (just not a lot of 'business sense'). 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.
- flohofwoe 4y ago
  > that they have different ways of modeling the world 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).
- ratww 4y ago
  For most 2D/3D games using ECS, which is something somewhat popular right now, you can definitely easily abstract the editor, in the manner flohofwoe mentioned for example. Same for other systems. 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.

Jare 4y ago

> It seems to be in the interest of "engine" makers to make people think that a smaller engine without an editor can't succeed Phaser for a long time was a runtime engine without an editor, and many people missed that type of capability. Same with Cocos2D. > and that there's no possibility of having a standalone editor. Tiled (for 2d maps) or Spine (for 2d animations) are 2 examples of well known standalone editors. There's no chance to "make people think" that such things can't exist. > It seems to be in the interest of "engine" makers to make people think There's no hidden agenda going on, it's that integrated tools are often much more effective when building things out of multiple different pieces. Wouldn't it be cool to place animated objects in Tiled and see their animation states to properly gauge how they interact with the rest of the scenery in different states? Or use Spine to animate a tilemap going through an earthquake? Custom file formats exist because features differ, and even for similar features, the semantics differ.

vvanders 4y ago
Yep, it's been a while since I've been in the industry but with med-large teams your the composition of staff is such that Art/TechArt/Design are where the majority of the time/effort is going to be spent. Last team I was on of ~60, we had 9-10 devs, if I could build tools that made our design or art team more effective that was a better use of my time(within reason of course). Integrated engines just reflect that composition.
ratww 4y ago
> Tiled (for 2d maps) or Spine (for 2d animations) are 2 examples of well known standalone editors. Those are a 2D map editor and a 2D animation editor. Apples and Oranges compared to what the editors in Unity/Unreal/Godot do. > There's no chance to "make people think" that such things can't exist. A lot of people in this very thread seem to be under this impression. > it's that integrated tools are often much more effective when building things out of multiple different pieces Integration can happen in different ways. Complete integration (aka being made by the same team and tightly coupled) is not necessary for a great experience. For programming itself we’re already free to choose our editor of choice, and they often integrate quite well. People used to say the same about Visual Studio and C#. > Custom file formats exist because features differ, and even for similar features, the semantics differ. There is a lot of common functionality in modern engines. Not to mention that formats can be extended to contain additional metadata coming from customised parts of the editor. And editors can be extended to allow new formats too. Starting with the automatic assumption that there cannot be a common format is incorrect.

bob1029 4y ago

Decoupling the user interface from the actual engine seems like an excellent idea on the surface. Aside from your post here, has anyone even proposed an "engine agnostic" IDE experience for game dev? I can kinda see how it would be possible to do this - code your engine against some common editor API rather than the other way around. The idea of being able to swap to an entirely different engine but keep all my content, tools, etc is pretty fantastical, but I don't see why it would be impossible.

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

ohgodplsno 4y ago

It's not just vertical integration for the sake of it. There are many, many, many things that are simply made easier by having every component able to talk to eachother. UE5's particle system can talk to the sound system back and forth, which can trigger gameplay events and send data to the renderer, etc. This leads to extremely complex interactions being rather easy to do, and that is exactly what large games want nowadays. You don't want to painstakingly time your cutscene to begin exactly 2m15s after the beginning of the level because you know that's where the song will begin but shit wait the intro can loop, no, you just have a gameplay event that starts the sound, the sound regularly says "hey, if you're ready, please trigger the cutscene now" and everything works together. Getting this with a bunch of libs glued together is simply impossible. This is a design that was thought of for years before it happened properly.

ratww 4y ago
The components are a concern of the engine and the game code, not of the editor. There is nothing preventing components from talking to each other when a generic editor is used. Have you ever played with Unity? Their modular design is generic enough to allow different components to be connected to each other. Not to mention that interconnection between components is often also achieved via code inside each component (example: gameObject.GetComponent() in Unity), which is not really the concern of the editor, but rather of the engine and the game code. > Getting this with a bunch of libs glued together is simply impossible. I really don't see what "bunch of libs glued together" has to do with my comments at all. Are you sure you answered to the right person? Are you answering to the article in general?