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

Linux for "real work"

Windows for gaming (no-frills setup) and music production (much easier and less clunky low latency setup, way more availability of free synths etc)

I absolutely adore Linux for everything it has done to my career but I cannot drop my Windows system yet.

For what it's worth, I used to have that, and I am happy I don't anymore. Having two separate computers for gaming and work has been very positive to both my work and gaming experiences. I recommend this to anyone who can afford it.. even if you work on Windows.

That would not buy food on the table. Most money comes from Windows and what games should be optimized for.

See r/choosingbeggars for more entertaining stories on the "value" of "publicity".

It does not. Take a look at the Steam games supporting Linux. There's thousands of them, it's not special.

It's easy to think that a truly cross platform game that has Linux as a first class citizen would make a lot of stir. But I used to play Heroes of Newerth years ago when Linux support were way worse than today. I also read HN then.

I never saw any special treatment for that even tho I loved the game and it worked really, really good on linux.

Searching on algolia just proves my point: https://hn.algolia.com/?query=heroes%20of%20newerth&sort=byP...

I simply do not buy the story that just because you release it on Linux, have good linux support etc it will spread like wildfire.

S2Games, which made HoN, made a superior MOBA imo but none of my friends play it anymore. They play Dota2 tho. I think the reality of the situation is that no one cares about if a game run on linux or not except extreme nerds that would never use Windows and go through the daily struggle that is desktop Linux.

I used to be one of them, nowadays I only use Windows.

When supporting a platform can mean debugging and submitting patches for a users graphics drivers in exchange for a shockingly low conversion rate, it's an easy no for me.

PS I built and maintain an Enterprise AWS GPU app on Ubuntu and the platform is great. But it was very non trivial to get working.

PPS if you spend less than $150/yr combined on all software purchases (including mobile/console) please don't make a case for Linux gaming. TuxRacer is your apotheosis.

Heck, I'm mostly on Linux but boot into Windows for gaming... I'd probably continue to do so, even if the games were released for Linux just for that extra performance and significantly less chance too run into an obscure issue with my setup.

If you ported your game to the Atari ST or the Amiga you'd get more press and probably more sales.

This particular game (Planetary Annihilation) was designed with Linux support in mind from the very beginning; as the person who wrote the tweets notes, he and numerous others within the company were huge proponents of supporting Linux. As events proved, it didn't work out for them.

the thing is microsoft really painted themselves into a corner. ya see windows was made for all sorts of skullduggery to occur , this was supposed to be a boon for MS but they punched so many holes in W32 that it was secure as a sieve, I know this first hand as i have spent a major amount of time decompiling and snooping through the binaries. the file structures in a windows OS has big voids of zeros for padding, leaves lots of room to insert malcode and fix the file headers, Thread Local Storage is neat, a thread can move data packets through its kernel objects to other objects or static files on swap. And the alternate data paging that win executable files may have is just mindblowing. a file {any W32/W64 file} that every one expects to do one thing can be trojaned by the system as a feature using alternate data streams in a file! IT GOES ON AND ON this and win10 is why i left windows and gave linux a serious try and never looked back. Linux runs games and keeps getting better at it with no cat and mouse game of you modding system files so things work and having MS updates demodd them and then prevent you from making thing workable without major klugeing around.

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?

You could also think that, because of WINE, Windows is first class and then they check Linux with Wine.

Depends on the perspective.

PS. Yes, steam detects Wine

Put me in the skeptical camp, I've been hearing the same line with wine support for nearly 2 decades and never found it to be remotely true.

I've had enough trouble getting the actual linux supported games to work. Some work with gnome+wayland, others only work in gnome+xorg, some silently fail, some just freeze, open source AMD drivers still crash the whole machine, etc.

That is especially true if you are forced to use professionally maintained Linux without root access.

You almost convinced me so I checked out ProtonDB, and found out you're overstating things.

Only 50% of games are rated "gold+", and most of those are native Linux versions. Most Windows-only games have issues.

https://www.protondb.com/

- In a 16-player game, each player can operate thousands of units across multiple planets orbiting a star, and afterwards, you can replay the match exactly within your own copy of the game.

- The planets themselves were mobile battlefields which could be destroyed, moved, and weaponized.

- The path-finding for those thousands of units crashing into an opposing army of thousands of units is smooth and there isn't total chaos on the field.

