Supporting Linux is hard. So is supporting Windows, but if Windows makes up 98% of your customer base, it's justified. 2%? Ehhhhh.
(P.S. I love Linux. See my profile. This is the kind of stuff I deal with every single day.)
[1] https://boilingsteam.com/we-dont-game-on-the-same-distros-no...
You claim I am being "self-centered" but the fact is if you don't provide something that the distros can work with and instead try to route around everybody and ship an untestable blob then that's your fault. The reason everyone tells you to just support Ubuntu LTS is because they are the only ones who have the resources to support all these random binary blobs for X amount of years, and that comes with all the pains associated with it, as you are well aware of.
Alternative view: distros don't provide a stable platform that developers can target.
Expecting every distro to have the exact same release & support cycle is nonsensical.
To contrast, if you take a Win32 game from 2003 that targets DirectX 9, it probably runs fine on the latest Windows releases. (You might have to enable some compatibility mode.)
"BUT BUT BUT if it's packaged with the distro it's no problem." Remember we're talking about proprietary applications (mostly games) here. Having these packaged with distros for years after the devs moved on to the next project is just a pipe dream.
It doesn't mean that there's no such way, but it does mean that attempting to find it is very risky. Making games is already a very high-risk, high-reward industry, do adding this amount of risk to the equation is advice that's insane for all but most successful companies.
One of the ways these companies can reduce risk is actually by using other proven open source components. If they won't even make an effort to try to expand this, then there will never be a well-understood way.
No, it's not - this is an absurd statement. Cloud services get most of their income from big and medium companies, billing tens and thousands of dollars in privately negotiated agreements. Digital Ocean and AWS don't live on single developers paying them $5. All their real money is on B2B.
Multiplayer games either get a flat subscription from all their playerbase, or rely on micropayments. Either way, they spend much less on account management where they interact with customers as individuals, and much more on analytics, where they measure and work with their customers in aggregate. These are completely different business models, that completely shape companies that operate on them.
> Find the pain points your business customers/partners are having and then charge for solutions.
Games are not solving any problems - they are entiertainment product. I've seen people who have tried to reason about games in the terms you're using, and it always yelded hillarious (but also sad) results.
Which might be one of the reasons Linux Desktop is so awful to develop for.
You wonder why people ignore your platform? Saying it isn't actually a single platform and instead is dozens of different platforms just means each of those platforms is even less relevant. Saying you're not just one platform with 10% market share but actually 20 with 0.5% each doesn't make the case for shipping on Linux Desktop any better.
And many proprietary pieces of software license components from other proprietary pieces of software, so that even if they did want to open their code they'd have to strip pieces out of it anyway which doesn't really help the cause of distros integrating it. And even if it did, then the developers are reliant on the maintainers for their relationship to their customers. Have an issue with the product? Oh, it turns out that's because of this patch made by the maintainer of the package for that distro, who now has to be contacted and convinced to fix it, which they may decide not to for arbitrary reasons. Even open source developers have problems with this!
If you need to strip out some parts and there is enough will in the community to replace those pieces that you stripped out, then it will happen. If you have a product that is anywhere near being popular among the FOSS developer communities then I don't think it makes sense for you to claim that this will doesn't exist, or that distro maintainers will lose interest.
For a simple game that uses the entire UE4 stack, you might be able to get away with that if none of your code is Windows-specific and works exactly the same on the Linux distribution you are targeting. Once you start using your own middleware and libraries from outside of the default engine, you need to make sure every single one works across all the platforms you're targeting. Many won't have a Linux compatible version, and those that do may only work against specific distributions and hardware. Even then: Have they changed the window manager? What have else they customised?
There have been many issues with anti-cheat solutions over the years on Linux.
> It's not like they have to do a full run of play-testing for Linux. Just check if it starts, play for 10 minutes and release that.
For a simple game, you may get away with this. Anything larger will require significantly more testing. I've been a producer on large games, and the QA process starts very early on. You don't 'finish' a game and then QA starts - It's an ongoing process that consists of significantly more than just launching a game.
>We know we're a minority so we're willing to put up with bugs
Some people don't see it that way though. People who have paid for a product have the right for it to work properly. Tickets for Linux support are often higher [1], so the time investment against payback can be problematic.
GPU driver support on Linux can also still be problematic. From feature differences against Windows, to crashes. These all take additional development time. Linux developers are often more difficult to acquire in the game dev world. QA even more so.
Game dev is really hard. Some of it is hidden by engines like UE4 on the surface, but as soon as you start digging down into serious development, it's difficult.
> Many won't have a Linux compatible version, and those that do may only work against specific distributions and hardware. Even then: Have they changed the window manager? What have else they customised?
Outside of truly exotic window managers, the biggest issue I've ever seen with ports has to do with dependencies. Flatpack/Snaps solve most if not all of those problems.
> There have been many issues with anti-cheat solutions over the years on Linux.
That's assuming anti-cheat systems are ethical, even. Most games I play I want to be multiplayer, and moddable. Most games I play can do both of those things and work in a cross platform modding language. Not hard. I don't want any anti-cheat systems for a complex game with tons of modding.
The only place anti-cheat systems make sense is with e-sports style games. Of which, the best anti-cheat systems work server side. Anything else is invasive and tantamount to illegal spying. Shame on you, go burn in peeping Tom hell you perverse game dev.
> For a simple game, you may get away with this. Anything larger will require significantly more testing.
I find this incredibly hard to believe. If you are working within the engine the majority of the time, the majority of the game will play wherever the engine works. Which brings us back to one of your first comments:
> For a simple game that uses the entire UE4 stack, you might be able to get away with that
For which games are you not just using the UE4 stack? I.e. what specific problems are game devs normally experiencing causing their code to be non-portable? A bunch of low level assembly code and non standard C++?
> but as soon as you start digging down into serious development
I challenge you to define 'serious' development. That sounds suspiciously like you're wasting your time fighting infrastructure, or just doing things in a non-portable manner. Solving problems is cross platform, so you can't be doing much serious game coding, its probably problem solving for your particular platform (e.g., as I already mentioned, doing a bunch of work in DirectX shaders or something).
If that would just be the money a single developer got for 2-3 months of work, it could still be fine for some regions (not everyone on HN is from US). But with a studio, you also have to spend money on marketing, payroll taxes, rent, and development of future projects, which most likely sell even worse.
So, no, I really don't see how porting to Linux would pay. Most of developers that I talked to who did it admitted that supporting OSX and Linus turned out to be a giant waste.
But outside EA Games e.g., some of the best games I've ever played were written by solo devs in a cross platform engine you may have heard of called Flash. Yeah, not always smooth sailing on Linux, but it worked, pretty well even.
What are the main costs of releasing a Linux version of a game when using Unity or Unreal? My limited experience with Unity has been "check the Linux box, click the build button". It even cross-compiles no problem. People I know tell me Unreal is similar.
It's not like they have to do a full run of play-testing for Linux. Just check if it starts, play for 10 minutes and release that. We know we're a minority so we're willing to put up with bugs. Even if there's only 100 people who'd buy it only if it ran on Linux, that should pretty much cover the couple hours of dev time.