Personally I'd just respond to stuff like that with "Sorry, but that's a very obscure combination, and as a single indie dev I unfortunately don't have the bandwidth to support that, I can send you a refund if you want".

As long as you're nice about it and don't turn it in to a bland cookie-cutter "corporate" response most people will understand.

As someone who just runs Linux, and occasionally runs some games on it, I'm always a bit annoyed when people report these kind of very specific bugs with old/weird drivers/distros that aren't in the supported platforms list. It turns developers off for completely understandable reasons. It's a shame, because for most people it does usually work.

I run Void Linux, it almost always works, but I'd never report these kind of bugs without testing Ubuntu (or whatever is supported) first.

I suppose I can only speak for myself but I don't see that as an attractive option, and what you're describing is mostly what I did do for the game release I mentioned.

If I sell on Windows (I do) and Mac (I do) then I have to support a certain range of OS versions and ongoing OS releases - even if that means (for example) I have to figure out how to 'notarise' a Mac executable so that a user doesn't have a big scary Security Warning pop-up. Not ideal, but fine. The challenge with Linux is that I would have to communicate against expectations - that I would have to make it clear that when I 'support Linux' it looks different to the support for Windows or Mac. I do genuinely think that 99% of Linux people get this, it's just the 1% that's maybe less forgiving of different standards.

For me, just personally and selfishly, passing the buck to Photon or Wine is an easier sell for my business.

You're looking for the Steam Runtime, not Ubuntu for future projects - it bundles the dependencies into a container similarly to Docker so that no matter what distribution a user is running it'll work for them.

I wonder - what's wrong with supporting just the Steam runtime and that's it? Why deferring to Photon/Wine at all?

Do you mean just support SteamOS? The biggest problem is, as a few other commenters have mentioned, there's no further break-down in categories other than "SteamOS + Linux" (and the url is .../linux). So you can't tell the Steam Store "I only support distro x, y and not z". I can't hide it for those who I am not actually supporting, Steam will advertise it to them regardless.

No, Steam runtime: https://github.com/ValveSoftware/steam-runtime

When your game runs under Steam runtime, the real distribution is (almost) irrelevant - everything in your address space is supplied by the runtime, the things you get from the host system is the kernel/kernel modules and services you talk to via IPC (i.e. X11/Wayland, Pulseaudio).

It solves the problem of what version of what library is installed (if at all, maybe user removed it as "bloat") on the host system. You get known set of binaries that you can test against / coherent SDK target like with Windows or Mac.

Doesn't "X11/Wayland, Pulseaudio" include almost all the surface where my game's bugs will arise? It certainly includes the full-screen bug described by the GGGGP.

That bug would be there with Wine/Proton too. They would run the same display server.

I believe that GOG.com doesn't accept games that rely on the steam runtime; I know some games which have Linux ports aren't available on GOG.com because of this.

Whether this matters is up to the developer. But it's a potential downside.

Yes, this is downside.

Gog is quite contend with just Ubuntu being supported; they are not that different.

Not sure whether that is the only reason why some games are not on Gog though; often Mac ports are missing too. It seems more like missing rights for the ports than technical reasons.

> Not sure whether that is the only reason why some games are not on Gog though; often Mac ports are missing too. It seems more like missing rights for the ports than technical reasons.

I don't know; probably not. But this was the response I got back from the devs of "Expeditions: Conquistador" when I asked if they could release the Linux version on GOG (when I bought it originally I still had a Windows machine).

But Steam only really supports the latest stable Ubuntu. It works on most distros because package maintainers put a bit of work into make it but it isn’t officially supported on them,

That doesn't stop people from making support requests, though, which is the entire problem OP is talking about.

TBF isn't this going to happen no matter what? As a linux user I have absolutely no problem with the OP saying "we don't support that distro, sorry" and closing the ticket.

I don't think so. If Linux isn't natively supported, even if it runs fine via Proton, you're much less likely to receive bug reports directly, because there's less of an expectation that things work without issues. And closing tickets doesn't help with negative reviews—in fact, some users may use that as a reason to give you a "thumbs down" on Steam.

Maybe but he’s talking about having to deal with the requests. Since Steam only supports Ubuntu LTS you can push the blame on them and say something like, “Sorry we develop for Linux via Steam and they only support Ubuntu x.04, feel free to open a ticket with them if you have further trouble.

Which is the sane thing to do.

Valve should just partner with Canonical and release Ubuntu support.

