I'm painfully aware of this problem. I'm writing a metaverse viewer in Rust, to connect to the Second Life / Open Simulator servers and get better performance and look from that 20-year old technology. A metaverse viewer has the problems of both an MMO game client and a web browser. It works much like an MMO client, but it's more general. All the game logic and content come from the server. It faces most of the overload problems a web browser faces. Plus some of the hostile content problems.<p>I can use many library-type components from game ecosystems. But I can't use the big game engines, Unity and Unreal, because they assume a workflow that uses their own editors, their own networking, and their own formats. So I'm forced to glue libraries together. Some of which I have to write.[1] Most of it is little stuff. Too much little stuff.<p>That section about struggling to get open source library maintainers to fix things is spot on. I have Github issues open for six libraries. If I open the hood on one of those libraries, I could spend months getting deep enough to contribute. I can only do so much.<p>[1] <a href="https://github.com/John-Nagle/serde-llsd" rel="nofollow">https://github.com/John-Nagle/serde-llsd</a>
How are you supposed to make a level for a game if the engine doesn't support editing levels? A big part of the level is that it integrates features of the engine directly into the level, e.g. static light shadow rendering.
This post hits home. It's true that if you want to make a more framework-ey library it is easy to end up maintaining a lot for controlling the developer experience. It is really sobering since it means a limit to reuse.
> It gets so much worse though. Suppose you need that bug fix from your dependency, or worse, want a shiny new feature to unblock your work?<p>> Roll a d12 to determine what happens:<p>> ... (a lot of examples of no attention being given to the issue)<p>Personally, I'm all for open source, but to me this seems inevitable when you expect people to solve your requests and issues with (quite possibly) no compensation.<p>That's a situation where paid support of any sort with SLAs would help mitigate almost all of these things. Similarly, if you couldn't get a contract from the current maintainers of the project (or couldn't find those maintainers in the first placE) then it would be telling, that you should probably look elsewhere.<p>Then again, curiously, open source projects rarely if ever offer paid support and using closed source libraries comes with a wholly different set of risks.<p>It does seem like it would be a reasonably lucrative area, though: "Pay us X$ per month to have your issues reviewed within Y hours." Or maybe even just allow the interested parties to donate money towards the resolution of particular issues that matter to them: "So far Z$ has been donated towards the solution of this particular issue. This issue has the #1 highest amount of donations and should be given priority."
Game engines are not good in general, because they do too many things. In my view it's better to pick libraries that do just what you need.<p>It gets a bit worse when you need to write a functionality that is specific to your game, and it becomes too dependent on a certain engine or library, so you can't switch to another library or engine.<p>Unreal and unity are monsters that allows beginners to have quick access to a high end rendering system, but then it doesn't leave enough room to add new cool things, like cool gameplay, a good multiplayer system, etc, when you want to ship on console who have limited memory.<p>I'm quite curious about the unreal engine and how fortnite uses it, because PUBG is a similar game, but its performances are quite bad, so it is an easy demonstration that a rich engine doesn't mean your game will be a smooth experience if your developers are not experts, because expert developer can write a better home made engine instead of paying for a rich engine.<p>These are the good reasons why I don't want to use all-in-one solutions, and this applies for web frameworks too. What's even worse, is that those big things don't just enforce a programming style, they also make it difficult to migrate your code elsewhere.
> GitHub is littered with failed projects taking this approach...<p>I would argue this is because most of the developers trying to make these game engines are hobbyists or students. Most professional software engineering these days is all about gluing packages together so anyone with modest work experience shouldn't have trouble with this.
I wish the term "game engine" would be better defined. Somehow this now means "the whole package", an integrated product like Unity, UE or Godot which includes all tooling required to create and publish games. This isn't an engine, it's a whole "Gamedev IDE", in spirit much closer to Photoshop than ImageMagick. Or as car analogy: nobody calls a whole car an "engine", even though every car has one.<p>The original meaning of "game engine" which made much more sense was: "the actual code which enables the game to run", e.g. just the runtime parts, the tiny piece of code that's dangling off the end of the asset pipeline ("tiny" relative to the work that needs to go into authoring tools and asset pipeline).<p>> Let's begin with something controversial: a stack made for a single game is not a game engine.<p>...controversial indeed :D