Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Game dev: Linux users were only 0.1% of sales but 20% of crashes and tickets

twitter.com

Post reply on HN
Print view View original

311–320 of 415 posts

Re: Game dev: Linux users were only 0.1% of sales but 20% of crashes and tickets

#311

Post by yellowapple »

michaelmrose wrote: post #258
bartread wrote: post #239

Earlier quoted context omitted.

> Have you not seen Steam Play these last few months? Because of Proton the majority of the top 250 highest rated games now run fine on Linux. Whilst this is cool I think it may also, sadly, be commercially irrelevant. Why bother worrying about Linux compatibility when only a tiny (i.e., somewhere between 0% and 1%) number of players/purchasers will run your game on Linux?

Perhaps because you will earn way way more money by making your game cross platform given the 3 consoles and 3 pc platforms that exist and once you have committed to such linux support might only take 1% of your effort.

Correct. If your game can't cope with Linux "fragmentation" (most of which is already abstracted away by Steam, so the remaining "fragmentation" is with hardware, which is the same problem you have with Windows), then you're in for a world of hurt if you try to port to a console with its far-from-ordinary hardware and programming APIs and such.

Re: Game dev: Linux users were only 0.1% of sales but 20% of crashes and tickets

#312

Post by zmw »

derefr wrote: post #232
selectodude wrote: post #218

Earlier quoted context omitted.

Why should I get excited about decent compatibility when I can stick with perfect compatibility? Linux gaming doesn't suck compared to linux gaming 5 years ago. It's still crap compared to Windows.

You’re coming at this from the perspective of someone who wants to set up a PC primarily in order to play games, and probably wants to try out every game under the sun. Of course, you’ll install Windows. Try instead coming at the question from the perspective of someone who already has a Linux workstation (e.g. for work) and wants to do as little as possible in order to play a few games—maybe the ones their friends a…

People who own a Linux workstation at home and just want to play a few games is vastly outnumbered by people who own a Windows desktop at hone and just want to play a few games. Probably at least 100 to 1. And the former group, with the “almost works” compatibility, will be a much bigger maintenance burden per customer.

Heck, I’d bet money that the Linux casual gaming crowd you described is also heavily outnumbered by people who have a dedicated Windows gaming PC (e.g. me, Mac user otherwise).

Re: Game dev: Linux users were only 0.1% of sales but 20% of crashes and tickets

#313

Post by _wmd »

CyberDildonics wrote: post #307
_wmd wrote: post #243

Earlier quoted context omitted.

It's a wonderful idea - on paper, but all that's needed is for one of the many mandatory deps for running a GL program to link against the system libcurl or any other replaced dep and you're back in Crashville again, population 1 - cloth-eared developer

Are there mandatory dependencies for running a GL program that can't work without using the system libcurl shared library? How does that make any sense?

If you distribute and link libcurl v69 dynamically, the dynamic linker symbol table for your process will contain references to v69 symbols. If you then load an e.g. GL driver that in turn links libcurl v42, the GL driver will end up with some combination of v69 and maybe v42 symbols, despite being compiled against v42 headers containing v42 struct sizes and offsets.

Now there is an opportunity for silent memory corruption in your program, one that even once detected, which may not happen for years, cannot easily be fixed without completely rearchitecting the build.

When using a wide variety of system APIs including at least NSS and OpenGL, there is little control over what dynamic libraries end up loaded, the exact configuration will vary across machines

Substitute libcurl for libexpat or libX11 or libstdc++ and the principle continues to apply. I can't think of a good reason something like libcurl would be used by the Nvidia driver or some bizarro embedded board's GL driver, but that doesn't mean the Nvidia driver doesn't now or in the future link it, and if/when that day arrives, the problem lies entirely with the program that mixed random system deps with random self-compiled deps.

Re: Game dev: Linux users were only 0.1% of sales but 20% of crashes and tickets

#315

Post by _wmd »

kentonv wrote: post #306
_wmd wrote: post #300

Earlier quoted context omitted.

It's definitely technically possible to find a hacky combination that works today, but only by shouldering the cost of understanding all the possible deps and symbols and the structure of their underlying objects used by all possible e.g. graphics drivers and X11 libraries now and into the future. You can hack around it today, but it's a fool's game and absolutely not something that can be relied on to continue worki…

There's no other option, though. If you aren't integrated into the distros' builds, then you have no way of getting your binary updated when a dependency makes an ABI-incompatible change -- much less shipping a single binary that works across all distros. The only reasonable option is to determine a subset of your dependencies which offer long-term stable ABIs, dynamically link those, statically link the rest, and ho…

But there is another option, it was mentioned in the original complaint :)

> So it means for every product, have a build for every distro / version combination you want to support.

Of course it's a total pain in the ass, but it's still vastly preferable to unfixable bugs sometime in the distant future

Re: Game dev: Linux users were only 0.1% of sales but 20% of crashes and tickets

#316

Post by CyberDildonics »