Let the other distros figure out how to get it working there.

Please not Canonical. OG Steam OS was Debian, which was a wiser choice.

Ubuntu is the most common, most widely used Linux based OS. It's the "Windows" of Linux, for good or ill.

Most hardware and software vendors primarily target it.

It might not be hip, but it's what everyone knows.

From the company that leaked data to Amazon through ads in your search? Yeah, no, pass.

Valve could probably buy Canonical outright if it wanted.

Could you say "supports Ubuntu" instead?

Not only did I say that but I also gave the specific Ubuntu version as well!

That's too bad :( As a Linux user, I love it when game studios support Linux and make a point to buy their games more often.

Steam for example has a "SteamOS + Linux" filter so exposing your game as Linux compatible means exposing it to all Linux users.

Almost everything that works on steam works everywhere. Letting the dev specify a supported distro would be a huge misfeature not unlike websites that used check user agens and refuse to work outside of Internet explorer.

People would start pretending to be Ubuntu to install games.

Yes it seems better to whitelist specific explicit Linux-configurations (version, window-manager, sound-setup, etc). Like we officially support this, if you are using something else use the forums to discuss with other users but we will not investigate your issue.

The emails are likely bug reports?

This is unfairly downvoted IMO, because I think you're actually hitting on a very important point. Linux users tend to be enthusiasts, people who love software, and also primarily interact with a community where the "developer/user" is the most important figure, the one whom everything is designed around.

In the Linux community, at least unless a project has a toxic developer (there are a few), bug reports are Always Good. They're how we make the software WE use better on the systems that WE use it on. Even if a report isn't fully actionable (e.g. it's a problem with graphics drivers), the report is often helpful because the bug tracker is probably public and we can try to find workarounds, or at least flag the issue for others.

For closed source commercial software, especially cases where a tiny number of developers are working on the code, bug reports are Always Bad. They represent more work, work that you don't want to have to do, because at the end of the day these are people who already bought the game. You've gotten as much out of them as you're going to get out of them. If they're more trouble than they're worth (someone else in this thread claimed 90% of bug reports out of 1% of purchases), then it's obvious you should just ignore them or not port your game to their platform at all. You'd think this attitude would be different for issues that affect a lot of people: a good bug report can help you fix widespread problems that are hurting your players, but actually even this is rare. See the story of this guy fixing a bug causing 6 minute startup times that affected at least thousands of people using reverse engineering, when the developer ignored the problem for years: https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...

So I think you're right, these are mostly people enthusiastic about a piece of computer software instinctively trying to collaboratively improve it for everyone. But because development is so limited (there's only one person reading bug reports and working on the code), those reports are experienced as frustrating rather than helpful. Worse still, because the software is commercial there may be an unspoken feeling that support is owed for the software because the user paid for it.

> They represent more work, work that you don't want to have to do, because at the end of the day these are people who already bought the game. You've gotten as much out of them as you're going to get out of them.

This is such a bad attitude. The game is supposed to work correctly without any bugs. People who paid money for the game deserve continued support. It doesn't matter how much time and money the developers have to spend, that's their problem.

If the software is defective, consumers should be entitled to a refund. That ought to motivate companies not to release shoddy work.

> The game is supposed to work correctly without any bugs.

This is not real-world software engineering :)

Pretty much any software has bugs; maybe surprisingly to non-programmers, games are especially complex (in primis, architecturally).

In real world, one can realistically talk about, let's say, an acceptable threshold of bugs.

> People who paid money for the game deserve continued support

And this is not real-world (game) business. Whether one likes it or not, there is a per-unit profit, and the corresponding value in terms of support is very limited.

An ideal solution to this is open sourcing games after a certain time (Id Software used to do it), but this is not realistic. I wish it, though!

> That ought to motivate companies not to release shoddy work

One can't really force a company not to do shoddy work. The gaming market is a radically free one, unlike other constrained markets, like internet providers. Customers are actually entitled to have the money refunded, at least on Steam. Gaming journalism actually has been including bugginess in games evaluation for a while, so buyers can decide in an informed fashion.

Which is why developers don't release on Linux, since they would have to test for so many strange driver setups to ensure things works correctly. The bug reports you get from linux are not "this gameplay is bad", but stuff like "my mouse cursor isn't displayed correctly here" which works fine in windows but somehow their setup screws it up. Trying to get graphics to reliably work in all linux versions is a lot of work.

