When reading the context of the statement itself, it isn't that bad. He was concerned that Microsoft would introduce restrictions that place inhibitors on other vendors hardware with the introduction of a Pro operating system. The statement itself isn't the best, but his stance was that as a community Windows developers and users should push back against such changes.

An employee at Epic has mentioned that if someone with Linux development skills was interested, they would be more than happy to bring them on to develop a EGS application for Linux. The thread can be found here: https://twitter.com/CanalOCaraDoTI/status/110621899365072896... (scroll to the top for the beginning).

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?

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%.

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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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?

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.

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.

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.

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 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.

>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.

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

> 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.

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.

steam does not run games in containers.

Not yet, but:

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

>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.

Is that tweet really "extremely negative" towards Linux? All he says is that he doesn't want to abandon Windows but instead push back on changes to it he doesn't like; he doesn't make any judgements about Linux. The reality is there are many barriers to Linux replacing Windows as a desktop platform for users today so it's not surprising that someone who runs a business that depends on users doesn't want to push for a huge switch to Linux if it's not necessary. If a company not wanting to act outside it's interests makes it Linux's "biggest enemy" then it will be a very long time before it succeeds as the major desktop platform.

It's not hard to hate Linux (Desktop) when you develop proprietary software since Linux seems to go out of its way to make it as difficult to deploy proprietary software as it possibly can [0]. Libraries are constantly changing underneath you in incompatible ways, there are several hundred "distributions" to deal with, etc.

[0] And frankly it is only slightly easier if you write FOSS software.

The way developers solve this on Windows works on Linux: ship the libraries you need with your application. Steam does this and it works pretty well. Even if you don't, the Linux community will do most of the debugging for you and submit fairly detailed bugs (failed on platform X with error Y, workaround Z produces different error), so all you need to do is interact with the community periodically, fixing the easy issues to keep people happy.

For FOSS projects, everything gets easier once you get it accepted in the package repositories, and if your project is popular enough, you can usually get someone else to do it for you.

In both cases, using a language that has a cross platform dependency manager eliminates a huge number of compatibility problems. Also, keeping libraries reasonably up to date also helps prevent problems from happening. Updating every two years should be sufficient to maintain compatibility with most Linux distributions.

Also, software vendors don't have to worry about every Linux distribution, just pick the top one or two and let users support the rest for you.

Target the steam runtime. All popular distros will either support it out of the box or have an overlay to do it. And it doesn't change very often.

Open source is a million times easier. Your source is available. It's up to the distro's maintainer of your package to deal with compiling and binary compatibility.

https://github.com/ValveSoftware/steam-runtime

> It's up to the distro's maintainer of your package to deal with compiling and binary compatibility.

That's bullshit though. Why would you trust some random community maintainer to get between you and the user? Now when shit goes wrong there's one more person in the loop of blame to deal with. There are famous incidents of maintainers introducing problems to otherwise correct software, and ignoring the developer.

"I am constantly getting email from users reporting bugs that have been fixed for literally years who have no idea that the software they are running is years out of date." -jwz

How is this considered a sane way to distribute software!?

Many of these distributions, at least the popular ones, are nothing more than forks of Debian, Ubuntu and RHEL/SuSE. And most (not all) people who would want to game on a Linux system use Ubuntu as it's by far the most painless thing to get going. Base yourself off of the latest Ubuntu LTS, compile your project statically as far as possible and you're probably good to go, containers can be used to get your project running on other distros if needed.

If you're using any engine even better, all of the major ones are cross-platform anyway and abstract all the nastiness away.

1. It seems as if he's addressing the context of the discussion (switching to Linux from Windows) rather than saying anything particularly negative about Linux.

2. I've been making some UE4 projects recently (as im getting back into game development as a hobby) and the toolchain to cross compile to linux is well made and easy to use (and even easy to dockerize).

I think unreal engine support of linux is probably the better barometer of Epic's stance towards linux than their not-so-fully-featured launcher/store (which is many years behind steam).

I haven't tried recently, by UE4 used to work reasonably well on Linux if you build from source, so they're putting at least some effort beyond cross compiling.

Oh, wow, I was not aware it is this bad! I kinda expected they just don't care but not they are actively sabotaging Linux compatibility...