[shmerl]

> It's trivial in the sense that it's low technical risk.

The problem is not in the risk, but simply in the cost itself. It's an extra tax to pay. However quality can also suffer, see below.

> I can't speak for Epic, they are making an engine for every possible game and every possible rendering scene which is a harder problem than what we were doing. But the rendering backend isn't the hard part.

The story of Everspace illustrates my point. They were bitten by multiple issues in OpenGL backend of UE4, and it took Epic a long time to fix some of them. Their resources are limited, and they are more focused on more widespread backends obviously. Which is exactly the result lock-in proponents are trying to achieve.

[DoveBrown]

Sure, there is effort involved, but from my point of view it's a small one (a couple of man months on a project with 50+ coders). I'm going to have to make adjustments between the platforms because the hardware is different. Even on a DirectX PC, you can often have a lot of differences between the rendering scene for Nvidia, AMD and Integrated Intel gpus.

Don't know exactly what issues Everspace had with the UE4, but you want to have a fun night go out with some Epic licensees and get them to tell you war stories of issues they have had when they tried to do something which Epic hadn't done in their games. You're paying Epic for the "battle testing" and often they didn't fight those battles.

Part of the reason I left the games industry is that once you work at studio with an internal engine it is extremely frustrating to work on AAA games without the freedom to walk over to the engine programmer and get them to move the engine closer to what you need.

[shmerl]

> Part of the reason I left the games industry is that once you work at studio with an internal engine it is extremely frustrating to work on AAA games without the freedom to walk over to the engine programmer and get them to move the engine closer to what you need.

Internal engines also on average are less cross platform. Simply because big publishers and shareholders don't want these very expenses that creep into development because of lock-in. That's why many Linux releases for such games use source or binary wrappers, rather than proper native rendering to begin with. This highlights my point above.

[DoveBrown]

I disagree with the characterisation that internal engines are less cross platform because of lock-in, the big publishers don't care about lock-in. It's not part of the calculus in deciding whether to support a platform or not.

A port of a game is more than changing the low-level APIs used to control the hardware. It's the hardware of the platfrom the decides the complexity of producing the port.

Linux is a special case because it's the same hardware as a the Windows. Your market is people who want to play the game but aren't dual booting. Most of the issues with producing your port are going to come down to driver incompatibilities and the fact that every Linux system is set up a little bit differently (the reason Blizzard never released their native Linux WoW client[1]). It's not a big market and there are loads of edge cases.

For big publishers and AAA development, they're not looking to break even or make a small profit. They need to see multiples of return on their money or they aren't going to do it. Using a shim is cheap and doesn't hurt sales enough to matter to them.

[1] https://www.phoronix.com/scan.php?page=news_item&px=OTA0NQ

[shmerl]

I'm looking at publishers who do release Linux games using internal engines. Most of them use binary or source wrapping. Only a minority are implementing proper native rendering in those engines. And I bet it's based on cost considerations like I said above. How would you explain it otherwise?

And I'm sure that cost plays a role when small market is evaluated. The higher is the cost, the less likely such publisher is to care, because prospects of profits are also reduced. So it goes back to my point. Lock-in proponents like MS and Co. benefit from lock-in in slowing down competition growth.

[DoveBrown]

I agree that cost is a consideration of doing the port. From my experience what renderering API is used at the bottom is a very small factor in that cost calculation.

I think where we disagree is that I don't think of the lower level API as being much of a lock in. The better graphic programmers I know have pretty extensive experience of the various flavors of DirectX and OpenGL. The general principles are the same and good programmers move between them easily.

[shmerl]

> I think where we disagree is that I don't think of the lower level API as being much of a lock in.

Lock-in here doesn't mean they have no technical means of implementing other graphics backends, it means that implementation is hard.

A lot of common middleware supports Linux just fine. It's graphics that's usually the biggest hurdle. People have expertise to address it, but it's still a tax to pay. And different distros support is a very minor thing in comparison.

If graphics is not the biggest issue, what is then in your opinion?