cheese talks to

• JP Lebreton - Mr Friendly & Doom
• Éric Chahi - Another World
• Double Fine - Cross Platform Game Dev
• Desurium Contributors
• flibitijibibo - Porting (Part 1)
• flibitijibibo - Porting (Part 2)
• flibitijibibo - Porting (Part 3)
• Nooskewl - Monster RPG 2
• Digital Arrow - Dilogus (Part 1)
• Digital Arrow - Dilogus (Part 2)
• RLK - Neverball (Part 1)
• RLK - Neverball (Part 2)
• Frozenbyte - Trine (Part 1)
• Frozenbyte - Trine (Part 2)
• Protektor - Desura (Part 1)
• Protektor - Desura (Part 2)
• Protektor - Desura (Part 3)
• VoiDeD - Vapor

analyses/opinions

• Hive Time finances
• Proton and Linux Gaming History
• The Linux Game Jam 2018
• 2016 Games Finished
• Exhibiting at PAX Australia
• Star Wars Games
• Linux game porting & Day of the Tentacle
• AdventureJam 2015
• The Interactive Adventures of Dog Mendonça & Pizzaboy
• 2015 Games Finished
• First Programming Experiences
• Assault Android Cactus Launch Reflections
• SLUDGE Engine
• 7DFPS 2014: A Linux Perspective
• Another World
• LUGs & Communities
• Steam Hardware & Software Survey
• Assault Android Cactus
• 7DFPS 2013: A Linux Perspective
• Linux Stretch Goals
• Cross-platform Humble Bundles
• Humble Music Bundle
• ACMI Game Masters
• Humble Bundles
• Trine 2
• Trine
• Desura Beta Review
• TF2 F2P Debacle

other stuff

• About Cheese
• Supporters!
• DFGC Lee Petty Interview
• DFGC Tim Schafer Interview
• DFGC Tasha Harris Interview
• Humble Visualisations
• Wiki Enhancement Project
• Neverball History
• DFGC Ron Gilbert Interview
• RSS Feed

A couple of weeks ago, Valve shipped a beta update to the Steam client, which reframes Steam Play (previously a cosmetic flag that indicated games where one store purchase gave access to the game on multiple platforms) as a feature which allows games to be played on multiple platforms. The distinction probably sounds small, but the move from something-that-developers-do to something-that-Valve-provides is a significant one with lots of implications.

To try and contextualise these implications, we're also going to look at the way that gaming on GNU/Linux has changed over the past 15 or so years. This topic alone could be the subject of an extended series of Cheese Talks articles. In the interests of keeping it down to what's relevant to Proton, we'll be overlooking a lot of Free/Open Source Software game history, skipping the role of crowdfunding and Unity, and glossing over a lot of details that, while historically important, are not essential to getting an idea of the ebb and flow of Linux gaming across the period of time we're looking at.

• What is Proton?
• Linux gaming in the new millennium
• Potential Pitfalls
• Possible Positives
• So, is Proton good?

What is Proton?

In short, Proton provides a Valve distributed Wine install that allows Linux users to download and run Windows games in the native Linux Steam client. Valve have been directly and indirectly contributing to Wine, DXVK (and other libraries, but these two are the main focus here) for some time. It's great to see/know that even for a big feature like this that they're applying their own branding to, Valve are primarily contributing upstream or funding upstream development.

Proton itself consists of Wine (a Free/Open Source Software implementation of Windows APIs that allows Windows programs to run on non-Windows platforms), DXVK (a F/OSS implementation of the Direct3D 10 and 11 APIs that allows Direct3D applications to be rendered via Vulkan - sensing a theme here?), SDL (a F/OSS audio, IO, windowing, etc. library), OpenAL Soft (a F/OSS 3D audio library). It also includes a bunch of Wine dependencies like FFmpeg, FreeType, libjpeg-turbo, and libpng. None of that's surprising, but there are a few other noteworthy things in the repo.

The first is MoltenVK, a F/OSS implementation of Vulkan APIs that allows Vulkan applications to be rendered via Apple's Metal APIs. This is about making games with Vulkan renderers easier to run on MacOS, not about making Metal renderers easy to run on non-Mac platforms. There's really no way that this project can be used or useful in Proton unless Valve are leaving options open to or have unannounced plans to ship it for MacOS as well. This is interesting!

The second thing that's worth peering at is the native Steamworks-Wine bridge called lsteamclient that allows the games launched via Proton to interact with the native Steam client in the way that they would if they were running on Windows. While this in itself isn't new (other projects like Steambridge accomplished this to varying degrees in the past), that it's produced and maintained by Valve means that this functionality is no longer in the domain of independent community developed projects that are chasing the moving target of an upstream API. Since lsteamclient appears to have source available (I haven't tried building it), this would seem to be the best of both worlds. The community can still fork and/or contribute, but being Valve maintained means a higher likelihood of ongoing parity with Steamworks development.

