Hacker News Reader

Comment by bob1029 | Hacker News Reader

I honestly cannot blame someone in that business for hating linux. The number of variables to test for if you only care about windows gamers is staggering. Linux is 10x harder than windows if you care about supporting any arbitrary distribution and driver stack. I think if users were willing to load a linux VM for each game they'd like to play, this would be more manageable from a game developer's perspective.

I understand SDL2 exists. I understand that Valve has "mostly" pulled off linux/macos support. But, is it really worth it from a business perspective for all game developers to support linux? How big and wide do your margins need to be before it makes financial sense to fully support both operating systems? How many features (or even titles) will stay in the backlog because your developers are busy chasing down the 5000th weird linux network/GPU/sound bug that only occurs on this one kinda-old version of Ubuntu?

View on HN

Nobody is going to support 5 year old Slackware for their game distribution platform. They'll support current Ubuntu and maybe Fedora--anybody else can work out the problems on their own.

And by support I mean a one-off build for the platform and a public forum where users can ask and answer questions of other users. Maybe if you're lucky they'll do a new build when a patch is released.

Linux users aren't asking for much, and Epic has been more than just dismissive to them. They've been outright hostile, doing things like adding checks to make sure the game isn't running under Wine.

Linux users are asking for quite a lot; not just support for Ubuntu and Fedora but for all the random custom builds and drivers out there.

It's simply not worth it when 0.3% of your customers represents more hardware and software configurations than the remaining 99.7%.

I thought steam only supports ubuntu and therefore games only support ubuntu. That being said, I use arch and most games just work.

Rocket League isn't available on Steam (anymore). Epic does not technically support Linux outside of Android.

Rocket League is not (yet) available on the Epic Games Store, and has not been removed from Steam.

You're making things up; who are these Linux users demanding anything?

Generally speaking once a game developer gets it working on Ubuntu the Arch wiki guys will happily figure out the rest on their own.

It would require them to write it in vulkan which would improve performance across the board on both platforms...so really I think we are asking them to do a job that will cost them more money than they expected for a product they can maintain longer for less effort. You can have both but you have to know what you are doing, epic is just tending a garden that someone else made and clearly doesn't have that level of forsight.

If they release the source, every distro can figure it out on its own.

And if I had a magic flying Unicorn I wouldn't be stuck in traffic.

There's zero chance these for-profit companies are going to open source the current game that they are selling.

Supporting only a single distro of Linux would be fine. If it's not my prefered distro, I'd be happy to dual boot into another to play a game. But I don't want Windows on any of my machines, even as a secondary OS.

People always say this, but then post support comments saying stuff like "nobody uses Ubuntu, everybody uses insert distro here". It's a big mess to support.

I'm still not sure.why game developers are aiming to support distros rather than library versions. That tends to be the biggest problem with linux is the huge number of versions of libraries each distro could have or not have and the location of said libraries on the system. That's the issue crossplatform developers should be aiming to tackle rather than trying to cater.to every single linux distro. That's like trying to shoot at minnows in the ocean with a BB gun.

Also last I checked, if it works on Ubuntu, someone usually will make it work on other distros of roughly the same generation, often within a week. If the core is available, the linux gaming community is quite amazing.

I don't even understand why anyone bothers with targeting dynamic libraries. Why not statically compile everything? The system calls aren't changing are they?

Dynamic linking is usually for packages maintained by the distro, but many proprietary software actually use statically linked libraries.

This way they have one binary that runs on all the modern distributions, then packaging is only to integrate with the package system, menus and stuff (and is optional).

There's also this: https://appimage.org/

So honestly, people complaining about Linux fragmentation haven't done enough research.

Even if you could statically link everything else you would still to dynamically link to the system's native user-mode graphics drivers, which in practice means that you also need to dynamically link to other libraries used by your application and the drivers (like glibc & libllvm) in order to maintain compatibility. Static linking against glibc isn't really recommended in any case.

Nothing prevents you from providing your own preferred versions of most of the dynamic libraries along with the application, however. It should be possible to limit external dependencies to libraries that actually care about maintaining compatibility.

Or...they could just ignore having to target library versions entirely and just target Windows, which represents >99% of the market.

