4 ms·

Game engines inevitably become monoliths because you need that level of integration between components. If you examine a modern game, you'll generally find abou

Game engines inevitably become monoliths because you need that level of integration between components. If you examine a modern game, you'll generally find about 3 different layers in the runtime: - individual subsystems: aside from things like animation and graphics, many engines use externally developed libraries for sybsystems (e.g. retour for navigation or bullet for physics) - integration layer: this comes across as a mundane glue layer between game code and the subsystems, but it is much more than that. This layer takes care of a lot of things. For example, it's often responsible that the right resources are loaded at the right time across all subsystems, makes triggers work (physics collision handler to trigger events/changes in other subsystems), makes it possible that animation timelines can act across other subsystems, triggering sounds, starting animations, altering object states, and many more things... This layer is also ultimately responsible for keeping the real time guarantees across all subsystems with all the tweaking that entails. - game logic using the facilities provided by the integration layer When you look at the evolution of game engines, the first ones were monoliths that had to do everything themselves because no reusable components existed (e.g. Doom, Quake). A few years later, reusable components started to appear (mostly physics and audio engines IIRC) and for a short time there were a lot of mostly proprietary engines integrating these components. But with games becoming more complex and more demanding, these integration layers also became more and more complex and became a huge investment. That's when the well integrated monoliths won.

skohan 5y ago
I think it could be less coupled than it is. For instance, renderers (esp. back-ends) and physics engines are already largely subsystems which are fairly separate from the rest of the game logic. I can imagine a world where you start with a package manager, and maybe you choose one overarching framework/ecosystem which will serve as a middleware for combining nav meshes and animations etc. in the same world space, handling events etc. the same way you might choose a framework for building a web-server from several popular options. There's no reason you need an extremely heavy-weight closed-source black-box system to serve as the foundational layer.
- gmueckl 5y ago
  This sounds nice on paper. There's just one problem: you mention one overarching framework. That's the game engine. And no matter how you slice it, it's going to be a beast.
  - skohan 5y ago
    Not exactly - I think you can have one of many frameworks serving that glue/structure role, and not all games would need it. I also think you're over-estimating how much of a "beast" you need as a minimal structure for building a game around. I have built a lot of hobby games, and if you're not trying to make an AAA game, you can get really far with a simple game loop, and a few single-header libraries for things like audio and asset loading. That would be one of the advantages of a more modular approach: you could choose a right-size solution rather than working from the assumption that you need this hugely complex monolith to build off of, and potentially not needing a lot of that complexity.
    - learc83 5y ago
      > I also think you're over-estimating how much of a "beast" you need as a minimal structure for building a game around. I have built a lot of hobby games, and if you're not trying to make an AAA game, you can get really far with a simple game loop It’s an organization/people problem. Eventually if your tiny hobby game engine gets big enough people start trying to use it to make the equivalent of AAA games. Then either those users (or your investors if you’ve gone that route like Unity did), start pushing you to support those edge cases. Eventually your elegant modular code is dwarfed by the all the edge case handling that got crammed into the framework—either because it was so performance critical that it had to live there or (the more likely case) because it was much faster to hamjam it in than spend time thinking about how best to architect it.
      - skohan 5y ago
        Idk I think you are describing a way a modular approach can fail, but I'm fairly confident you could find a way to modularize game development to a much greater degree than is currently achieved.
ratww 5y ago
I disagree. I don't think there's anything inherently "tightly-couply" in engines, nor the systems are as coupled as tightly as you describe. In modern engines, the allocation and management of resources is often delegated to an individual subsystem. The fact there are no famous libraries (as famous as Bullet, Retour or BGFX) that do it is no indictment it's not decoupled in practice, it's just not a very sexy area. And even in commercial engines, this subsystem is not as smart (and complex) as one would wish. The triggering parts you mention are handled by Components, in most popular engines. Even without using ECS or something fancy, Unity-style components are already as decoupled as it gets. Sure one component might need to know about others, but that's the nature of the programming and it's already pretty decoupled. Even the editors like Unity are as decoupled as it gets, using reflection instead of knowing the internals of the Components in the integration layer. The fact that most engines only come in big monolithic packages is just a reflection of current development culture, with lack of collaboration between engine writers and lack of standard patterns or formats. Virtually every single standard present in video game engines (models, video, audio, code, serialisation, APIs) come from the outside. It's a young field. But I could perfectly envision a reality where the popular libraries offer components (or whatever) ready to be included into third-party editors, for example. Imagine VST plugins in a DAW, for example. Maybe even a standard map/level format too. But this is not where the money is: Unity and Unreal breaking it and creating an open ecosystem of Components would be amazing, but would also open the floodgates for competition. Their "strength" is in being a single package that looks monolithic from the outside. With a plugin-is system one could create a new editor without creating the other parts, or a new renderer without creating an editor. I could see Godot doing it, maybe, but that's probably not a priority.