But the team also made some really questionable bets that ultimately doomed the title.

- Then, for some reason, they used an out-of-proc UI compositor to draw the 2D elements that would fork one process per layer IIRC and drop interaction events, and broke the tool that the players use to interact with the wonderful simulation.

- Then, for some worse reason, they launched it like this, and reaped the terrible early reviews that doomed the title. Even after patches resolved the issues, the long-term damage was done.

it is a blessing to be able to work with a different paradigm than piano roll and with such modern tooling (renoise supports vsts, rewire integration and whatnot), being essentially a supercharged tracker.

libcurl may or may not be a good example but surely all software has dependencies that isn't shipped with OS. In Linux case the special pain is, library that is shipped with OS might be outdated but bundling compiled lib/o/so files should work.

I did this once with a ruby gem that had particular c++ dependencies that kept breaking when the build machine had different library versions than the production machines. If you aren't integrated directly with the development of a linux distro, it's best not to use their packages as runtime dependencies, since they really only consider their own use before changing things up.

I'm confused. GNOME is a desktop environment. It implements a task bar, a control panel, a way to set your desktop wallpaper etc. Why would you ship GNOME?

Maybe you meant shipping a proprietary application that uses a GTK version that is different than the OS-provided GNOME uses?

If so, of course you can. GTK is a bunch of shared objects that generate system calls, X messages, etc. It has no reason to interfere with the OS-provided GTK as long as it's got everything it needs in your bundle.

I do agree that shipping your glibc is "the road to hell" and shipping with the glibc could be qualified as "shipping in the form of its own Linux distro", as amusing as that sounds :) But that's the price of freedom you pay if you want to draw your platform boundary at the kernel -- you need to ship the whole userland! Where's the surprise in that? That means you need to understand the interactions between different version of /usr/lib64/opengl/nvidia/lib/libGLX_nvidia.so.0 (that you need to ship) and nvidia.ko (that is nvidia's binary driver loaded by the kernel, that you do NOT ship)

That's what people mean when they say they "are targeting Linux", even when they don't really understand the kind of work that that statement entails :)

Linux is an OS kernel. I'd wager it's the most popular one by far, in terms of the number of platforms that uses it.

Saying that "Linux is fragmented" is the wrong way to look at the problem. One should rather realize that Linux is just and OS kernel that is used by countless platforms. It's up to the developer to draw platform boundaries and focus engineering effort on the chosen ones.

If you need to support GNU/Linux with glibc-2.25, then you need to set up your testing bench to accommodate that. If you need to have native look and feeling in ubuntu, kubuntu and lubuntu, you already have 3 platforms with at least 2 LTS versions that you need to test with.

Each platform has its own quirks. Linux distros are the ones with the least amount of quirks, but in exchange we get many many platforms, because it's so easy to create them.

I guess that's life :)

The actual difference is that Visual C++ and XCode (presumably) automate most or all of this, since this is the standard way of compiling and distributing applications for those platforms. In contrast, Linux development tends to revolve around software that can be recompiled for each distribution, so the tooling is going to be optimized around a workflow of relying on system-wide libraries and binaries and other data managed by a package manager.

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

I used to but I'm switching to a different model

> Do you do a separate AppImage for each plugin?

no, they are just loaded as .so / .dll / .dylib in the ~/Documents/score/addons folder. They can't have further dependencies though.

Have long given up on dual booting. Granted much of my gaming is also done on consoles, Mac gaming support is better than ever outside of still generally anemic GPUs (and who knows what will happen when they move to ARM… a great many games will be orphaned in x86 forever -- e.g. will Starcraft HD get ported to ARM?)

Thank you, to all the indies (and open source engine porters) who have supported Mac over the past 14 years!

From the linked series of tweets:

"In the end they accounted for <0.1% of sales but >20% of auto reported crashes and support tickets (most gfx driver related)."

"So yes, fragmentation is still totally an issue."

"We eventually laid out a guide with known good versions of Linux and graphics drivers, but it didn't matter. Part of the allure of Linux is the customizability, so few actually stuck to it, and generally wanted to run the game on older hardware we didn't support."

However that niche is way too small to be worth it.

Linux support for Optimus and friends is abysmal, I agree. When I say good things about Nvidia's Linux support, I am referring to their discrete desktop and workstation cards.