The Proton repository on the Valve GitHub account.

The third and final surprise here is an OpenVR-Wine bridge that allows VR games launched via Proton to interact with HMDs via the native version of OpenVR that ships with the Steam client. More on the implications of this in a bit.

Valve are "whitelisting" Steam Play for specific titles to mark them as officially compatible with Proton, but also expose an option to allow users to run any Windows game via Proton so long as it doesn't have existing Linux launch configuration (games with Linux ports available on Steam can be made to run, but it's a bit more fiddly than just clicking the install button in the Steam client). With these features turned on, Windows games that are available to be run via Proton appear in the "SteamOS + Linux" filter, which I think is the first point where things start to feel a touch wonky.

Backing up a little, this feature is something that many Linux users have enthusiastically requested since before the native Linux Steam client shipped in 2013. Before then (or more accurately, before the Linux client beta became publicly accessible), all Linux based Steam users were running Steam via Wine. There were many of us who had existing Windows-only games that we had to launch Steam in Wine to play (I ran a community called SteamLUG which had hundreds of members before Steam for Linux shipped, and merged that with another community focused on requesting a native Linux client that I was given custodianship of, which had thousands of members before Steam for Linux shipped).

In my eyes, that's an acceptable (and maybe even important) compromise. There's some value in shaping the ease and appeal of certain tasks over others. If running native Linux games with official support is easier and more convenient then people will do that. If running non-native, unsupported games is easier, the people will do that. Humans are creatures who seek out experiences that feel optimised (sadly, we're not always so good at looking at the bigger picture, so often what feels easiest or best in an immediate sense turns out to have unexpected ramifications beyond that).

↑return to page top↑

Linux gaming in the new millennium

I first became a Linux user in an era where we had what felt like a broad range of "AAA" titles being ported to Linux and a modest set of opportunities for positive gaming experiences. Early last decade though, we had very little visibility outside of Linux communities. We were a fringe thing that didn't appear in the public consciousness at all. As desktop Linux became more accessible through the efforts of fast-release distros like Fedora and Ubuntu in the middle of last decade, Linux gaming was in a decline. Loki Entertainment had closed in 2001, and Linux Game Publishing's last supported port was released in 2009. Epic Games and id Software stopped shipping Linux versions of their games (though the former would return in 2014 thanks to community contributions and more internal interest at Epic Games), which more importantly meant that third party games which used their engines would not have convenient access to Linux-supporting tech.

In the interests of publishing this article in a timely manner, I'm foregoing hunting up actual numbers^[1], but given the way that the broader industry has grown, I suspect strongly that we had a proportionally larger representation of "mainstream" games on Linux in the early to mid 2000s than we do today. By contrast, we have much, much stronger representation from niche and independent developers today than we did back then. Which is a touch odd given that it's bigger studios and publishers that are unarguably in a better place to be able to absorb porting and support overheads.

The market has shifted dramatically since then, not just for developers targeting Linux audiences, but also for the industry in general. Digital distribution has become broadly viable, independent developers have access to wider audiences, large distributors and publishers no longer play the same kind of gatekeeper roles. Reaching Linux users doesn't require retail partnerships or shipping overheads, so we've seen a shift away from the platform specific publishers who dominated Linux gaming's past and toward a world where (ideally) any interested developer can build and ship a Linux game (which isn't to say that platform specific porting house/publisher combos are dead - they're still around in the form of companies like Feral Interactive and Aspyr - they're just not the primary contributor they once were).

Things in this industry move so fast that when reflecting on timeframes, it's almost laughable that the Linux gaming "dark ages" that existed between the post-Loki decline and the eventual increasing the visibility of Linux as a viable/profitable platform only lasted for somewhere around a half dozen years (which, for scale, is about how long it took Valve to develop Half-Life 2). That said, it was still a significant setback. The momentum lost there meant that without the support of previous stalwarts like id Software and Epic Games, something industry shaking would be needed to put Linux gaming back on a trajectory toward where it is today.

The first three Humble Indie Bundles in the Humble Visualisations' chart playground.

In 2010, spurred on by the success of their limited time pre-order promotion with Unknown Worlds Entertainment, and inspired by a pay-what-you-want sale that 2D Boy ran for World of Goo (something that was effectively unheard of at the time), Wolfire Games pulled together a bunch of friends and associates try that idea on a larger scale with the Humble Indie Bundle. The premise was to sell a handful of previously released indie games under a pay-what-you-want model, with strong anti-DRM, anti-publisher, and pro-cross platform messaging. Purchasers were able to customise how their contribution was distributed between individual developers and two charities. It was a mind blowing success that exceeded all expectations, raising 1.3 million dollars - not bad for a bunch of "old" (remember, things move fast here) indie games.

