Comment by KronisLV | Hacker News Reader

Comment by KronisLV | Hacker News Reader

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

> Roll a d12 to determine what happens:

> ... (a lot of examples of no attention being given to the issue)

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.

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.

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.

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."

Interestingly "You patch the issue and ship the patched library in your game" is not on the list.

Comparing to popular game engine Unity, let's say you are making a game that uses time-travel dead-reckoning netcode and polls inputs at 60hz. So you'd like to poll inputs at 60hz even if the game is rendering at 20hz, and you'd like to send those inputs in UDP packets immediately, not up to 50ms later than you got them. You don't need to roll a d12, we already know what happens: you start waiting in June 2005 for the ability to poll inputs at 60hz while rendering the game at some other rate, occasionally posting about this issue on the official forums. You continue waiting for at least *17 years*. It's a good thing you didn't depend on an open-source library instead!

Isn’t Unity’s code available? Unreal’s is, at least. It’s not quite the same as having official support and you don’t have the same rights as in open source, but you can at least change the code and fix it yourself if you really need to (with the difficulty of understanding a complex codebase, but that’s the case in open source engines too)

A post about releasing the source of the editor from 2018 says "the main engine will remain proprietary for the foreseeable future."

The other commenter answered it (that unity’s source costs money to get access to), but my comment wasn’t about whether it’s proprietary or not, but rather if the source is available/accessible. Unreal’s source code is on GitHub, but it’s still proprietary. You cannot redistribute it or anything like that.

Unity is a lot more choosy about who gets their code than Unreal. To get the source you need to be in at least the $1800/seat/year tier and pay an additional cost that isn't specified.

https://store.unity.com/index.php/compare-plans

Sorta unrelated, but I see the existence of engines to also be sort of a problem for Open Source libraries too. They create sort of a maintenance bottleneck.

In other areas where open source is more prevalent (like web dev), there will be virtually a guarantee that someone running into some long-lived issue within a library will try to patch and contribute back, or in the worst case fork it. Because the end users of frameworks/libraries often have the skills needed to patch those libraries.

In Games, however, there's fewer and fewer true consumer of libraries, since everything go through engines, and there's a lot of consolidation going on. Also, the popular engines aren't targeted at programmers that could fix the libraries, quite the opposite.

That puts a lot of pressure on library maintainers and engine maintainers, as they become the only people able to fix those deeper issues. Bevy of course is a bit lower-level, an others have source-available, but still...

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

Let's remember that half the point of open source/free software is that you have the freedom to fix things yourself. Remember that the reason that Stallman started his free software work was that he couldn't fix a printer because he was dependent on a company that wouldn't give him the source code.

I don't understand how we came to this idea that open source/free software means that people are dependent on each other to fix each other's bugs when the point of it was to get rid of that dependency.

As a gamedev I don’t have time to fix every issue that comes up with the engine. I’m not interested in building a game engine, I want to make games. Unity and Unreal are mature enough that they have understood limitation, workarounds of known bugs, and many, many solutions for common game mechanics. I built game engines for the first half of my career (about 6 years) and it’s a lot of work that could be better spent designing and implementing new game features. This is also why a lot AA and AAA game development are moving to Unreal and Unity because they want to make games not engines.

> As a gamedev I don’t have time to fix every issue that comes up with the engine. I’m not interested in building a game engine, I want to make games.

Not only that, but you might not necessarily be able to fix it yourself either! You might be a developer who can learn to use Godot with GDScript or C# (just an example) and could get comfortable with its abstractions, but might have never worked on your own engine before and might not have the pre-requisite C++ experience not to make horrible mistakes.

Using an off-the-shelf engine is generally supposed to allow you to get by with a team of game developers, instead of needing another team of game engine developers. That's not to say that it's not very lucrative to have the latter for larger organizations, though I think that smaller teams have different concerns.

Reply on news.ycombinator.com