On the driver side, a lot of the features and performance advantages of Nvidia cards are rumored to be largely implemented in software. (Think of things like having a really good optimizing compiler for shaders.) Open sourcing that code would allow other brands to copy a lot of their techniques.

On the application side, Nvidia produces a lot of developer tools (like CUDA) that are either tied to or heavily optimised for Nvidia hardware.

All this means that Open Source is largely antithetical to the way they do business.

OTOH, ATI Linux drivers went through a very rough patch when ATI decided that Open Source meant, "Hey, we can get a bunch of suckers to write drivers for us!" Everyone involved seems to have actually come out the other side stronger for the experience, and I'm very optimistic about their future.

That said, my understanding is that you are committed to Linux, you still get a more robust OpenGL implementation (ATI used to be buggy as sin) and better shader performance with Nvidia hardware/software. The situation is changing rapidly, and I would love to know if the information at the start of this paragraph is out of date.

Now that I've provided an infomercial for Nvidia: I'm willing to defend Nvidia's products, but I'm not really ready to defend Nvidia the company. Even if Nvidia's hardware beats the competition on all the benchmarks relevant to your use case, it's entirely reasonable to prefer choosing a company that is more willing to play nice with the greater community.

Uber gets recurring revenue from their app, so expecting them to provide updates is like expecting a rental property owner to maintain the property--entirely reasonable. Expecting a game developer to release patches years later is like a homeowner calling up the original real estate developer and demanding improvements. Not gonna happen.

(With the obvious caveat that homeowners are allowed to do the work themselves without the original developer's permission, but this about economics, not the absurdities of software licensing.)

"Issues specific to Linux were almost entirely graphics driver related, and unique to the platform."

So somewhat similar to having 0.5% of your pet walking customers complaining about issues you can't do much about, or have to do extra work to make them happy - their doghouse at home is too small, their car has an issue so they can't come and pick up the cat - basically a subset of your customers giving you a whole lot of extra work for very little gain.

There are still problems with nVidia/nouveau, but that's easily solved by not buying their hardware.

The Intel iGPU drivers have also been solid for a long time, though the hardware may not be fast enough depending on the game.

At almost any point in my time using linux there was something "temporarily broken" that would eventually get fixed/improve some time down the road (modems, sound cards, wifi, power-management modes, GPUs, etc), at which point it didn't take long for something new to break.

There are of course those calm eras of peace in between but anecdotally it never seemed to last long until the next nuisance.

I think we should talk more about code escrow, in general.

All these numbers are way higher than 0.1 % though. I admit I just don't believe the OP that Linux sales were 0.1 %. I would believe 1%.

Also my first interpretation of the headline was "Linux users provide valuable feedback!", which matches my experience. I report so many bugs against everything all the time as a Linux user, if a game had a bugtracker I would definitely use it if I encountered a bug. Whether the issues were Linux-specific or not, I don't know.

Finally, my experience with cross-platform development is just not nearly as bad as I keep hearing. I do it. Bundle, and use an already cross-platform library for your GUI or graphics. I admit I don't make 3D games, but I'm super perplexed as to what is supposedly so hard about the cross-platform aspect of it. For my (non 3D) graphics I don't even use electron, just Qt (also perplexed by those thinking electron is the only way to do cross-platform). I've never tried to freeze my code so it will work on future systems (it is open-source and maintained to stay up to date), but I know exactly what I would do if I had to - I would bundle literally everything except glibc and the kernel and call it a day. Would anything trip me up if I were to do that? Am I naive and waiting to be burned by something I don't understand? Maybe - but it seems like the devs complaining about cross-platform development being hard aren't even doing this step.

I know personally, when it comes to purchases on Steam, I've bought ~200 games/applications, and I've probably only installed a third of them.

For example Android software worked on Jolla's Sailfish OS.

Especially when it comes to things like graphics libraries and game engines, stuff like OpenGL, SDL or even higher level engines like Unity are quite popular on both platforms. While you could say this is just due to having cross platform libraries, but the platform specific steps for them (compiling, linking, initialization) are definitely more consistent across Android and Linux than going to Windows for example.

There's being a good citizen. There's wanting to offer support to a small set of customers. Then there's losing money. At some point, you just can't afford to service the long tail.