The impact and legacy of that first Humble Indie Bundle played a significant role in not only putting indie games, DRM, and maybe-publishers-play-a-different-role-now sentiments into the forefront of the public consciousness. Per-platform purchase stats were displayed on the bundle's page, showing Linux being responsible for one quarter of that revenue, on average paying half again as much as the cross platform average contribution, and accounting for over 15%^[2] of purchases. For the first time, Linux gamers were presented to the world as not only a market of reasonable size, but also as a market willing to pay for games. In a time when people were first starting to become worried about sale culture on platforms like Steam devaluing games, this made Linux a lot more attractive than it had previously been. Coupled with Humble's highly visible success indie developers were clamouring to be involved with future bundles, and the subsequent 18 bundles would facilitate close to 50 "Linux debuts," and encourage many more ports to be developed outside of Humble's promotions.

Near the end of 2011, the digital distribution platform Desura announced Linux support, providing one of the first game oriented storefronts to support Linux, not only with manually downloadable games, but also with an automatic updater/downloader client application. Unfortunately, this was short lived, and two years later, financial difficulties, which would result in Desura being sold several times and developers going unpaid would eventually kill the platform.

A screenshot of the Desura client during its Linux beta.

In 2013, after a number of hinted false-starts, Valve also shipped Linux support. With Desura's future feeling uncertain, and with Valve in a position to encourage other developers to support Linux (in addition to porting their own games), Linux users were very receptive, and very excited. Although there were a number of smaller online retailers and digital distributors going back as far as 2000 with the likes of Tux Games, Gameolith, and Wupra, none of them had the catalogue, the clout or the userbase that Steam did.

Valve's narrative was that in the worst-case scenario, the locked down, Windows Store oriented future that Microsoft seemed to be pushing for, supporting Linux was a key to the company's survival. Some of the landscape for this shifted and Windows 8 and onward so far haven't provided the software-hostile environments many were concerned about. It's hard to say whether this has had an impact on Valve's prioritisation of Linux as a platform. At the time of writing, OpenVR remains in a beta state, which itself was released three years after the Windows SteamVR beta and a little bit shy of a year after SteamVR came out of beta on Windows (Linux is not a fun platform to be an early VR developer on!). Streaming via Steam Broadcasting is also not yet available in the Linux Steam client. A number of significant Linux issues in the Steam client remain unaddressed or took significant amounts of time to be resolved, but thinking bigger picture, that's probably the case on all platforms. Valve is a difficult beast to read.

Later in 2013, the Humble Store launched, providing a centralised purchasing platform for Humble customers that wasn't tied to their limited-time promotions or to developer specific "widgets." In 2014, GOG launched Linux support for their storefront as well. In spite of these platforms having moderate user bases, Valve maintains market dominance over both the distribution of Linux games to users, and the Linux users that buy games. For better or worse, it's fair to see Valve as holding most of the strings so far as the viability of Linux gaming is concerned.

So far, this has been mostly positive. There have been a few disappointing situations where games that were advertised to come to Linux are yet to materialise (Witcher 3, Gauntlet), or took long enough for Linux audiences to get invested in expressing frustration (Rocket League). There have also been a few poorly received ports here and there (Limbo, Witcher 2), but generally speaking, growth in terms of title count has been pretty strong in my eyes. When Steam for Linux first launched, we had a handful of Valve games, a bunch of games from Humble Bundles, and a few other little bits and pieces. Today, a Steam store search filtered to exclude demos, mods, DLC, software, videos, etc., and only show titles that support Linux returns 5,290 results.

Similarly, in spite of a declining percentage reported in the Steam Hardware & Software Survey, the number of Linux is growing, albeit slowly. Valve rarely talk about user counts outside of daily and concurrent user totals, so taking 1.06%^[3] of a 65 million users figure from an October 2013 Valve press release and comparing it to 0.90%^[4] of a 125 million users figure from an April 2016 Valve press release, we're left with 689,000 growing to 1,125,000. That's a 92.31% increase in Steam's total userbase across a 2.5 year period, and a projected 63.28% increase in the Linux userbase. Not dramatic growth, but growth nonetheless. While these numbers can be difficult to take at face value, I think it's safe to say that they give a ballpark indication.

In October 2013 when I first wrote about the Steam survey, there were 204 games marked on the Steam store with Linux support. Nearly 5 years later, we're over 5,000. It's pretty clear that the number of games supporting Linux has grown far faster than the userbase. This isn't necessarily bad, but it does mean two things. Firstly and most obviously, games supporting Linux are competing with each other for proportionally fewer Linux users, which in turn means that either some games will miss out on players, or fewer games will be purchased at full price (in practice, both happen). Secondly, and perhaps less obviously to people outside of Linux gaming communities, Linux users suddenly found themselves in a post-scarcity market a couple of years ago. Up until that point, most Linux users were in a position to own most Linux games. In the interests of supporting the platform and having lots of choices for what to play, many Linux users did go out of their way to own every single Linux game. Today, that's just not an option. This realisation is bound to have a significant impact on purchasing behaviours, and likely exaggerates two impacts of increased competition mentioned earlier.