skohan 5y ago

I think it could be less coupled than it is. For instance, renderers (esp. back-ends) and physics engines are already largely subsystems which are fairly separate from the rest of the game logic. I can imagine a world where you start with a package manager, and maybe you choose one overarching framework/ecosystem which will serve as a middleware for combining nav meshes and animations etc. in the same world space, handling events etc. the same way you might choose a framework for building a web-server from several popular options. There's no reason you need an extremely heavy-weight closed-source black-box system to serve as the foundational layer.

gmueckl 5y ago
This sounds nice on paper. There's just one problem: you mention one overarching framework. That's the game engine. And no matter how you slice it, it's going to be a beast.
- skohan 5y ago
  Not exactly - I think you can have one of many frameworks serving that glue/structure role, and not all games would need it. I also think you're over-estimating how much of a "beast" you need as a minimal structure for building a game around. I have built a lot of hobby games, and if you're not trying to make an AAA game, you can get really far with a simple game loop, and a few single-header libraries for things like audio and asset loading. That would be one of the advantages of a more modular approach: you could choose a right-size solution rather than working from the assumption that you need this hugely complex monolith to build off of, and potentially not needing a lot of that complexity.
  - learc83 5y ago
    > I also think you're over-estimating how much of a "beast" you need as a minimal structure for building a game around. I have built a lot of hobby games, and if you're not trying to make an AAA game, you can get really far with a simple game loop It’s an organization/people problem. Eventually if your tiny hobby game engine gets big enough people start trying to use it to make the equivalent of AAA games. Then either those users (or your investors if you’ve gone that route like Unity did), start pushing you to support those edge cases. Eventually your elegant modular code is dwarfed by the all the edge case handling that got crammed into the framework—either because it was so performance critical that it had to live there or (the more likely case) because it was much faster to hamjam it in than spend time thinking about how best to architect it.
    - skohan 5y ago
      Idk I think you are describing a way a modular approach can fail, but I'm fairly confident you could find a way to modularize game development to a much greater degree than is currently achieved.

ratww 5y ago

I disagree. I don't think there's anything inherently "tightly-couply" in engines, nor the systems are as coupled as tightly as you describe. In modern engines, the allocation and management of resources is often delegated to an individual subsystem. The fact there are no famous libraries (as famous as Bullet, Retour or BGFX) that do it is no indictment it's not decoupled in practice, it's just not a very sexy area. And even in commercial engines, this subsystem is not as smart (and complex) as one would wish. The triggering parts you mention are handled by Components, in most popular engines. Even without using ECS or something fancy, Unity-style components are already as decoupled as it gets. Sure one component might need to know about others, but that's the nature of the programming and it's already pretty decoupled. Even the editors like Unity are as decoupled as it gets, using reflection instead of knowing the internals of the Components in the integration layer. The fact that most engines only come in big monolithic packages is just a reflection of current development culture, with lack of collaboration between engine writers and lack of standard patterns or formats. Virtually every single standard present in video game engines (models, video, audio, code, serialisation, APIs) come from the outside. It's a young field. But I could perfectly envision a reality where the popular libraries offer components (or whatever) ready to be included into third-party editors, for example. Imagine VST plugins in a DAW, for example. Maybe even a standard map/level format too. But this is not where the money is: Unity and Unreal breaking it and creating an open ecosystem of Components would be amazing, but would also open the floodgates for competition. Their "strength" is in being a single package that looks monolithic from the outside. With a plugin-is system one could create a new editor without creating the other parts, or a new renderer without creating an editor. I could see Godot doing it, maybe, but that's probably not a priority.