7 ms·

Honestly Unity is now mainstream, but I hate it. It is not the game engine, it is a game engine. One of many ways of doing thingи, and very from what I find ide

by Svoka 5y ago

Honestly Unity is now mainstream, but I hate it. It is not the game engine, it is a game engine. One of many ways of doing thingи, and very from what I find ideal for my workflows.

skohan 5y ago
In many ways game development seems decades behind other types of software development in terms of workflows. Virtually every other discipline in CS has moved towards loosely-coupled, composable components, but game development is still mostly happening against proprietary monoliths.
- DeathArrow 5y ago
  >game development is still mostly happening against proprietary monoliths. Running as a monolith is the most performant way and utilizes hardware to its fullest, which is what you want to do when you run games. Users don't have farms of Pcs and consoles, they don't need to scale.
  - skohan 5y ago
    What about a monolith ensures better performance optimization? And won't general-purpose engines pay a penalty relative to single-purpose engines since they have to optimize for the "average case" game rather than exactly one target?
    - Mikeb85 5y ago
      > And won't general-purpose engines pay a penalty relative to single-purpose engines since they have to optimize for the "average case" game rather than exactly one target? Theoretically, yes. However so many man hours have been put into optimizing engines like Unreal that in reality the answer is no.
      - skohan 5y ago
        I don't agree with this. I mean, UE renderer is the subject of countless hours of effort and optimization. But for instance the startup time (or build time for that matter) of a UE game is quite long and it is fairly easy to beat in a bespoke engine. That's one of the reasons looser coupling would be great. I would love to be able to use the UE renderer in the context of a different engine.
- flohofwoe 5y ago
  I like to call the Unity approach a "Photoshop for games" (which can be a good or a bad thing, depending on perspective and requirements). It's essentially a game-maker UI tool with some support for scripting/coding. The runtime that's dangling off the end of the asset pipeline and editor is much less important (even if this hurts the pride of hardcore engine coders) ;) PS: a standalone "bring your own engine" hackable Unity editor would be great, but I guess that doesn't quit fit into Unity's business model
  - meheleventyone 5y ago
    > PS: a standalone "bring your own engine" hackable Unity editor would be great, but I guess that doesn't quit fit into Unity's business model I’ve been thinking about this a lot as I want to write more standalone games with minimalist runtimes but also don’t want to give up the QoL you get with a decent scene editor with runtime inspection and “fiddling”. One thing that intrigues me is the recent rash of tools made with Godot as it has a pretty good UI system that is used to make their own editor: https://itch.io/c/651672/tools-made-with-godot-engine https://itch.io/c/651672/tools-made-with-godot-engine I could see a decent open-source game editor made this way as well. But don’t have the energy to actually do it myself.
- gmueckl 5y ago
  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
- owalt 5y ago
  Is it really because game development is "decades behind", or just because games are among the few pieces of software still developed against hard performance constraints? Loosely-coupled composable components may be great for producing software quickly, but the approach is basically antithetical to performance.
  - skohan 5y ago
    I don't think that's true. If anything a tightly-coupled monolith can hurt performance. For instance have you ever read through the movement code in Unreal? There are a million branching cases for every kind of movement: on particular slopes, swimming, flying etc. If your game doesn't have underwater motion, you're still executing those branches just because other games might need it. General purpose game engines are by necessity not optimized for performance. They're optimized for being able to support every arbitrary type of game.
- surfmike 5y ago
  The same shift has been happening on game engines, with Entity component systems.
  - DeathArrow 5y ago
    ECS is just data oriented design. The data is better layed out to enable parallel execution and to minimize cache misses. OOP is not a good fit for performance. I would even argue that OOP is not even good for decreasing complexity and ease of maintenance.
    - ratww 5y ago
      Similar to your reply above about microservices, there are more benefits to ECS than data-oriented design. Composability, separation of concerns, flexibility and simplicity were also some of the driving forces behind ECS.