Game developers could do lots of things to support Linux, but many prior attempts to support Linux gaming have shown game developers that it's generally not worth it from a resources perspective unless the engine you're using already supports Linux and you don't need to do additional work to get your gaming running on Linux.

> you don't need to do additional work to get your gaming running on Linux.

Ideally this is how it would be. Develop the game targeting Windows, and simply don’t do the things that unportably tie it to Windows. If you develop it from the start as cross platform, then it shouldn’t be some gargantuan effort to port it. It shouldn’t take that much longer to use platform-neutral APIs than the Windows-only equivalents.

Then just fling off a “totally unsupported Linux build”, stick it on an FTP server, ignore support tickets mentioning Linux, and let the Linux people figure out how to get it working—they will! Let them figure out their driver problems or which distributions ship the right library dependencies. A totally unsupported build is at least better for Linux users than abandoning the platform entirely.

I think a lot of games fail to work on Linux not because of the support costs or the platform fragmentation, but because the developers just don’t care or they choose engines and technologies that are not cross platform. It just never crosses their mind to do it differently.

They could do that, but then people who can't get the game to work will give negative reviews. It's better to just not give them the opportunity at all.

On the other hand, I just recently asked for support on a linux version of a game for a bug that affected only the linux version of the game, the support staff was extremely quick and responsive, the problem was an easy fix when I found out what it was, I didn't ask for a refund because of this and because of my interactions with their support team I wouldn't hesitate to buy another game from them in the future.

Now, same thing happened with one of the worms games, Team17 was dismissive and rude. I ended up just getting a refund. I've been a fan of the series since the very first one, i've bought a bunch of their games over various systems, I own a copy of worms 3d on both GameCube and ps2, but I don't plan on buying another worms game or anything else they put out any more.

D3D11 is much easier to use and more reliable than OpenGL etc, using OpenGL would increase the cost to finish the game and no meaningful gain since Linux is essentially irrelevant.

Also most game devs don't have Linux machines to build or test the game on in the first place.

I thought about it once, tried installing Ubuntu-- it wasn't as simple as I'd like, but eventually worked.. except it didn't seem to be aware of the GPU and was running at 640x480 or some shit.. deleted it.

Officially Steam only supports Ubuntu, and other distros do the work to make it run on them. The same could probably be done for games.