A random selection of prominent and niche Linux gaming sites/communities out there (there are many more).

In my eyes, this situation increases the importance of being able to engage with Linux users specifically. Linux communities are tightly knit and do have good word of mouth propagation, but they're also fragmented in unexpected ways. I mentioned earlier that I ran a community with thousands of Linux users. I've also written for GamingOnLinux.com, have ported a couple of well known Linux games, and have helped developers of a not-small number of titles find positive experiences on Linux. I ran a website that aggregated data from Humble bundles, which Linux users loved to champion. I've been a moderately visible contributor a popular and long-lived F/OSS game. I was a prominent member of the Desura community when it was the biggest digital distribution platform supporting Linux, and was a part of the development community surrounding its original open source client. To throw modesty aside, I have, and have had more visibility within Linux spaces than most people, and yet there are other prominent people I've never interacted with, who haven't heard of me, and who I haven't heard of. This is typical. There is some of course, but generally speaking, the SteamLUG community and the GamingOnLinux community and the Phoronix community, and the Linux Game Cast community, and the Jupiter Broadcasting community, and the HexDSL community, and the The Linux Gamer community, etc. etc. (apologies to everybody that I've missed here - this article would be double its length if I was thorough!) really don't have a lot of overlap, certainly not the level of overlap that common perceptions of Linux users would suggest.

Unlike platform specific porting house/publisher combos, the domain specific knowledge and skills needed to develop, market, ship and support a game on Linux are something that are harder to come by/develop for individual dev studios who are trying to support Linux for the first time. Feral and Aspyr both have decades of experience with engaging audiences on niche platforms, and while they did have to invest platform specific effort into producing successful Linux ports, they were able to lean on their past experiences as Mac focused porting/publishing houses to get the hype train rolling (toot toot).

Platform specific marketing is a thing that often goes overlooked by many, but it's what those platform specific porting/publishing houses live and breathe on (that and their business model of chasing games with established audiences, which while not relevant to my point, is definitely relevant to their identities). It's also something that a lot of developers and publishers supporting Linux themselves overlook. Most of the developers who've had significantly positive experiences that I am aware of have either put specific effort into reaching out to and engaging Linux audiences, or they have a solid relationship with one of the larger Linux communities (Simon Roth's Maia being the prime case study, and the ongoing repport he has with GamingOnLinux feels like it has played a significant role in its positive reception on Linux).

Across the intervening years, the number of Linux supporting games available has continued to grow, and based on activity among the various Linux oriented communities I'm a part of, the Linux userbase has been steadily expanding at a sustainable rate. For better or worse, the ratio of overlooked games is higher now than it used to be, but for better or worse, that just puts us more in line with the ratios present on Windows. In spite of this, the number of developers having positive experiences with supporting Linux feels like it's also been growing slowly, but steadily, providing Linux uses with more diverse gaming options and exposure to more games that are defining broader game culture.

The WineHQ website.

Interestingly, Wine itself gained some controversial status, with a prominent attitude across Linux communities being that if someone buys non-Linux games to play in Wine, they're hurting the platform. The argument that buying a non-Linux game creates a differential of 2 sales if that game then later comes to Linux (one extra Windows sale and one less Linux sale since Steam as a platform does not allow a game to be purchased multiple times) is solid. Historically though, existing Linux users within non-Linux games' communities have often played a role in helping developers see value in supporting Linux and feel supported when trying to get feedback on initial porting efforts.

While opinions on whether Wine was healthy or unhealthy for Linux gaming were strongly divided, most did acknowledge that Wine itself played an important role as a transitionary tool, allowing new and experienced Linux users to run legacy software acquired then they were Windows users.

Into this arena is thrust a new Steam feature that further trivialises running non-Linux games on Linux. The advantages for Valve feel clear - more Linux users playing and buying more games. For SteamOS/Steam Machines (which we haven't really touched on, but are Valve's Linux based turnkey gaming OS and the branding for hardware that ships that), this has enormous potential value as well. As mentioned earlier, in September 2013 when Steam Machines were first announced, the number of Linux/SteamOS compatible games was around 200. Other turnkey gaming systems (consoles) have typically have had launch catalogues smaller than 30 titles, but the role of the gaming equivalent to a media PC is a concept that's not widely embraced yet. The console ecosystem is also dependent on platform exclusive titles to avoid proper competition between platforms. This is culturally accepted to an extent that the Steam Machines' lack of exclusive titles likely made it less appealing to audiences looking for a console style experience. Whether it was the diminished threat of Windows 8 by the time it was released, the long lead time on SteamOS being production ready, hardware vendors expecting Valve to push when Valve were expecting hardware vendors to push, or customers not being excited by low-spec Steam Machines, and not being willing to pay for high spec ones, the Steam Machines launch fizzled a bit and was widely regarded as a not-so-successful experiment.

