4 ms·

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 separ

by 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.
      - learc83 5y ago
        I think you could, but I just don’t know how long it would last. The real benefit of microservices in most cases is that the network acts as an externally enforced boundary layer. There’s no reason the vast majority of time that you need to pay the overhead of using network calls to enforce your boundaries. Yet time an again you see companies willing to pay the microservices tax because it’s just so hard organizationally to enforce modular boundaries over time.
        DeathArrow 5y ago
        >The real benefit of microservices in most cases is that the network acts as an externally enforced boundary layer. Then we have the scalability, then we have composability, then we have different security models, then we have code isolation. There are many advantages to a microservice model. But that doesn't mean the microservice model is good for a game, unless it is backend code.
        learc83 5y ago
        You can have almost all of those benefits without using network calls as your boundary. Nearly every benefit you listed is a consequence of having enforced boundaries, not of microservices specifically. Microservices do provide technical benefits for a small monitory of companies, but for the rest of us it’s almost entirely a solution to organizational/human problems.
        skohan 5y ago
        You couldn't imagine a package-driven ecosystem like npm or cargo catching on for game-dev?
Mikeb85 5y ago
These things exist. Ogre, Bullet/PhysX, Assimp, etc... But monolithic game engines won.
- skohan 5y ago
  To say "won" seems a bit strong. Game engineering is an area of active and fertile development.

by skohan 5y ago

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.
    - learc83 5y ago
      I think you could, but I just don’t know how long it would last. The real benefit of microservices in most cases is that the network acts as an externally enforced boundary layer. There’s no reason the vast majority of time that you need to pay the overhead of using network calls to enforce your boundaries. Yet time an again you see companies willing to pay the microservices tax because it’s just so hard organizationally to enforce modular boundaries over time.
      - DeathArrow 5y ago
        >The real benefit of microservices in most cases is that the network acts as an externally enforced boundary layer. Then we have the scalability, then we have composability, then we have different security models, then we have code isolation. There are many advantages to a microservice model. But that doesn't mean the microservice model is good for a game, unless it is backend code.
        learc83 5y ago
        You can have almost all of those benefits without using network calls as your boundary. Nearly every benefit you listed is a consequence of having enforced boundaries, not of microservices specifically. Microservices do provide technical benefits for a small monitory of companies, but for the rest of us it’s almost entirely a solution to organizational/human problems.
      - skohan 5y ago
        You couldn't imagine a package-driven ecosystem like npm or cargo catching on for game-dev?

Mikeb85 5y ago

These things exist. Ogre, Bullet/PhysX, Assimp, etc... But monolithic game engines won.

skohan 5y ago
To say "won" seems a bit strong. Game engineering is an area of active and fertile development.