_wmd wrote: post #313
CyberDildonics wrote: post #307

Earlier quoted context omitted.

Are there mandatory dependencies for running a GL program that can't work without using the system libcurl shared library? How does that make any sense?

If you distribute and link libcurl v69 dynamically, the dynamic linker symbol table for your process will contain references to v69 symbols. If you then load an e.g. GL driver that in turn links libcurl v42, the GL driver will end up with some combination of v69 and maybe v42 symbols, despite being compiled against v42 headers containing v42 struct sizes and offsets. Now there is an opportunity for silent memory corr…

> If you distribute and link libcurl v69 dynamically,

This whole thread is about avoiding this.

Re: Game dev: Linux users were only 0.1% of sales but 20% of crashes and tickets

#317

Post by thibran »

I was one of the PA Kickstarter supporters and played the game on Linux. It never worked flawlessly (graphical glitches). Today however I can play the latest DOOM (through Steam) on Linux using Vulkan without problems using an AMD card and open-source drivers. There is no reason not to build games for Linux, just use Vulkan and graphic problems are a thing of the past.

Re: Game dev: Linux users were only 0.1% of sales but 20% of crashes and tickets

#318

Post by yellowapple »

freeone3000 wrote: post #271
pantalaimon wrote: post #257

Earlier quoted context omitted.

Running Linux on new hardware is usually a bad idea, due to the nature of the process you have to expect at least a year before divers for new hardware have settled into distributions. Then things should be pretty sweet for quite a while. Unless your hardware is really poplar, things will bitrot away eventually, but expect a 5-10 year sweet spot where everything should just work out of the box.

THIS is the problem. Windows drivers start working on day 1 and continue working. The breaks are when we went to 32-bit drivers in NT and when we disabled real-time hardware interrupts in Vista. Linux needs a driver compatibility story this strong to even start.

On the flipside, while Windows has a greater quantity of drivers available for devices on day 1 of release, Linux tends to have a greater quantity of drivers available for devices at time of install. With Linux, there's no separate step of having to wait for Windows Update to pull the driver, since all the drivers are included alongside the kernel (the exceptions being printer drivers - which aren't developed alongside the kernel - and firmware for wireless NICs if you're going with a strictly-FOSS-only distro).

Meanwhile, I "fondly" remember having to have a USB stick on hand for Windows 7 installs because the default install didn't include wired (let alone wireless) NIC drivers for 90% of the laptops and desktops on which I installed it. Thankfully Windows 10 is better about this (at least on the wired front; wireless drivers are still hit or miss), but still.

Re: Game dev: Linux users were only 0.1% of sales but 20% of crashes and tickets

#319

Post by vetinari »

curt15 wrote: post #227
vetinari wrote: post #139

Earlier quoted context omitted.

Why not pick a "distribution" like org.freedesktop.Platform/18.08 (i.e. pick a flatpak runtime) and support that? It runs on all desktop distributions. Updating supported flatpak runtimes is then on your leisure, not on their release cadence.

How long are flatpak runtimes supported? What is their update policy?

The runtimes are not locked down, anyone can publish theirs (under their domain name, ofcourse), so it depends on who publishes it.

For the freedesktop one, they have following policy[1]:

  - When a new stable release release is done, the changes on that branch will only be:
    - security updates
    - stable releases (tested carefully); no ABI breaks / API build breaks.
    - we will try to keep updating that branch as much as we can

  - We release a new major release every year, only if:
    - There is a ABI break
    - There is a "API build" break (apps might not compile because new major releases of important packages (GCC))
    - Looking at the GCC and other major project cadences, this is likely going to happen annually.

  - We only maintain the current stable release and the previous one, this means:
    - Stable releases get 2 years of security updates
    - We maintain maximum 3 releases at any given time:
      - Development
      - Stable
      - Old stable
[1] https://gitlab.com/freedesktop-sdk/freedesktop-sdk/wikis/rel...

Re: Game dev: Linux users were only 0.1% of sales but 20% of crashes and tickets

#320

Post by derefr »

zmw wrote: post #312
derefr wrote: post #232

Earlier quoted context omitted.

You’re coming at this from the perspective of someone who wants to set up a PC primarily in order to play games, and probably wants to try out every game under the sun. Of course, you’ll install Windows. Try instead coming at the question from the perspective of someone who already has a Linux workstation (e.g. for work) and wants to do as little as possible in order to play a few games—maybe the ones their friends a…

People who own a Linux workstation at home and just want to play a few games is vastly outnumbered by people who own a Windows desktop at hone and just want to play a few games. Probably at least 100 to 1. And the former group, with the “almost works” compatibility, will be a much bigger maintenance burden per customer. Heck, I’d bet money that the Linux casual gaming crowd you described is also heavily outnumbered b…

"People who own a Linux workstation at home and just want to play a few games" make up a disproportionately large amount of the developer-base for pretty much any software, though, including games. It doesn't matter if none of your users care about a particular feature, if a fair number of your own devs do.
Post reply on HN