↑return to page top↑

Potential Pitfalls

When I first started using Linux, the majority of my gaming experiences were with Wine. This meant that none of the people who made the games I played cared about me as a customer or as an appreciator of their work. It meant that I would sometimes be derided and mocked within the communities surrounding their games. Since Wine itself is by nature ever chasing the moving and obscured target of Windows' closed APIs, it's common for any games that do anything remotely unusual or envelope-pushing to not work until the relevant Windows behaviours that that game relies on are identified and reproduced in Wine's codebase, meaning that I was effectively excluded from participating in launch enthusiasm and discourse. Any problems I encountered were my own problems to solve, and, in that era, no refunds were available to customers who chose to purchase something to run on an unsupported platform. In these situations, I as a Linux user was not socially equal to other users, nor was I entitled to the benefits and experiences of other customers.

After trusted distribution platforms with Linux support became available, some developers chose to ship Windows versions of their games on Linux bundled with a pre-configured Wine install. In these cases, the onus is on the developer to provide their customers with positive experiences, and to work toward addressing issues. In these situations, I as a Linux user was seen as legitimate and valuable.

With Proton being provided by Valve and not developers, the responsibility for ensuring that users have positive experiences is unlikely to lie with those who are making/maintaining the game, and so we end up with the potential for end user Linux experiences to be set back 15 odd years. In fact, a Proton FAQ entry addressing concerns about increased support overheads from developers who've had games officially whitelisted as being compatible with Proton (seems like this happens without notification or consent) states, "Users playing through Steam Play experiencing Linux-specific issues should be directed to Steam for support." Which on the surface sounds fine, but in my experience, it's not uncommon to find developers who struggle to identify whether problems are Linux-specific even when they are targeting and testing native Linux builds - this can only be exacerbated by having less opportunity for first hand experiences.

Two of the FAQ entries in the announcement of the Steam Play/Proton beta.

Some may argue that this is irrelevant if the game runs well, but the future that I want to live in is one where the operating system I use does not play a role in the level of cultural participation I can have. My good friend Drew posits that Valve have positioned things so that the platform a user is on no longer matters. Games, like films become a thing that just work anywhere, and nobody who makes or distributes films has to know or care about whether their customers are running one brand of DVD player or another. I think this is a really interesting perspective, and maybe it's a good future to aim for. In this analogy though, film compatibility is enabled through a common format standard, and I'm not convinced that technologies like Wine (which are beholden to the proprietary upstream decisions that whoever made the project it's copying) are as good a fit for that kind of role as existing F/OSS cross platform tools, frameworks and libraries.

It's also worth remembering that our ability to play DVDs on Linux is thanks to the reverse engineering efforts of community members not associated with the DVD Copy Control Association, which are of questionable legality in some countries, and it's not unreasonable to expect that given a choice, DVD CCA (the people in charge of the tech) would probably prefer for libdvdcss and the information it exposes to not exist. It's not hard to imagine that Microsoft don't hold Wine in high regard either. At best, hostile upstreams are likely to make decisions that don't prioritise positive experiences for downstream users. At worst, they actively work to undermine positive experiences downstream^[5].

Another prominent perspective I have seen is that barring regressions, if a game works in Wine/Proton, it works forever, whereas a native port might stop working at some point in the future. This one is harder for me to get onboard with. Wine allows old things to work on new platforms only by virtue of it being F/OSS and being something that can be compiled for in any environment that its dependencies are available on/can be compiled for - it's not something that's intrinsically a property of emulation/compatibility layers. I think this concern about native ports not working forever comes from two places. Firstly, it's easier for backward and forward compatibility to be of a comparatively low priority. In a purely F/OSS ecosystem, anything can be rebuild at any time in any new environment (we have packaging ecosystems to handle this and makes sure that software doesn't conflict and philosophies are represented in the packages users have access to). That said, a lot of projects do put effort into this, and I feel like it's something that's on more projects' minds now than it was ten years ago.