While I agree with the spirit of what you're saying (as a linux user myself) the problem is that we have to recognize that developers have limited bandwidth. Windows is also generating more revenue for them, so it is going to take priority.

Though for an indie game it probably isn't crazy to make the code open sourced and then put those users to work for you. That can really help reduce the burden. But of course opens you up for people stealing your software (which let's also be real, happens anyways).

No, I agree totally with that. I think that the situation that exists, while unfortunate, is pretty understandable from all sides.

its Proton, not Photon.

I recently did exactly this for my game (Industry Idle) on Steam. I added Linux build but pinned a post that says "Linux and Mac support are considered experimental and are supported on best effort basis" (https://steamcommunity.com/app/1574000/discussions/0/3122659...)

Most people are very helpful and quite understanding that as a sole indie developer, it would be hard to support all the configurations. But occasionally I get angry emails and negative reviews about game not running on Linux.

Given the sales (Linux is 1% of the total sales, Mac is 3%), I would say for an indie developer, it makes more sense to put Linux support on a low priority. It is unfortunate for Linux gaming community but it is what it is.

Also even though Proton has come a long way and has become relatively stable - occassionally there are some strange issues (like Steam Cloud sync fails, etc) here and there. But overall the effort is much lower compared to maintain a separate Linux build.

This is partly the fault of Steam. They simple have a single "supported" boolean. It would be nice if you could provide a warning or "partial support" label so that people had these expectations when buying the game.

Right now the flow for the user is 1. See store page 2. Buy 3. Play 4. Hit bug.

This is the moment when they find out that they bought a game that was not in fact supported. That is super frustrating (and possibly legally requires a fix or a refund). If there was a 1.5 step of "This game offers no support for Linux" or "This game offers no support for any distribution except Ubuntu 21.04" then it is much more acceptable, because I accept that detail before purchasing.

Recently stumbled over a game that did that a bit differently. On the steam page there is only support for Windows listed. But it actually downloads a Linux version. That version worked just fine for me, but they say they can't support it, that's why it's not listed. So there is more than single "supported" boolean (and games can list required Linux version in the requirements section I think).

https://steamcommunity.com/app/378720/discussions/0/49012573... is their explanation, https://store.steampowered.com/app/378720/Thea_The_Awakening... the store page. Great game btw.

I don't disagree that this would be beneficial, but I also don't think it would do anything to prevent the additional support burden and negative reviews in aggregate. If you need proof of this, see the amount of negative reviews on some Early Access games that are very up front about the lack of polish in their current state.

The most obvious solution imo is to offer a free trial mode. If it fails during the free trial then don't buy it.

Steam is quite generous about refunding games, either because you purchased them accidentally or they didn't run correctly or any other reason, as long as you don't have more than a few hours in the game. I think that's a much better approach than having to implement what's effectively a DRM system in software, or a completely separate trial binary containing only part of the game.

> as long as you don't have more than a few hours in the game.

Last I checked the limit was the minimum of "2 hours playtime" and "2 weeks after purchase"

> Steam is quite generous about refunding games, either because you purchased them accidentally or they didn't run correctly or any other reason,

Again, last I read, Steam is quite generous but will probably flag your account if certain patterns emerge (probably through some ML-alchemy).

> This is partly the fault of Steam. They simple have a single "supported" boolean. It would be nice if you could provide a warning or "partial support" label so that people had these expectations when buying the game.

You can have Linux builds available via Steam without listing Linux support on the store.

That is interesting, but too far the other way. I wouldn't even think to look around to see if they have an unsupported Linux version available. But maybe I'm just too picky.

From my point of view, one person telling all their friends that your game sucks can completely offset the nearly zero sales of native linux games. On the other hand most linux gamers know how to run games under wine, so I really don't see any advantage for a developer to make a native linux version.

> On the other hand most linux gamers know how to run games under wine, so I really don't see any advantage for a developer to make a native linux version.

Maybe I'm in the minority, but I've never bought a game because it could theoretically run under Wine, while I've bought quite a few games that run on Linux. Very rarely do I buy a game that does not natively run on Linux.

Wine seems like kind of an ugly hack even in the best case scenario. You don't know what performance is going to be like with your hardware, and you usually don't have anyone who's tested the program on your hardware to make sure it runs correctly and doesn't crash, and obviously games are extremely sensitive to these kinds of hardware dependent things. Installing Wine can be gross too, you have to install a bunch of 32 bit libraries on an otherwise clean 64 bit system.

I'd say the appeal of making a native Linux game is that it gets you access to the market of people who will buy a native Linux game. It's true that you already had the market of people who are technically running Linux and playing Windows games via Wine, but presumably there are many people who aren't going to go to that much trouble. (Obviously, there are many cases where supporting Linux isn't financially viable anyway, Wine or native.)

