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.
With engine-based gamedev, you buy into a monolith and that will dictate basically everything about how the project has to be built.
Web dev is theoretically open but in practice runs on Chrome almost exclusively.
10 years from now, if you have built your site according to WC3 standards, theoretically it should just work on every browser out there.
If Unity goes out of business, and their editor is no longer available, good luck getting your unity project to build in another environment.
Likewise one of the things thats most fiddly and annoying in game engines is dealing with implementation of things like OpenGL that are based on standards but not actually implemented to spec across OSes and hardware.
I agree on the dangers of relying on closed-source, proprietary software but if we wanted to avoid that we could just point to Godot as our monolithic example de jour instead.
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).
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.
Unity is reworking their systems to use it by calling it "DOTS" (https://unity.com/dots), and this wouldn't be a HN post without mentioning rust so there is also bevy (https://bevyengine.org/) which is great.
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
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
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.
- 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.
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.
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.
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.
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.
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.
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.
Do you dislike cargo as well or just npm for some reason?
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.
But monolithic game engines won.
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.
Loosely-coupled composable components may be great for producing software quickly, but the approach is basically antithetical to 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.
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.
Composability, separation of concerns, flexibility and simplicity were also some of the driving forces behind ECS.
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.
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.
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.
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'.
Care to elaborate on how that's not programming?
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.
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.
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
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.