3 ms·

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

> 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?
    - learc83 5y ago
      An npm like ecosystem sounds absolutely horrible. It’s also not what I thought you were talking about. Many (most?) software engineers (most?) cringe at the state of the npm ecosystem—even if they hold their nose and participate in it. I definitely wouldn’t consider that an improvement to the state of game dev software engineering practices.
      - skohan 5y ago
        I think there are some problems with package managers, and with the culture around NPM in particular, but I think almost everyone would agree that simple and standardized code reuse has been a massive boon to software engineering as a whole. Do you dislike cargo as well or just npm for some reason?
        learc83 5y ago
        It's more a question about degree. I don't mind an app having a few well vetted external dependencies. When it becomes common and accepted for a small application to contain thousands of 3rd party dependencies, I think we've gone way too far. I've worked in languages that had large standard libraries where it was common to only include a few large commercial external dependencies, and I've worked with javascript and ruby on the other end of the spectrum. I don't think one style has a clear productivity advantage over the other. Other than maybe at the very lowest levels of beginning software engineers (even then I'm unsure because of the decision paralysis common for beginners in these ecosystems). As to the original point, however, Unity and other engines already have package managers and asset/code stores. What you're essentially asking for is for Unity to remove many of the features they already include and pull them out into packages. Now you're running up against many of the organizational issues I've already talked about. Not saying it's impossible, in my experience it's just not likely to work out long term.

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?
  - learc83 5y ago
    An npm like ecosystem sounds absolutely horrible. It’s also not what I thought you were talking about. Many (most?) software engineers (most?) cringe at the state of the npm ecosystem—even if they hold their nose and participate in it. I definitely wouldn’t consider that an improvement to the state of game dev software engineering practices.
    - skohan 5y ago
      I think there are some problems with package managers, and with the culture around NPM in particular, but I think almost everyone would agree that simple and standardized code reuse has been a massive boon to software engineering as a whole. Do you dislike cargo as well or just npm for some reason?
      - learc83 5y ago
        It's more a question about degree. I don't mind an app having a few well vetted external dependencies. When it becomes common and accepted for a small application to contain thousands of 3rd party dependencies, I think we've gone way too far. I've worked in languages that had large standard libraries where it was common to only include a few large commercial external dependencies, and I've worked with javascript and ruby on the other end of the spectrum. I don't think one style has a clear productivity advantage over the other. Other than maybe at the very lowest levels of beginning software engineers (even then I'm unsure because of the decision paralysis common for beginners in these ecosystems). As to the original point, however, Unity and other engines already have package managers and asset/code stores. What you're essentially asking for is for Unity to remove many of the features they already include and pull them out into packages. Now you're running up against many of the organizational issues I've already talked about. Not saying it's impossible, in my experience it's just not likely to work out long term.