- orangeoxidation 5y ago
  > Virtually every other discipline in CS has moved towards loosely-coupled, composable components, but game development is still mostly happening against proprietary monoliths. I'd argue that's because game development is not a CS discipline. Game tech / engine is, but games need more man-hours in artistic disciplines like modeling, animation, level-design, story-telling etc. than they need for cs. There is a lot of 'game middleware' out there for the CS part of the equation. Game engines themselves are not monoliths, using 20+ middleware components is common. The game design part is done using a monolithic interface to the technology (the engine), but that's because that job is not 'programming'.
  - phlalexsh 5y ago
    > The game design part is done using a monolithic interface to the technology (the engine), but that's because that job is not 'programming'. Care to elaborate on how that's not programming?
    - ratww 5y ago
      Game Design and programming are two completely different sets of abilities. Programmers can design a game, and game designers can do some programming, of course. But in modern days, the core way that both professionals interact with engine editors is completely different. Game Design in general is closer to art or being director than to programming.
    - orangeoxidation 5y ago
      My wording might have been wrong there. There's artists building the game experience and CS people building the game technology. The latter do use and reuse smaller software components to build the level editors, scripting interfaces, particle physics, path-finding, illumination, etc. The engine. This job is very much like other fields of software development, not actually behind. The first might write code (e.g. scripting), but they are generally doing so in a restricted 'monolithic' environment provided to make their job easier. They do not have to build the technology, they can just direct it, if that makes sense. Their job isn't typical software development, more content development, thus it seems a bit alien, behind from a software developer's perspective.
- MattRix 5y ago
  Many game devs, myself included, would argue that loosely coupled code makes for messier and less performant code in most situations. It certainly becomes harder to reason about code once the execution flows through dozens of different functions (often in different files) rather than through a single monolithic function. This is somewhat obvious when you think about it, yet people still insist on breaking long but perfectly readable functions into tons of tiny parts for some reason. In many game dev circles there has also been a strong push towards “Data Oriented Design” where the focus is on manipulating the memory as directly as possible, rather than creating abstractions. See this talk by Mike Acton: https://youtu.be/rX0ItVEVjHc https://youtu.be/rX0ItVEVjHc
  - skohan 5y ago
    I would argue DOD as it's often applied to game design is all about loose coupling. There's no reason you couldn't leverage a lot of loosely coupled components in a program structure which mostly consists of large flat functions.
- meheleventyone 5y ago
  A general purpose game engine is more like a web browser than other software projects. And perhaps one of the few projects outside of an OS with more complexity. An engine is intended to be a place to run arbitrary software, across multiple platforms and also an environment to build it on. There is still a whole bunch of reusable components built on top as there is with the web.
  - skohan 5y ago
    It's in imperfect analogy. You could argue there's nothing less tightly coupled than web dev. There you choose whatever tools you want as long as you can get it into HTML/CSS/JS at the end of the day. With engine-based gamedev, you buy into a monolith and that will dictate basically everything about how the project has to be built.
    - cornel_io 5y ago
      Web dev is not tightly coupled, but browser dev is, and when you do web dev you're essentially buying into a set of monoliths that have finally after 30 years come together by committee just enough so that you only have to conform to one single way of doing web dev. Javascript has quite seriously sucked for a long time and only recently got a bit better, and HTML and CSS are still trash, so don't talk to me about "dictate basically everything" as if that's not the case there, too. Unity is the equivalent of a browser, not an app or even app framework. It just lives in a world where the competitors haven't done the committee thing to ensure interop (and never will).
      - skohan 5y ago
        This is an extremely strange comparison to me. Web is a standards-based, implementation independent platform. That is completely, categorically different from Unity, which is a proprietary tool for making applications. Unity isn't the browser, it's web-flow or square-space. Except it doesn't give you artifacts which are interoperable with other tools at the end.
    - meheleventyone 5y ago
