Why Game and App Devs Aren't Targeting Linux

So, I’ve been a Linux user for almost 2 decades now. I’ve seen the platform grow and improve over that time period, as well. One of these areas that has grown by leaps and bounds in such a short time has been gaming on Linux. Developers from large publishing houses like Feral Interactive and Aspyr as well as smaller indie studios have been creating games for Linux for 6-7 years now. However, I’ve noticed an increasing number of instances where developers of games have decided to eliminate Linux support or forgo Linux entirely.

This is due, in my opinion, to many factors. The first of these is market share. Now, I know this is a chicken and egg problem. However, there are ways to get past this problem that are not being put forth, at least publicly, by the Linux community. I recognize that not every Linux user is a developer. I also know that many users are completely fine with just using things and not rocking the boat as long as things keep working.

To increase market share we need to improve the experience for users. There are plenty of projects that are working on improving the experience for new users and there have been incredible achievements in this area. However, the users aren’t going to consider a platform that, regardless of how easy it is, doesn’t solve the problems they have. So, we need to get more developers to build their apps for Linux, right? Yes. However, the state of Linux desktop app development is not a pretty one.

“Wait!”, you say, “What about Snaps and Flatpaks? Weren’t they supposed to solve this problem?” Partially. They solve the issue of packaging and dealing with multiple distros and environments, certainly. The issue is with what lies within the package. Right now we have an enormous amount of frameworks and toolkits to use when building an app for Linux. Diversity of toolset might be a good thing as you can cater to a wide variety of skills in the dev community. However, how does one choose what to go with? Do I make a GTK app or QT? Do I use the Python bindings for this toolkit or another? What about libraries? I want to implement some video into my project, so how do I handle that with acceleration? The list of questions goes on.

So, what I think is the ultimate issue with building apps for Linux is the plumbing of the apps themselves. We lack any solid SDKs that persist across distros and environments that devs can rely on. For example, when considering hardware accelerated video on a site like YouTube in the browser we run into a problem. None of the browsers (aside from an experimental Chromium snap) support hardware video acceleration. Why is that? Well, we have no universal framework to plug into for this functionality. Do we use gstreamer or ffmpeg or any others? What about supporting vaapi or nvdecode? Older cards need VDPAU support, too. How is a dev supposed to bring functionality that the community wants if there’s no universal API/SDK to build off of when creating the underpinnings?

We focus a lot on look and feel of software. It’s important because it’s the first thing that people experience when using software. We focus lots of effort on making GTK apps look good in Plasma and QT in GNOME. However, there’s so little focus on the more important bits that are underneath that thin veneer of GUI toolkit. If we look at Windows or MacOS we see overall SDKs and subsystems that provide app developers with a sane and universally available set of parameters that they can work within. CoreImage, CoreAnination, QuickTime, AppKit, UIKit, and more are on MacOS (and iOS) to provide devs with ways to optimize their code for the operating system and unlock the power of their hardware. Windows has things like WPF and DirectX that provide similar levels of functionality. In desktop Linux, we have numerous ways to decode video, display 3D graphics, even draw Windows on a desktop. This is a very important distinction to make as developers need sane and integrated ways to build their apps on top of your operating system.

So, what’s an example of an app framework that does exist on Linux that devs can write to? Well, lots of people hate this, but it’s Electron. It’s not perfect by any means, but it’s the best option for lots of developers because they have a sane set of tools and frameworks with which to rely on when building their Electron app. We can sit here and sream until we’re blue in the face about how terrible it is, but it’s the symptom of the larger native Linux app problem.

Here’s where the human aspect comes in. Many members in our community, some of which are developers, make terrible decisions on how to interact with others. In the case of developers, it is much easier and more convenient for them to just fork a project and go their own way than to try to integrate their ideas into an existing project. Also, there are too many people in decision-making positions in projects who are too closed off to the ideas of the wider dev community. This is where we end up “spinning our wheels” so to speak. We will never become a platform that encourages developers to come work on if we are constantly getting in the way of development.

The users are not immune here, either. As mentioned in the beginning, many Linux game devs are choosing not to target the platform mostly due to support costs vs the retun on investment. That’s understandable. However, instead of finding ways to encourage devs to make apps and games on Linux (by creating sane SDKs and frameworks) many individuals choose to throw mud and become hostile toward those developers. The end result of this is a dev thinking, “Well, that’s a terrible way to respond to the people who try to provide the things you love. Guess we won’t be making stuff for them again.” These people are mad because they don’t have games, yet their actions are exactly that which prevents devs from targeting their platform.

These are not easy issues to solve. The first set of technical problems could be solved with a good bit of code and some knowhow. The human aspect is much harder. People are going to be terrible on the Internet, I know. There’s nothing stopping that. However, if we want to grow as a platform and improve our community we need to stop thinking in such small terms as “my way or the highway” and “if you want it done right, do it yourself”. We need to make our platform inviting to new users and developers by improving things technically and socially. Not sure how we’ll get there, but we have to move forward into the future whether we like it or not. May as well make it a pleasant move.

4 Likes

This reminds me of the Linux Spotlight with @popey where he discusses this same topic in detail. He came to the same basic conclusion and fumy enough also mentions Electron as being a workable solution for devs because it’s cross-platform.

As far as the chicken and egg problem, there are so few Linux users that developing native applications seems pointless to most corporations. Where is the potential for profit in a 1% user base? Unless it’s something very specialized there isn’t one. For-profit corporations, especially publicly traded ones, don’t have the luxury of taking chances with almost no likelihood of making a return on their investment. Keep in mind that developing the software is only part of the challenge. If they sell something for a platform they have to support it. Not just tech support but sales, marketing, and so on. It impacts the entire organization. That type of investment just isn’t going to happen with such a small market share in place. Now, if the Linux desktop market were to grow and show continual growth then they could make a case for investing in it. Corporations follow the money. If there is profit potential, they will be there to meet it.

So that leads us to the importance of Valve and Proton. Valve made the decision to support Linux long ago and has made a significant investment in Proton. It has taken them years to develop using paid developers. They have solved a few key problems.

  1. They provide a compatibility layer for Windows games to run on Linux. Sure, there were ways to do this before with Wine and wrappers, scripts and so on but in many cases it just works in Steam.
  2. They alleviate the need for game developers to officially support Linux, particularly as it relates to organizational support, while being able to sell games to Linux users via Steam.
  3. They give developers a bridge to bring new games to the Linux market by providing tools to test as they develop. Will they take advantage of it? Who knows. If it means $100,000 more in revenue and costs then a few thousand in man hours I assume they will.

I guess where I end up is that, if and until there is some critical mass achieved on the Linux desktop, it will be up to third parties to make things work on Linux.

2 Likes

I have been thinking about this and sometimes gamers and linux users are justified in feeling aggrieved. Like in the case of Forager where we have a developer who sold a product with Windows, Mac and linux support. People then bought the game on the basis that it would be supported on their chosen platform only to have that support pulled with no offer of a refund. Any way you slice it, that is anti consumer and goes in the same file as Rocco’s hardware purchase woes for me. Not giving consideration to supporting a platform in the first place is a decision I can accept and respect. Releasing a product and taking money on the basis of supporting it, then pulling the rug out from under your customers is a very poor move and deserves criticism.

The reasoning they gave also seems suspect because they spoke about challenges supporting Mac and linux directing people to an article that only talks about Mac and doesn’t mention linux.

It seems to me that there needs to be improvements on both sides. Gamers/linux users need to learn to stop being pricks, and developers need to learn to be more honest and forthcoming with reasons why they are not supporting a platform.

3 Likes