Secondly, as mentioned earlier, the landscape of Linux gaming has changed dramatically over the past decade and a half. While there still isn't much in the way of centralised resources for best practices to guide developers who're new to supporting Linux (something I want to put effort into addressing in the future), I feel like it was more of a "wild frontier" in the past, especially without the advantages of the Steam Runtime as a common set of base libraries that developer can target (the value of using the Steam Runtime is often debated among Linux users, but its value as a minimum set of library versions that a developer can expect to be on users' machines has definitely enabled more developers to ship working games with confidence). Beyond this, as former LinuxGames.com writer, prominent ioQuake3 contributor, and Nuclear Monster writer Jack Slater noted a while back, applications that run in Wine at one time may not always work in the future - regressions and bugs occurring as new Wine features (which may be old Windows features that were missing or features of new Windows versions) are brought online is not uncommon.

A tweet from a developer who has been working on a Linux port of their game.

Coming back to the introduction of Proton, I have to imagine also that any developers who were uncertain about supporting Linux who'd just taken the plunge on commissioning a port might be feeling like they could have just waited and explored Linux audiences from a more comfortable angle without spending any money. In the eyes of Linux users, native ports are inherently more valuable, but from a developer perspective, losing 10% of your platform specific audience in exchange for a less risky alternative that has zero cost sounds like a sensible tradeoff.

Unfortunately, this means effectively ignoring the platform specific marketing thing that I mentioned was important earlier. It's easy to imagine that developers who ship Windows versions of their games for Linux users to run via Proton would, generally speaking, engage less of the Linux market than they otherwise would, which in turn means fewer opportunities for positive experiences of supporting the platform. That leads to more narratives about how Linux users are difficult to attract the attention of, which winds up making new developers interested in trying out Linux more likely to try the low risk option.

In the short term at least, I expect to see less porting/platform specific consulting work. I don't feel like my livelihood is anywhere near as important as the platform, but if people who do this kind of stuff don't get work, it's harder for that knowledge/those skills to find their way into the industry. One of my philosophies has been to always try to help people gain the knowledge and skills they need to be able to have a positive experience supporting Linux without me for their next project. They may still call on me, but they won't be forced to be dependent on me.

It's also easy to imagine that developers who aren't specifically building for and testing on Linux, who receive support requests from their Linux users are going to come away feeling like they are being complained to about and being asked to address things that are outside their ability to control. This can already be a problem for some developers, and its a situation I put effort into helping others avoid. In a world where Proton adoption is high, I could see this becoming a much more common pitfall, and one that makes developers less likely to feel like they can engage with their Linux audiences.

Ultimately, native ports benefit the ecosystem of F/OSS and cross platform game development tools that are out there. SDL itself grew out of common porting work that Sam Lantinga did while working for Loki Entertainment in the late 90s. Companies like Feral Interactive, Aspyr and VirtualProgramming have been responsible for input into Linux kernel and F/OSS video driver improvements. Valve have contributed to and released numerous F/OSS projects. All of these benefit not only the games that that work is being done specifically for, but also Linux based developers and in the case of cross platform tech like SDL, users and developers on all platforms.

A photo of the HTC Vive's Link Box taken while writing my First Steps with OpenVR and the Vive on Linux article in 2016.

One of the biggest surprises for me personally was seeing Valve ship an OpenVR-Wine bridge before OpenVR/SteamVR for Linux come out of beta. The likelihood of VR applications targeting Linux and VR development being seen as viable on Linux felt like it was pretty high in the early days when platform parity for Oculus (who had Linux listed among their supported platforms in their Kickstarter campaign) and HTC's devices (SteamVR had Linux support for the Oculus Rift in 2014, and in 2015, HTC's Jeff Gattis told Business Insider that the Vive would run on Linux) seemed reasonable to expect. Linux audiences would have had an opportunity to make up a much larger portion of the VR market than is remotely possible for broader gaming markets, and the likelihood of the first wave of VR success narratives from this generation including cross platform support as a way of expanding audiences seemed high (we'd never be a majority, but instead of a perceived 1%, we could have been a perceived 10% or higher). Windows based developers who don't have established histories of natively supporting Linux targeting Linux with a VR applications at all feels extremely unlikely now, and it seems like it will still be a while before Linux based developers have access to stable tools.

It probably sounds at this point like I'm painting a pretty negative picture of Proton-era Linux gaming - fewer developers pursuing native Linux builds, lower commitment to Linux as a platform, less support for Linux users, less contribution to cross platform F/OSS game development tools, and so forth. I don't believe that these will necessarily come to pass. These scenarios are just possibilities that are easy to envision and reflect hurdles we've past in the past. The more we think about and explore the potential negative outcomes though, the better equipped we are to avoid them.

↑return to page top↑

Possible Positives

Assuming that more developers supporting Linux natively, and treating Linux users as equally valid/valued customers are the most positive outcomes, let's consider a few of the possible ways that something like Proton could be used to leaverage that.

The first and most obvious area that can potentially benefit Linux surrounds Proton itself. Given the project's history and Valve's track record of continuing to maintain their F/OSS projects, contributing upstream, and sponsoring contribution^[6], it seems likely that Wine, DXVK, SDL, and OpenAL Soft (at least until the FAudio migration is complete) are all likely to get ongoing development and bugfixes where that aligns with Proton's needs. While Wine and DXVK aren't particularly useful for anybody making stuff that targets Linux specifically, SDL and OpenAL Soft are widely used projects that support game development on many platforms (including Linux).

As an aside, it's also worth noting that Proton's Wine diverges from upstream Wine a little. Some comments I'd read from one of Valve's Linux oriented developers seemed to suggest that there was potential for it to diverge further. The situation here is interesting and raises a piece of Linux gaming history I haven't touched on yet - Cedega (originally known as WineX). Created by TransGaming Technologies, Cedega was a commercial proprietary fork of Wine that focused specifically on game compatibility (unlike Wine, whose primary corporate sponsor, CodeWeavers, is focused on running business productivity software and their own commercial fork called CrossOver). Their agreements with game publishers lead to them implementing support for a number of DRM mechanisms, which in turn placed restrictions on what code they could and couldn't share. Since Cedega was forked before Wine adopted the LGPL, TransGaming Technologies were allowed to use code up to that point, but not further. For now, Proton seems guarded against this, and Valve seem committed to maintaining their F/OSS projects. Cedega's last release was in 2009, after several years of slow support, it was eventually retired in 2011. Efforts to continue development under the name GameTree Linux were announced, but it's unclear whether that was purchaseable at any point before 2016, when TransGaming Technologies shifted to focus on that most game related industry, real estate financing.

A screenshot of Rocket League running on Linux.

Another area that positive benefits can be drawn from is passive and active encouragement from Valve. After Steam for Linux first launched, Valve worked with many developers to encourage and support them in developing Linux builds. These efforts were rarely explicitly documented, but the most well known is likely Rocket League, Psyonix's vehicle based football/soccer game, with the Linux port initially announced in 2015 and offered as an incentive for Steam Machine (and other Steam hardware) pre-orders. Beyond that though, there have been many less visible instances of Valve's Linux-positive stance and encouragement influencing developers, and the prominence of Linux-relevant talks at the Steam Dev Days conferences has been notably high for a game development oriented conference. To continue this kind of encouragement, Proton could be presented to developers as a way of ensuring that Linux customers have easy access to that developer's back catalogue when shipping a native Linux build (not having the first game in a series available may steer customers away from a sequel when a Linux port is released - I recall concerns about this when Coffee Stain Studios' Sanctum 2 was initially released in 2014).