- thejosh 5y ago
  The most exciting thing happening in game development is the move towards ECS (Entity Component Systems). Hopefully with games like Overwatch using it (and other big names), it'll see an uptick in usage. Unity is reworking their systems to use it by calling it "DOTS" (https://unity.com/dots https://unity.com/dots), and this wouldn't be a HN post without mentioning rust so there is also bevy (https://bevyengine.org/ https://bevyengine.org/) which is great.
  - flohofwoe 5y ago
    ECS (or what's called "ECS" nowadays) is mainly useful if you need to deal with thousands of similar data items each frame. Not many games need that outside of specialized systems like particle systems.

by Svoka 5y ago

Honestly Unity is now mainstream, but I hate it. It is not the game engine, it is a game engine. One of many ways of doing thingи, and very from what I find ideal for my workflows.

skohan 5y ago

In many ways game development seems decades behind other types of software development in terms of workflows. Virtually every other discipline in CS has moved towards loosely-coupled, composable components, but game development is still mostly happening against proprietary monoliths.

DeathArrow 5y ago
>game development is still mostly happening against proprietary monoliths. Running as a monolith is the most performant way and utilizes hardware to its fullest, which is what you want to do when you run games. Users don't have farms of Pcs and consoles, they don't need to scale.
- skohan 5y ago
  What about a monolith ensures better performance optimization? And won't general-purpose engines pay a penalty relative to single-purpose engines since they have to optimize for the "average case" game rather than exactly one target?
  - Mikeb85 5y ago
    > And won't general-purpose engines pay a penalty relative to single-purpose engines since they have to optimize for the "average case" game rather than exactly one target? Theoretically, yes. However so many man hours have been put into optimizing engines like Unreal that in reality the answer is no.
    - skohan 5y ago
      I don't agree with this. I mean, UE renderer is the subject of countless hours of effort and optimization. But for instance the startup time (or build time for that matter) of a UE game is quite long and it is fairly easy to beat in a bespoke engine. That's one of the reasons looser coupling would be great. I would love to be able to use the UE renderer in the context of a different engine.
flohofwoe 5y ago
I like to call the Unity approach a "Photoshop for games" (which can be a good or a bad thing, depending on perspective and requirements). It's essentially a game-maker UI tool with some support for scripting/coding. The runtime that's dangling off the end of the asset pipeline and editor is much less important (even if this hurts the pride of hardcore engine coders) ;) PS: a standalone "bring your own engine" hackable Unity editor would be great, but I guess that doesn't quit fit into Unity's business model
- meheleventyone 5y ago
  > PS: a standalone "bring your own engine" hackable Unity editor would be great, but I guess that doesn't quit fit into Unity's business model I’ve been thinking about this a lot as I want to write more standalone games with minimalist runtimes but also don’t want to give up the QoL you get with a decent scene editor with runtime inspection and “fiddling”. One thing that intrigues me is the recent rash of tools made with Godot as it has a pretty good UI system that is used to make their own editor: https://itch.io/c/651672/tools-made-with-godot-engine https://itch.io/c/651672/tools-made-with-godot-engine I could see a decent open-source game editor made this way as well. But don’t have the energy to actually do it myself.
gmueckl 5y ago
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
owalt 5y ago
Is it really because game development is "decades behind", or just because games are among the few pieces of software still developed against hard performance constraints? Loosely-coupled composable components may be great for producing software quickly, but the approach is basically antithetical to performance.
- skohan 5y ago
  I don't think that's true. If anything a tightly-coupled monolith can hurt performance. For instance have you ever read through the movement code in Unreal? There are a million branching cases for every kind of movement: on particular slopes, swimming, flying etc. If your game doesn't have underwater motion, you're still executing those branches just because other games might need it. General purpose game engines are by necessity not optimized for performance. They're optimized for being able to support every arbitrary type of game.
surfmike 5y ago
The same shift has been happening on game engines, with Entity component systems.
- DeathArrow 5y ago
  ECS is just data oriented design. The data is better layed out to enable parallel execution and to minimize cache misses. OOP is not a good fit for performance. I would even argue that OOP is not even good for decreasing complexity and ease of maintenance.
  - ratww 5y ago
    Similar to your reply above about microservices, there are more benefits to ECS than data-oriented design. Composability, separation of concerns, flexibility and simplicity were also some of the driving forces behind ECS.
orangeoxidation 5y ago
> Virtually every other discipline in CS has moved towards loosely-coupled, composable components, but game development is still mostly happening against proprietary monoliths. I'd argue that's because game development is not a CS discipline. Game tech / engine is, but games need more man-hours in artistic disciplines like modeling, animation, level-design, story-telling etc. than they need for cs. There is a lot of 'game middleware' out there for the CS part of the equation. Game engines themselves are not monoliths, using 20+ middleware components is common. The game design part is done using a monolithic interface to the technology (the engine), but that's because that job is not 'programming'.
- phlalexsh 5y ago
  > The game design part is done using a monolithic interface to the technology (the engine), but that's because that job is not 'programming'. Care to elaborate on how that's not programming?
  - ratww 5y ago
    Game Design and programming are two completely different sets of abilities. Programmers can design a game, and game designers can do some programming, of course. But in modern days, the core way that both professionals interact with engine editors is completely different. Game Design in general is closer to art or being director than to programming.
  - orangeoxidation 5y ago
    My wording might have been wrong there. There's artists building the game experience and CS people building the game technology. The latter do use and reuse smaller software components to build the level editors, scripting interfaces, particle physics, path-finding, illumination, etc. The engine. This job is very much like other fields of software development, not actually behind. The first might write code (e.g. scripting), but they are generally doing so in a restricted 'monolithic' environment provided to make their job easier. They do not have to build the technology, they can just direct it, if that makes sense. Their job isn't typical software development, more content development, thus it seems a bit alien, behind from a software developer's perspective.
MattRix 5y ago
Many game devs, myself included, would argue that loosely coupled code makes for messier and less performant code in most situations. It certainly becomes harder to reason about code once the execution flows through dozens of different functions (often in different files) rather than through a single monolithic function. This is somewhat obvious when you think about it, yet people still insist on breaking long but perfectly readable functions into tons of tiny parts for some reason. In many game dev circles there has also been a strong push towards “Data Oriented Design” where the focus is on manipulating the memory as directly as possible, rather than creating abstractions. See this talk by Mike Acton: https://youtu.be/rX0ItVEVjHc https://youtu.be/rX0ItVEVjHc
- skohan 5y ago
  I would argue DOD as it's often applied to game design is all about loose coupling. There's no reason you couldn't leverage a lot of loosely coupled components in a program structure which mostly consists of large flat functions.
meheleventyone 5y ago
A general purpose game engine is more like a web browser than other software projects. And perhaps one of the few projects outside of an OS with more complexity. An engine is intended to be a place to run arbitrary software, across multiple platforms and also an environment to build it on. There is still a whole bunch of reusable components built on top as there is with the web.
- skohan 5y ago
  It's in imperfect analogy. You could argue there's nothing less tightly coupled than web dev. There you choose whatever tools you want as long as you can get it into HTML/CSS/JS at the end of the day. With engine-based gamedev, you buy into a monolith and that will dictate basically everything about how the project has to be built.
  - cornel_io 5y ago
    Web dev is not tightly coupled, but browser dev is, and when you do web dev you're essentially buying into a set of monoliths that have finally after 30 years come together by committee just enough so that you only have to conform to one single way of doing web dev. Javascript has quite seriously sucked for a long time and only recently got a bit better, and HTML and CSS are still trash, so don't talk to me about "dictate basically everything" as if that's not the case there, too. Unity is the equivalent of a browser, not an app or even app framework. It just lives in a world where the competitors haven't done the committee thing to ensure interop (and never will).
    - skohan 5y ago
      This is an extremely strange comparison to me. Web is a standards-based, implementation independent platform. That is completely, categorically different from Unity, which is a proprietary tool for making applications. Unity isn't the browser, it's web-flow or square-space. Except it doesn't give you artifacts which are interoperable with other tools at the end.
  - meheleventyone 5y ago
thejosh 5y ago
The most exciting thing happening in game development is the move towards ECS (Entity Component Systems). Hopefully with games like Overwatch using it (and other big names), it'll see an uptick in usage. Unity is reworking their systems to use it by calling it "DOTS" (https://unity.com/dots https://unity.com/dots), and this wouldn't be a HN post without mentioning rust so there is also bevy (https://bevyengine.org/ https://bevyengine.org/) which is great.
- flohofwoe 5y ago
  ECS (or what's called "ECS" nowadays) is mainly useful if you need to deal with thousands of similar data items each frame. Not many games need that outside of specialized systems like particle systems.