In the beginning, a brief historical overview.
While PC was the platform that enabled mass-scale game development as we know it now, its Golden Age only lasted from about 1992 to 2005. Back then PC replaced the arcade machines as the primary target for both AAA and smaller game developers, while console ports usually came after a successful PC release and were inferior due to a weaker console hardware.
Things have changed in mid-2000s, when consoles that were at least as powerful as a typical user’s PC appeared. Hard-core gamers with their beefy rigs still had the upper hand, but a mass user’s desktop (slowly turning into a laptop at that point) was outclassed by the console hardware - and this hardware came bundled with online services which were better than what was available on PC (Steam and GameSpy, let alone Games For Windows), without the need to muck with the drivers and run PunkBuster to weed out the cheaters. And, more importantly, the games on the platform were designed to be played from the couch, often together with a friend or a partner - very important thing if you consider the prevalence of casual players over the hard core ones on any platform.
Sales quickly reflected the changed environment - take any cross-platform game of the era and compare PC and 360 copies sold on a sales tracking site like VGChartz - PC figures will be consistently smaller (and don’t forget that PC price is usually lower).
No wonder that for non-indie game developers, PC has not been a popular platform since then. Game developers and publishers alike are more than willing to concentrate on the console market, which consistently accounted for the majority of the sales while being relatively easy to develop for.
What has changed?
“PC renaissance” of early 2010s happened largely due to two factors, one of them being proliferation of the “free to play” format. Initially unpopular in the console-dominated West, F2P spread like wildfire due to the success of MOBA type of games. Both because F2P favors a large installed base and because it is inherently resistant to piracy, F2P once again made PC a viable platform for making money.
The second important factor was the “indie revolution”. Easier access to professional tools (e.g. Epic’s UDK released for free in 2009) and inexpensive engines (Unity, Cocos2D), widespread acceptance of the digital delivery (Steam) and significantly improved compared to early 2000s hardware and software (on Windows side) of an average PC allowed small teams to develop games that could be played by millions.
That said, these days PC is still an “ugly duckling” of the AAA game development. Contrary to its golden age, it is now the PC version that is released after the game proved to be a success, if at all. For whatever reasons, AAA games that don’t utilize “free-to-play” mechanics but are instead sold traditionally, enjoy larger sales in terms of profit on the console platforms - and this is unlikely to change in the foreseeable future.
How does Linux fit into this picture?
I dare to say that it was PC renaissance that enabled Linux gaming and not vice versa. While it is certain that Humble Indie Bundles benefited from claiming Linux support, the Linux ecosystem was not (and is not yet as of now) able to sustain game development even of F2P games and has to piggy-back on OS X porting efforts - or, sometimes, on the fact that the Linux port is comparatively cheap due to a cross-platform engine.
Demands for the Linux version of a game can be sometimes quite vocal, but its actual release does not seem to bring much, if any, profit. This is not because Linux users are not willing to pay in general; rather, it means that targeting the platform is more expensive than the price that can be reasonably charged for a single copy. Other platforms are helped by the economies of scale, but this is not the case for Linux.
The above applies to the traditional model of selling games; targeting Linux for a F2P game is probably even worse, since this model relies on the large player base, which is seemingly not there in Linux case according to statistics.
All in all, it seems that releasing the game on Linux now is done mostly due to developers’ enthusiasm about the platform, goodwill or - rarely - “long term” investment in making their tech cross-platform in case SteamOS turns out to be popular (there’s no immediate value in being cross-platform - developers may fix some bugs while porting, but if those bugs never mattered for their best selling platform, this is still a waste of time).
What are the problems with Linux as a gaming platform?
The overarching problem is that Linux-based operating systems are not designed to facilitate running closed-source binary blobs, let alone blobs that depend on so many system components at once. Graphics drivers are the most visible part, but problems with window, audio and input systems can also be severe, if games are to be held to the strictest standards of competitive PC gaming, particularly for e-sports.
Part of the problem is what we call “Linux” is vague - there are several related, yet different OS sharing that name. Even within a single OS there is sometimes a multitude of choices, sometimes subtle, that can make a problem reproducible only on that user’s machine. There are numerous micro-decisions to be done while writing the software, and sometimes there’s no other specification than the de-facto behavior of the developer’s system. If a user’s system behaves differently, we have a problem.
This, to an extent, applies to Windows as well (which is one of the reasons why console platforms with their deterministic behaviour are cheaper to develop for), but the FOSS principles that put everything on user’s system under the user’s control greatly amplify that problem.
Another problem is the cultural clash. Game developers make money from selling their proprietary software (even if sometimes indirectly), and as such are inherently incompatible with FOSS goals. The effect of this is two-fold: not only the likelihood of the developers’ prior experience with Linux is smaller than what would be expected from an average user, but this operating system is built on the principles that are contrary to and sometimes outright incompatible with their modus operandi, which presents them with unique challenges not encountered on other (proprietary) gaming platforms.
To add insult to the injury, Linux gaming community abounds in radically minded folks, who often are not willing to bridge that cultural gap - in spite of Linux gamers themselves being an eclectic minority within the larger, and even more radical, Linux community. It is curious how people could hold seemingly incompatible beliefs at once, both despising the closed source software and demanding its authors to support it on more FOSS platforms (yes, there are people who attempt to run Steam on gNewSense).
What can be done to improve Linux gaming?
First of all, we (all people interested in Linux gaming) should understand and respect the status quo before attempting to change it. Linux users are the minority among computer users, and that applies to game developers as well. A typical game developer does not possess an intrinsic interest in Linux, they may not have necessary knowledge nor patience needed for an enthusiast OS based on principles hostile to them - and they may happily live the rest of their lives without it. Their enthusiasm lies in creating games, and the proprietary platforms are not hindering their creativity anyhow significantly - learn to understand and respect this world view.
Second, understand where the money is. For a typical, non-indie game, Linux sales constitute negligible percent of the overall PC sales, which are themselves dwarfed by the console sales - to such an extent that even Windows version can be cut. Even for indie games that only sell on PC, Linux sales are unlikely to surpass 10%. It is safe to say that turning profit on a Linux version is extremely hard - if you are a developer, expect to lose money. If you are a gamer, be friendly to developers who are not doing this for profit and can be sometimes bitter about their experience. Also, when trying to reach out to devs for the help, keep in mind that players usually outnumber the developers by several orders of magnitude.
Third, understand the platform - both as a user and as a developer.
As a user, realize that the freedom to build your own system has an associated responsibility - you get to maintain it. You may be the only person on the planet who runs this particular combination of software on this hardware! If anything goes wrong on your system, you - first and foremost - are responsible for fixing it, or at least diagnosing the problem. This is both the blessing and curse of FOSS.
As a developer, do not claim to support more than you actually do. If you only packaged the game for Linux without even running it, state so. If you only can afford to run it on Ubuntu using NVidia drivers to make sure it starts, be upfront about this. Try not to use vague terms as “Linux version”, don’t be afraid to brand it as “Ubuntu version” or “SteamOS version” (if you are testing on these OS of course). In the latter case, I hope that Valve will start a certification program to help provide a consistent experience.
Fourth - pay attention to the attitude and the self-fulfilling prophecies it starts. Support companies that invested into Linux. Right now the best thing you can do for Linux gaming is switching to SteamOS for your gaming purposes (Ubuntu is reasonably close). Embrace the proprietary drivers. Run Steam. Be friendly and supportive to proprietary software developers. This seems to be anti-FOSS - it’s not in the big picture. What is at stake now is whether free software can be used as a foundation for a large scale digital entertainment platform (which involves compromises with proprietary software). It certainly worked for Android, so let’s hope it can work for the SteamOS. Article taken from GamingOnLinux.com.
While PC was the platform that enabled mass-scale game development as we know it now, its Golden Age only lasted from about 1992 to 2005. Back then PC replaced the arcade machines as the primary target for both AAA and smaller game developers, while console ports usually came after a successful PC release and were inferior due to a weaker console hardware.
Things have changed in mid-2000s, when consoles that were at least as powerful as a typical user’s PC appeared. Hard-core gamers with their beefy rigs still had the upper hand, but a mass user’s desktop (slowly turning into a laptop at that point) was outclassed by the console hardware - and this hardware came bundled with online services which were better than what was available on PC (Steam and GameSpy, let alone Games For Windows), without the need to muck with the drivers and run PunkBuster to weed out the cheaters. And, more importantly, the games on the platform were designed to be played from the couch, often together with a friend or a partner - very important thing if you consider the prevalence of casual players over the hard core ones on any platform.
Sales quickly reflected the changed environment - take any cross-platform game of the era and compare PC and 360 copies sold on a sales tracking site like VGChartz - PC figures will be consistently smaller (and don’t forget that PC price is usually lower).
No wonder that for non-indie game developers, PC has not been a popular platform since then. Game developers and publishers alike are more than willing to concentrate on the console market, which consistently accounted for the majority of the sales while being relatively easy to develop for.
What has changed?
“PC renaissance” of early 2010s happened largely due to two factors, one of them being proliferation of the “free to play” format. Initially unpopular in the console-dominated West, F2P spread like wildfire due to the success of MOBA type of games. Both because F2P favors a large installed base and because it is inherently resistant to piracy, F2P once again made PC a viable platform for making money.
The second important factor was the “indie revolution”. Easier access to professional tools (e.g. Epic’s UDK released for free in 2009) and inexpensive engines (Unity, Cocos2D), widespread acceptance of the digital delivery (Steam) and significantly improved compared to early 2000s hardware and software (on Windows side) of an average PC allowed small teams to develop games that could be played by millions.
That said, these days PC is still an “ugly duckling” of the AAA game development. Contrary to its golden age, it is now the PC version that is released after the game proved to be a success, if at all. For whatever reasons, AAA games that don’t utilize “free-to-play” mechanics but are instead sold traditionally, enjoy larger sales in terms of profit on the console platforms - and this is unlikely to change in the foreseeable future.
How does Linux fit into this picture?
I dare to say that it was PC renaissance that enabled Linux gaming and not vice versa. While it is certain that Humble Indie Bundles benefited from claiming Linux support, the Linux ecosystem was not (and is not yet as of now) able to sustain game development even of F2P games and has to piggy-back on OS X porting efforts - or, sometimes, on the fact that the Linux port is comparatively cheap due to a cross-platform engine.
Demands for the Linux version of a game can be sometimes quite vocal, but its actual release does not seem to bring much, if any, profit. This is not because Linux users are not willing to pay in general; rather, it means that targeting the platform is more expensive than the price that can be reasonably charged for a single copy. Other platforms are helped by the economies of scale, but this is not the case for Linux.
The above applies to the traditional model of selling games; targeting Linux for a F2P game is probably even worse, since this model relies on the large player base, which is seemingly not there in Linux case according to statistics.
All in all, it seems that releasing the game on Linux now is done mostly due to developers’ enthusiasm about the platform, goodwill or - rarely - “long term” investment in making their tech cross-platform in case SteamOS turns out to be popular (there’s no immediate value in being cross-platform - developers may fix some bugs while porting, but if those bugs never mattered for their best selling platform, this is still a waste of time).
What are the problems with Linux as a gaming platform?
The overarching problem is that Linux-based operating systems are not designed to facilitate running closed-source binary blobs, let alone blobs that depend on so many system components at once. Graphics drivers are the most visible part, but problems with window, audio and input systems can also be severe, if games are to be held to the strictest standards of competitive PC gaming, particularly for e-sports.
Part of the problem is what we call “Linux” is vague - there are several related, yet different OS sharing that name. Even within a single OS there is sometimes a multitude of choices, sometimes subtle, that can make a problem reproducible only on that user’s machine. There are numerous micro-decisions to be done while writing the software, and sometimes there’s no other specification than the de-facto behavior of the developer’s system. If a user’s system behaves differently, we have a problem.
This, to an extent, applies to Windows as well (which is one of the reasons why console platforms with their deterministic behaviour are cheaper to develop for), but the FOSS principles that put everything on user’s system under the user’s control greatly amplify that problem.
Another problem is the cultural clash. Game developers make money from selling their proprietary software (even if sometimes indirectly), and as such are inherently incompatible with FOSS goals. The effect of this is two-fold: not only the likelihood of the developers’ prior experience with Linux is smaller than what would be expected from an average user, but this operating system is built on the principles that are contrary to and sometimes outright incompatible with their modus operandi, which presents them with unique challenges not encountered on other (proprietary) gaming platforms.
To add insult to the injury, Linux gaming community abounds in radically minded folks, who often are not willing to bridge that cultural gap - in spite of Linux gamers themselves being an eclectic minority within the larger, and even more radical, Linux community. It is curious how people could hold seemingly incompatible beliefs at once, both despising the closed source software and demanding its authors to support it on more FOSS platforms (yes, there are people who attempt to run Steam on gNewSense).
What can be done to improve Linux gaming?
First of all, we (all people interested in Linux gaming) should understand and respect the status quo before attempting to change it. Linux users are the minority among computer users, and that applies to game developers as well. A typical game developer does not possess an intrinsic interest in Linux, they may not have necessary knowledge nor patience needed for an enthusiast OS based on principles hostile to them - and they may happily live the rest of their lives without it. Their enthusiasm lies in creating games, and the proprietary platforms are not hindering their creativity anyhow significantly - learn to understand and respect this world view.
Second, understand where the money is. For a typical, non-indie game, Linux sales constitute negligible percent of the overall PC sales, which are themselves dwarfed by the console sales - to such an extent that even Windows version can be cut. Even for indie games that only sell on PC, Linux sales are unlikely to surpass 10%. It is safe to say that turning profit on a Linux version is extremely hard - if you are a developer, expect to lose money. If you are a gamer, be friendly to developers who are not doing this for profit and can be sometimes bitter about their experience. Also, when trying to reach out to devs for the help, keep in mind that players usually outnumber the developers by several orders of magnitude.
Third, understand the platform - both as a user and as a developer.
As a user, realize that the freedom to build your own system has an associated responsibility - you get to maintain it. You may be the only person on the planet who runs this particular combination of software on this hardware! If anything goes wrong on your system, you - first and foremost - are responsible for fixing it, or at least diagnosing the problem. This is both the blessing and curse of FOSS.
As a developer, do not claim to support more than you actually do. If you only packaged the game for Linux without even running it, state so. If you only can afford to run it on Ubuntu using NVidia drivers to make sure it starts, be upfront about this. Try not to use vague terms as “Linux version”, don’t be afraid to brand it as “Ubuntu version” or “SteamOS version” (if you are testing on these OS of course). In the latter case, I hope that Valve will start a certification program to help provide a consistent experience.
Fourth - pay attention to the attitude and the self-fulfilling prophecies it starts. Support companies that invested into Linux. Right now the best thing you can do for Linux gaming is switching to SteamOS for your gaming purposes (Ubuntu is reasonably close). Embrace the proprietary drivers. Run Steam. Be friendly and supportive to proprietary software developers. This seems to be anti-FOSS - it’s not in the big picture. What is at stake now is whether free software can be used as a foundation for a large scale digital entertainment platform (which involves compromises with proprietary software). It certainly worked for Android, so let’s hope it can work for the SteamOS. Article taken from GamingOnLinux.com.
0 Likes
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Patreon
PayPal
Unfortunately the whole library situation is more complicated than what people seems to believe.
For simple libraries that just provide some piece of internal technology, bundle it and be done with it, but some other libraries are there to talk to system components, and backward compatibility there can be a little flaky.
An example is pulseaudio, I have to remove the steam runtime bundled version because it cause some freeze on start because of version mismatch between the libpulse (provided by steam) and the actual pulseaudio server (provided by my system).
The lack of familiar development environment is another problem, I do not like Visual Studio, but the large majority of game developers only swear by it, and nothing comes closes to it on Linux, especially on the debugging side. Things are improving (RAD game tools is working on a new debugger), but we cannot expect Windows centric developers to feel familiar on Linux, it is a very different environment.
I was very used to Linux myself, my main motivation for porting the games was being able to ditch Windows at work, but besides me, in a ~30 programmer studio, I do not think anybody (although all very competent programmers) had the Linux knowledge I had. So you can imagine what can happen for a smaller studio, its likely for them not to have any Linux guy.
Do not forget as well that windows, with all its faults, has maintained backward *binary* compatibility accross the whole system, you can still run binaries from more that 10 years ago and it will work. We unfortunatly cannot say that on Linux, even on a single distribution.
Pulseaudio notwithstanding because I'll agree with 100% that that is one flaky lib, most libraries, in my experience with Linux as a whole, have not been so problematic for me as an end user. As long as I can find the library either via my distro's package manager or via a source code package I can use it. Case in point, I was just recently compiling a game that uses SDL-1.2 and it would not acknowledge the fact that I have SDL-2.0 on my system so I had to find it and get it working but once I did the game compiled and ran smoothly but I think it may a different experience for an end-user like myself and a developer.
Full disclosure: I work for GOG and this is kind of our specialty: bring back old DOS and Windows games from the dead in a legal and technical sense. That said, I have to respectfully disagree with you on this very point as we constantly have to battle with compatibility issues between Windows versions.
The binary compatibility you refer to might be the case with programs that do not require the use of specific rendering libraries or APIs and such but games?No. For example, the latest culprit these days that breaks Windows compatibility is directdraw. This function is wholly deprecated in Windows 8/8.1 (Windows 8/8.1 emulates directdraw now) and a plethora of early Windows games used this very function for graphics rendering and the like.
In short, I have yet to see a huge number of games that have binaries that are compatible to the point that they run just like they did back when they were new. Could you give me your definition of "backward binary compatibility" when it comes to Windows games? Because for us, just having the game run is not enough :)
Oh, do not get me wrong, the library situation is not broken, most libraries do a good job keeping backward compatibility. Still its not always trivial: besides pulseaudio, I have been hitting problem with glibc, I had a very up to date glibc on the compilation machine, and the memcpy behaviour had been changed not to allow overlapping memory, so, for backward compatibility reason the actual memcpy symbol name had changed (to memcpy@GLIBC_2.14 IIRC) so that older program relying on the old behaviour would still work. Unfortunately that meant the binary could not run on any Linux that did not have that latest glibc version, as the memcpy@GLIBC_2.14 symbol was not defined.
It is definitely fixable, again I am just wanting to show it is not just a matter of bundling the libs.You have to be careful, and develop a good understanding of Linux internals.
The windows solution to that problem is not very elegant either (you basically end up with your system filled with every libc/libstdc++ version ever released by microsoft).
I am talking binary compat up to ~10 years ago, thats after DX9 (which has already deprecated direct draw). Of course it is not perfect, its all software, but I expect most games that targeted DX9 on Windows XP to still work on Windows 7/8 out of the box. On the contrary, I expect a dynamic linked game released for linux 10 years ago to be a little more painful to get to work.
Again, I love Linux, I want games on Linux as much as the next guy, I am just trying to give people a better idea of the amount of work it represents.