In the Steam Play/Proton announcement post, we can already see encouragement for developers to implement Vulkan renderers in three separate places, twice to highlight that Vulkan renderers will offer the most performant experiences in Proton, and once to talk about Vulkan being a way to improve experiences for users on all platforms at once. The latter carries the wording, "We think [Proton] will also allow future developers to easily leverage their work from other platforms to target Linux," though it feels unclear whether that means targeting Linux via Proton, or using Proton to provide Linux users with positive experiences while incrementally adding on features that would work toward a native Linux build longer term.

Since Valve are maintaining a whitelist of explicitly "supported" titles (found in the announcement post), it's easy to imagine that Valve could also leaverage this to secure future native ports. Whitelisted status could be offered in exchange for a commitment to investigating native support after a certain number of Linux sales was reached, and could be a low-risk way of allowing developers to engage with Linux audiences and incorporate Linux users into their player communities while accumulating resources to fund a native port. Ideally, this type of commitment would be between Valve and developers rather than developers and users (and maybe not communicated to users at all) so as to avoid disappointment should those thresholds not be reached.

A screenshot of the Steam storefront's "SteamOS + Linux" page.

With the increasingly hands-off approach that Valve are having to managing the Steam store and the developers who use it (which isn't a bad thing), it seems that reducing Valve's revenue share of Steam sales (by say, a quarter per additional platform that developers natively support) could be a significant way of incentivising the prioritisation of supporting all of Steam's users rather than those on a particular platform. Proton could be framed as a way of allowing developers who're unable to natively support Linux to still receive Linux revenue and service Linux customers, but without conferring the revenue increase. The likelihood of this seems low, as it hasn't already happened, but it is another case where users would be unlikely to have much awareness of specifics, since the details of the agreements that define Valve's revenue share are covered by an NDA.

Similarly, additional store placement options and other perks for developers explicitly supporting Linux could be also made available.

Last, but not least, launching SteamOS/Linux versions of their games marginally ahead of other platforms could increase Linux adoption and demonstrate larger Linux markets. This seems most unlikely as Valve have previously been adamant that platform exclusivity isn't a direction that they're keen to go in. Strong anti-exclusivity messaging has been coming from a number of notable Valve figures in regards to Steam Machines and VR for years (on a side note, arguments for supporting multiple VR devices/distribution platforms giving developers more opportunities to recover development overheads can also be used to explain why consistent and stable cross platform VR APIs are important for helping developers make whatever sales they can). It's possible that these attitudes may have shifted over the past couple of years, but they are strong points to be arguing from that respect and support Valve's clients (developers).

I also am wary of this approach. As mentioned earlier, Linux as a platform comes with a lot of philosophies and ideologies, and in order for the F/OSS ecosystem to function properly, it's important for users to be aware of and understand them. Dramatic population increases in communities where other community members play a vital role in easing newcomers into their new social and practical existence can be deeply destructive to existing cultures (I've written about that in the past, using Team Fortress 2 as a case study).

An archive of the original SteamOS announcement page, which has since been removed.