I have never seen such a support comment. (And I say this as someone who doesn't use Ubuntu and has never used Ubuntu.)

As other people have commented, the usual trend for Linux support appears to be that the developer needs to support the most recent version of Ubuntu (or maybe LTS), and anyone not using that version does the legwork necessary to make it work on their setup. And for consumer versions of Linux, Ubuntu is likely to be by far the most popular distribution.

That does not match my view for hanging out in Linux gamer forums. Most games just support Ubuntu and everyone is happy with that because if Ubuntu is supported then it is easy to make it work on other distros. I have never heard anyone complain.

Not only that, but the community would figure out a way to package the binaries with the appropriate libs. When Steam was released it was only officially released for Ubuntu. Yet it worked on Fedora, SUSE, Arch pretty damn quickly.

I hope somewhere in the next iteration of Xboxes, Microsoft comes up with a version that is essentially a Windows desktop, with support for whatever controllers a normal pc supports, but a trimmed down OS dedicated solely to gaming (supporting at least 1080p at 144 hz), with things like Steam and other game launchers.

For me, that would honestly be the best solution to the OS decision. I could just connect it to my same monitor on the second input, and use the usb switch to just switch peripherals.

That's literally what the current-gen Xbox is. It runs a very slimmed down Windows core and most WinRT and .Net applications can be made to run on Xbox without much effort. It not being able to run Steam or other launchers is purely a business decision, not a technical one.

Yeah but I think Microsoft is moving towards all platform adoption. The Halo collection is available on Steam for example.

A lot of people don't want to buy two computers for their desktop.

It will essentially be a console, which many people already have.

It already is a console, though. You're suggesting a way to make it less like a console, but still requiring you to pay a premium to game at your desk.

And it loses one of the big advantages of convenient couch gaming.

>Linux is 10x harder than windows if you care about supporting any arbitrary distribution and driver stack.

Not really. Most hardware is very standard these days, which is why you can install Ubuntu on most any laptop or desktop and have it work with less than or equal issues than a Windows install.

Amd and Nvidia both have Linux drivers that work on all the popular distros.

The reason devs don't even bother with Linux is because there isn't enough people that are playing on Linux.

Amd and Nvidia drivers for what? Big games aren't being made with openGL.

What is the state of vulcan across drivers and engines?

> Amd and Nvidia drivers for what? Big games aren't being made with openGL.

Doom 2016?

> What is the state of vulcan across drivers and engines?

Quite good actually. Intel has older generations supported than on windows. There are 2 mature AMD vulkan implementations.

Also through investments of valve there is a new shader compiler in the works that got merged in mesa which helps quite a lot. The performance is about equal, but sometimes faster under windows (I didn't look at benchmarks of 2020). Oh and vulkan 1.2 is implemented in mesa 20.

Oh and it's vulkan not vulcan

>which is why you can install Ubuntu

This is actually one of the root causes. It would be SO MUCH EASIER, for me, an app developer, if every linux user used centos, or ubuntu, or mint, or whatever the hell. Don't care, pick one. But, customizing is part of the fun... anyways.

Also yeah, desktop Linux is about 10% of users, depending on who you ask. Worse for gamers, although that's just feedback loops.

There's one more thing though, which most people aren't aware of... driver versions. Drivers often ship game-specific hacks for performance fixes. It's an insane, unspoken practice that occurs because some developers will only test heavily on one mfg GPU. Right now, nvidia is taking the brunt of the work because consoles are AMD based.

> I think if users were willing to load a linux VM for each game they'd like to play, this would be more manageable from a game developer's perspective.

As I understand it, this is the direction Steam is heading by running games in containers.

steam does not run games in containers.

Not yet, but:

https://www.phoronix.com/scan.php?page=news_item&px=Steam-Li...

If it turns out that this path is acceptable to the masses, I am 100% on board with all game developers following a similar pattern. Personally, I don't have a problem with this, especially considering most games I install these days are upwards of 100 gigabytes anyways. If 2 gigabytes of each game was a Linux OS image and supporting tools, I probably wouldn't notice.

Having a standardized Linux image with containerization support shared across the entire industry could be a really powerful tool for game developers who want to target Linux but don't have EA's budget. Over time, this could put Linux on equal footing with Windows in terms of platform support cost.

That's not going to happen. The main benefit of developing natively for windows is that the game should pretty much compile for Xbox straight away, with some minimal changes to the code. The PC build is almost a byproduct here. I don't personally see devs making a linux-but-not-really version for Windows if that cuts them off having a "free" xbox version. And from financial point of view having a Linux vs Xbox version is almost a non-starter, unless you're targeting some hyper-nieche.

>I understand that Valve has "mostly" pulled off linux/macos support

Although I think the vast majority of their games don't work on the most recent OSX release. Depending on your perspective, either Apple pulled the rug out from under them, or Valve is letting their code atrophy. Maybe a bit of both, but my opinion is more of the former.

That is 100% Apple's fault and makes me thankful for backwards compatibility.

Music Production has been hit hard by this same move. Plugins and virtual instruments that people have been using for years are all gone from support. All the open source plugins are out right now. Everyone is holding off and I am glad I use Linux and Windows 10 for music.

> or Valve is letting their code atrophy

There haven't been many good reasons to release a 32-bit only macOS app for some time. If Valve is at fault, it's that they didn't require publishers to submit 64-bit builds for macOS years ago.

Valve didn't even have a 64-bit build of Steam for the Mac until after Catalina was out.

I forgot about this. Valve released a 64-bit build of Steam two months before Catalina came out [1], but they did not migrate users of the 32-bit version to the 64-bit version automatically.

https://9to5mac.com/2018/07/27/steam-for-mac-64-bit/

There hasn't been much reason to release a new one, but there also hasn't been much reason to port old ones.

Of course linux is pretty flexible. Wouldn't it be nice if you could just target linux, and get it to automatically support windows/macos? Like a reverse proton? That should be a lot easier than proton ever was.

That's the direction I'd like to see steam's containerization go.

Reply on news.ycombinator.com