I have more than once bought a native linux game, gave up getting it to work, and run the windows version under wine.

At this point I just buy windows games, and if they don't work under wine, I run them in a VM.

> Does it work using the latest Ubuntu version? Probably.

KDE doesn't even work on the latest Ubuntu version - on my hardware, at least.

I have an Ubuntu system with an Intel graphics card, and my system won't boot into KDE unless I remove the old Intel driver that it defaults to, so that it then tries the new Intel driver which actually works. Gnome, Enlightenment, and whatever Ubuntu defaults to, they all work fine regardless, but KDE doesn't.

Note that this is after removing the 'Intel' driver for xorg, which had tons of screen tearing issues, in favor of the apparently "correct" modesetting driver, which is the preferred option for newish Intel cards. Except that at some point I was installing something else which explicitly depended on the Intel driver package...

And then we all ended up working from home and now I don't have to deal with any of that crap. Now I just use xorgxrdp from my Windows machine and it just works.

I can't imagine the gigantic hassle that would be trying to game on Linux in that kind of environment, where the "supported" and "default" options are the wrong choice and you have to manually uninstall things if you want stuff to work properly. No thanks. I love Linux (way, WAY more than Windows), but I'm not going to waste time and energy trying to play games on it.

It is absurdly easy to game on Linux now that Steam has proton.

I do it literally every single day.

It is possible to support a wide range of Linux distributions if one takes proper care such as: use CMake and never use GNU autotools or GNU Make as CMake has the best IDE support among C++ building systems; static link as much as possible avoiding reliance on the package manager for getting dependencies; set RPATH as relative path to executable in CMake building system for dependencies that cannot be statically linked; locate resource files using the relative path to the executable instead of relying on fixed path such as /usr/local, /usr/share, /etc/, ...; distributed the executable and the shared libraries in a zip or tar.gz archive with .desktop file containing an icon, so that the user can launch the application just clicking on it. Most MacOSX applications are already distributed in this way in the app-bundle format a, directory ending with suffix .app, containing, a p-list xml metadata, shared libraries and data. The app bundles can be installed just by dragging and dropping without worrying about dependency hell, enabling root permission and so on. The Linux fragmentation could decrease if Linux distros adopted a MacOSX-like standardized app-bundle format.

The last point of failure is the GlibC (GNU C library), a Linux application, even if fully statically linked against all dependencies or packaged with all shared libraries, may fail to run in another Linux distribution if it is using an older version of the GlibC than the one that the executable was linked against. Therefore, in order to ensure that the application can work in the broadest range of distributions, it is necessary to static link the application against the oldest possible version of GlibC or build the application on the LTS (Long Term Support) version of the supported distribution.