Beyond this, chasing a higher userbase is a flawed goal in and of itself. It is far better to focus on increasing the quality, accessibility, and robustness of experiences, and in that way create a more attractive platform, than work to artificially inflate the userbase in the hopes of hitting some kind of critical mass. The alternative results in skewed priorities that revolve around things that don't really benefit any users or the platform in tangible ways.

On the note of potential Linux user expansion, the Steam Machines' "You can play your existing Steam library" pitch becomes much more attractive if instead of the 5k games available for Linux, the 27k games available for Windows on Steam (at the time of writing) are available to be played on a Steam Machine via Proton without having to dedicate another machine to streaming from Windows. A Steam Machine re-launch could be a much more viable thing after Proton becomes stable.

Steam Machines as a platform end up contributing to the Linux and F/OSS ecosystem thanks to them being Linux based, but their target audience is primarily people who want a turnkey gaming experience, and that's not what desktop Linux is about. This is more in line with a set-top-box that runs Linux or a smart device that runs Linux - the bulk of users will not identify as Linux users and will not be interested in F/OSS philosophies and ideals.

↑return to page top↑

So, is Proton good?

Since Proton first launched, people have been asking me whether I think it's a bad thing or a good thing. Most of these people have been exuberant and are looking for someone to celebrate with. In all of the Linux communities I'm a part of, Proton focused channels, threads and recurring conversations sprung up immediately. While discussing Proton related features, SteamDB organisers decided to retire the long-lived "Linux list" (formerly the The Big List of Steam Games on GNU/Linux) at the same time as planning out how to track Proton compatibility. In two weeks, the community maintained Steam Play Compatibility Reports list has received reports of nearly 3,500 titles, more than the SteamDB list was able to accumulate in 6.5 years. For now at least, Linux users are embracing Proton with gusto.

The thing I find most interesting about Proton is that (not to downplay the advancements that Valve have been able to achieve with and through CodeWeavers and Philip Rebohle) all of the things that have truly changed about Linux gaming are psychological. It's the framing of Wine as part of a Valve product, its presence within the Steam client that most Linux gamers are already running, and the expectation that it's safe to assume Wine's presence on users' machines now that will ultimately shape attitudes and determine the impact that Proton has.

A user request asking a developer to remove an unpublished Linux port from Steam.

I remember when Steam for Linux was first announced, I was surprised at how eager Linux users were to embrace what would very clearly be the greatest influx of proprietary software our platform has ever seen. I expected that the gift of Valve's games to Debian contributors wouldn't have much value to people who are contributing to a Linux distribution that strongly rejects non-Free software. When Proton launched, I expected it wouldn't mean much to most Linux users - after all, as Valve mentioned in the Proton announcement post, users who were comfortable with non-native gaming experiences would already be running the games they were interested in via Wine anyway. I certainly didn't expect to see Linux users asking developers to remove unstable/unfinished Linux ports from Steam so that their game could be installed and run via Proton. It's clear that I am not very good at predicting how my fellow Linux users react to things.

I honestly can not say whether Proton is likely to have positive or negative outcomes for Linux. It feels like there is a tremendous amount of room for both. I feel a lot of uncertainty about what this means for porters and for developers who feel like they've invested a lot of effort into Linux support that hasn't paid off yet.

There are a couple of things that I think are fairly safe conclusions to draw though. If Proton's Wine becomes the primary way for Linux users to play non-native games, then Valve will be the custodians of the majority of tech that enables Linux users to play games (one could argue that through Steam and the Steam Runtime, they already had this, but the WineHQ AppDB lists 12,126 games with Silver or higher ratings at the time of writing, which is more than double the number of Linux-compatible games listed on Steam right now).

When disruptive changes occur that don't provide immediate advantages from getting onboard early, wait-and-see type approaches are typically adopted, and I think it's safe to expect that for developers who were considering but hadn't committed to Linux support, now will feel like the right time to wait and observe. Beyond this, the initial enthusiasm that Linux users have shown is likely to lead developers outside of Linux communities to assume that Proton is enough to satisfy their demand.

Longer term, the quality of gaming experiences that Linux users can expect moving forward will largely depend on how Valve handle and encourage developers who are receiving Linux customers.

Beyond that, any of the positive or negative things I've raised in this article may happen. Many more that I haven't mentioned could also be looming on the horizon. Right now, it feels impossible to predict what Proton might mean for Linux gaming in 3 to 5 years. I do know that the more we think about possible outcomes, the more able we are to take advantage of opportunities that arise, and the more able we are to navigate our way around problems.

Whether or not Proton is ultimately seen as good or bad in the future will depend on two things. How much priority Valve give the things that we as Linux users care about, and how much attention we pay to the paths that lie before us.

© 2011 - 2024 Cheeseness.
Subscribe for updates.
All trademarks are property of their respective owners.

Cheese Talks is supported by these awesome people!