If one does not have enough resources to support Linux, an alternative approach, assuming that is OpenGL is used, may be building the executable for Windows and Wine using MinGW compiler either on Windows or by cross-compiling on Linux using Dockercross-mingw (https://github.com/dockcross/dockcross). At least with Wine, one will not have to deal with Glib-C compatibility issues.

> The Linux fragmentation could decrease if Linux distros adopted a MacOSX-like standardized app-bundle format.

Everyone decided this so we got 3 different "standard" formats... (Snap, Flatpak, and AppImage). See: that XKCD about standards.

And macOS has apps that install with .pkg, .app bundles, .dmg, homegrown installers based on shell scripts, zipped archives...

And windows has .msi, whatever is used to install windows store packages, NSIS, Inno Setup...

it's a way overblown complaint. I use AppImages built on centos 7 for my own stuff and never heard anyone having issues with it.

Yep, but the installation is far simpler than the procedure for installing a Linux application not available at repositories or an application that uses unstable libraries likely to change the ABI. All one needs to install an MacOSX app-bundle is to drag and drop the .app folder or .dmg disk image to /Applications. MacOSX reads the plist metadata and finds the icon and the executable path, then renders the icon making easier and intuitive for non technical users to just click and run the application.

On Windows is easier to build self-contained applications as there is no the RPATH issue. All one needs to build a self-contained application that is easier to ship and works everywhere is just add shared libraries at the same directory where is the executable and create a zip archive or a MSI installer. When applications are installed, they are installed in a single folder and files are not scattered across the file systems like binaries in /usr/bin, /usr/local/bin, /libs/, /usr/shared, ..., as in Linux and other unices.

Here's an issue with AppImages: they don't work with musl. Makes me sad.

I mean, targetting musl means pretty much using a different operating system than GNU/Linux. The ELF linking semantics pretty much enforce that you're using the same libc implementation for your whole program.

That's like complaining that, say, a program built against cygwin on windows, can't work on a system without the cygwin dll (and all its dependencies also compiled against the cygwin dll).

Well the problem of Snaps is complex sandbox, lack of user control, forced updates and so on which is disliked on many non-Ubuntu distributions.

Flatpack attempts to solve the dependency hell problem by providing standard runtime, a set of libraries, Glib-C, Gtk or Qt with a fixed version which requires the developer to build an application linking against those runtime, which avoid binary compatibility problems and dependency hell. The trouble of Flatpacks is the integration with the desktop.

AppImage attempts to solve the dependency hell by bundling everything into a single launcher executable with a SquashFs file system image payload. The disadvantage of this approach is that it is only possible to use a single executable. AppImage are also not free from GlibC compatibility issues.

A MacOSx-like app bundle and a changing in Linux development culture to build and design applications as self-contained from inception would strength the Linux desktop and reduce the application packaging work duplication that still affects Linux distributions.

Aren't Linux syscalls backward-compatible? So can't you just static-link your own libc clone (like MUSL or whatever)? (Can't staticaly-link normal libc due to licensing, IIRC)

The system calls are documented and backward compatible. However, Glib-C is only forward compatible, but not forward compatible. An application, built linking against an older version of Glibc than the one found at the deployment machine, is pretty likely to work on this machine, whereas the other way around will result on a linking error.

By using MUSL it is possible to build fully statically linked applications that works everywhere, however dlopen(), dlclose() calls, that are used for loading shared libraries and plugin at runtime on Unix-like systems, do not work with MUSL.

Glibc is LGPL, which makes some exceptions for system libraries, which glibc would fall under. It's been a while since I've read it and IANAL, so I'm not sure what exactly would be allowed.

The bigger problem is that glibc cannot be statically linked properly. It dlopen's some libraries, like for NSS. Maybe games could avoid triggering those cases but musl is definitely better.

While syscalls themselves are backward-compatible (even for faulty behavior), I think I've read somewhere that some parts of DRI are not, but I've lost the source on that.

The bigger problem is that for games you will to interface with OpenGL/Vulkan and probalbly Pulse/ALSA and those are all shared libraries which you cannot use from a completely static executable.

And this still leaves you open to issues with the absolute myriad of driver issues that exist.

yes and then the vocal minority of linux users roast you on steam and tank your rating. chef's kiss

I think you can support only debian distros like ubuntu. Then you would reach the common linux users that install things with the package manager. More advanced linux users would know how to get things running under gentoo or arch, I guess.

I would disagree. As another comment noted, it would be better to compile static where possible and query for directories. I had a game not launch because of a shebang /bin/bash not found even though the common shebang practice is /usr/bin/env bash. No one is expecting perfection, but there are some common best practices out there like following XDG. The more you couple things to hard-coded paths and have them work with just one system, the more you limit accessibility and things "just work"ing on other distros.

As others have said, if you want to distribute on Steam, you have to support "SteamOS and Linux", and can't just say "Supports SteamOS and Ubuntu" or "Partial Linux support" or something like that. If you support any Linux at all, Steam tells every Linux user that your game will work for them.

Steam itself only oficially supports Ubuntu LTS. In practice most distributions work, same as for most games.

Is it actually common to have distro-specific issues like that? I'm skeptical. There are people playing CS:GO with Arch + i3wm just fine. I would think just having the right versions of things packaged is enough, and maybe that distros with fresher packages will be better off.

Alternatively, if more games were free (as in freedom) software, a large community could better sort out some of these issues.

Steam is pretty limited in official support, isn't it? Even if a game targeted a less popular distro, say one optimized for gaming, I'd have no issue dual booting into a different Linux distro just to play it, since it's free anyway and would likely be familiar enough to maintain.

Edit: Though the game would have to have pretty good replay value, I'm not installing another OS for a 10 hour game.