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
They have to do this, everybody would love that. As microsoft and sony does, Valve also has to make the development to their platform a lot more easier. Of course the steam-runtime was a (very) good step in the right direction, and Vulkan too, and steamOS as a target OS, but I'm confident than even more can be done to make linux development easier.
Last edited by edo on 6 July 2015 at 9:24 pm UTC
I have no issue with being patient and I try to help others to see that patience is needed. It does suck sometimes as an AMD user but at the end of the day getting angry doesn't help. If we as a community can help the devs improve their game then great but the devs have to be willing to accept the help and want to improve it.
I want ask questions:
- What about the current situation that sales can determined aproximatly but not real well ? I give an example: Bioshock Infinite / TW2 / Spec Op's and huge amount of other games where in my library before the linux version (windows days / linux wine days). As sadly will be Darksiders and Darksiders 2 :(
- What about none measurable Profits? For example i know Gamers which never would had touched some indie games if i wouldn't advice them this games.
While we all know that PC Gaming is broken to the end for AAA tittles i had a huge hope that indie games can stop this trend. In a way they did but what i see in terms of linux makes me sad. The same arguments publisher gave towards pc gameing (we make less money) are used to excuse bad quality on linux from some of those indie dev's. So do you suggest if we know what lead to the bad overall state of gaming on windows , we should still support the same excuses?
I know that for a dev right of now it's hard. You mentioned a vague platform. I agree and disagree. The linux gaming community always supported the idea that a dev target one distribution. Ubuntu in the beginnig, the better choice now would be steam os. But even that isn't mostly done in a good way. Some examples which find scary:
System requierments -> omg so inexactly across the board
Requiering drivers outside of the distribution -> as a customer why do i need to update my drivers if the dev targeted a distribution and therefor the included drivers ?
Communication -> Sometimes (of course it's not all of them) i realy think thats not true... You publish a game on a platform but say loudly this platform sucks? You take money but aren't even willed to check if the error could be on your side?
Bug fixing -> This is mostly a issue with Early Access tittles which even raise the bar. But in my oppinion if the linux community try to show you bugs for a product they bought to improve on their platform too. Don't ignore them or call them stupid or something like this (everything seen already)
Some points i want to add my thoughts:
(vague Platform)
- Linux has a standard. It's called LSB. I don't think it's ready for gaming but if it isn't why don't ask for changes ?
- SteamOS and SteamSDK should be the industry default as long LSB is a no go. I don't agree they are close enough to ubuntu or debian to use them as development platform. Some examples why:
- systemwide pulseaudio (i don't agree with that decission but it is how it is)
- compiz
* compiz can fix 99% of the vsync issues
* games don't need to implement vsync just a frame limitter (overheating) and the user can do a systemwide vsync on / off and set the desired framerate in the game
- bigpicture mode and controller support
* as much as i think mouse and keyboard are a great input method , lets be honest here controller / touch are the one most people are used too. So if there is no reason every game should support a pure controller based input
system using SDL2 as default (so it is hardware independend as much as possible)
What do i think can be done to improve:
- we not only need a steamsdk but we need a steamos development edition (at least a easy to use multipackage selection of the tools to install using the package management)
* pre-installed with the steamSDK and configured so a build is using the steamsdk libraries first if installed in the linux box
* including basic development tools freely (or in terms of valve freely available) for steamos. I think of default IDE's / Debugger / buildsystems (maybe even templates) and so on
* a ruleset how properity tools integrate into that -> i'm thinking here of unity 3D / unreal and so on (certification)
As hard as it sound's but the freedom and huge amount of ways how you can develop for linux scares windows dev's which are used to install visual-studio and everything integrating into it. At this point i even agree with the dev's stating that finding resources of how to do it leads to a nightmare amount of information which you can't decide what you realy need and what not.
There is one point which i realy think is vital for making a longterm success and agree totally with the article. We need a default featureset standard and make it deterministic for the dev's. Where i disagree is that we should agree to that being a problem and just take it.
So lets talk about the current status (from my point of view). A game / engine on the lowest level needs some systems:
1.) userinput | Staus: ok | SDL2 does a wonderfull job
2.) soundoutput | Status: medium | SDL2 / OpenAL will do the job -> If we check above makeing pulseaudio systemwide on steamos gives maybe another way to program or archive audio (i wonder if SteamOS will get a RT kernel and use RT Audio)
3.) graphic's | Status: WIP
3a) 2D graphic's should be fine with SDL2 and or most engines don't have problems with 2D graphic's
3b) 3D graphic's if an engine is used -> Unity 3D / Unreal / Source / Source 2
- 1st and foremost it's possible and works reasonable well
- 2nd bugs / performance issues can't be fixed between user and dev's but needs to be fixed between dev's and engine provider. So please dev's give it to the people which are responsible or use another engine or check if you can fix on your side (assets / shader and so on). As stated in the article , ask the customer to provide the information as best as possible. Hint checkout this thread how this can work -> http://steamcommunity.com/app/250560/discussions/0/558751813249138496/. As a dev remind your that you only have to support one distribution which is highly preconfigured (SteamOS).
3c) 3D with OpenGL
This is a huge WIP area. Ok what does most dev's complain -> different behaivior by different graphic stacks. What i don't understand and it bothers me (the customer can't change anything) is the following: OpenGL is done by the Khronos group. If there are unclear corner cases (example: https://bugs.winehq.org/show_bug.cgi?id=34052) why doesn't this get reported and gets fixed within the spec? I think if the dev's put themself together they are powerfull enough to do so. An example how this can be is a external OpenGL Bug DB only filled by dev's using opengl but public visiable so consumers can make informed decissions which graphics card vendor fix their shit and which doesn't. If you don't think there is enough power by the group of dev's at least valve could do something against it. SteamOS drivers could get certified. Certification is only given when a testsuite is gone thru. Of course this testsuite includes the mentioned corner cases and defines the outcome. So a programer against those certified drivers can expect a certain outcome.
3d) 3D with Vulcan (future hope)
All the points above can be solved without the customers and should be (in my eyes) solved without the customer (eg: linux gaming community). On last thing i realy want an answer:
Why are we always the bad toxic community here cause we are just a small marketshare but dev's are allowed to ignore all helping advices we give and go on claiming it's impossible to program for linux even it already exists or will be there soon ?
Some of the advices i talk about and a huge amount of linux users at least wrote once under a not working port:
- use SDL2 at least for Input and Windowmanagement
- Unity 4 has performance issues with AMD hardware please check what you can do
- The software only use 1 thread from my 4 core / 6 core machine
- __GL_Threaded_Optimisations=1 helps performance wise
- LANG=C fixes issues
Last edited by Glog78 on 6 July 2015 at 10:12 pm UTC
First off, since you're supplying a binary blob please, please do not rely on library X version Y to exist on your customers install. Rely on Steam runtime instead, the rest is up to Valve and distro maintainers.
If you don't want to use Steam runtime (or need something that it does not include), learn the very few gotchas about dynamic linking / library loading in Linux compared to Windows and supply your own. Usually this means a simple launcher script. If you need only a handful of libraries or binary size is not an issue, you can also consider static linking.
So, target either Linux (not Ubuntu, not Mint, not whatever, just Linux) or SteamOS. If you target Linux, you will need to supply libraries on your own and if you know what you're doing, it'll most likely work for majority of the users. It'll also run on SteamOS. If you target SteamOS, you worry only about compatibility with SteamOS but please, stick to the runtime in that case, and your game will most likely work elsewhere too if both distribution packagers and you have done their job properly. It really is that simple.
Driver problems unfortunately are there. I don't think it's a responsibility of a gamedev to fix the more serious driver problems. If you run into such problems (and most likely you will), it's your (constructive and detailed) feedback that is needed to get those problems fixed. I think most of us would not mind if you only target binary drivers at first. Heck, many would probably not mind if you would only target nvidia binary drivers at first. That is, if there is a good explanation for such behavior and support for other drivers coming in a future patch. Be clear what is supported, what is not and why and it'll all be alright.
I wouldn't worry about the ethics and philosophies either. Those that care are not going to install Steam or any other binary for that matter. I'm pretty sure most of us have this thin line about what we accept and what we do not. If a gamer only accepts free open source products, (s)he probably does not have any interest in a closed source game in a first place.
One last thing.. I would really like game developers to just ask us for help if they face problems with Linux. Chances are there are devs and experienced/veteran users in the audience who can actually help you get started or help you get your problems solved. It's a different platform, different ecosystem and a different user base so use the knowledge that is already out there instead of just banging your head to a wall while reinventing the wheel for nothing.
Sorry for the long comment, I just had to get it all out.
Last edited by skry on 6 July 2015 at 10:59 pm UTC
Anyhow, what I would add is, apart from what has been mentioned - nothing is impossible and Linux makes an excellent platform for gaming despite the different user configurations out there. If only it was distributed and marketed on the same level as Windows you'd see the magic.
Here comes Ubuntu - the OS that to an average geek seems as restricting, to an average consumer beneficial, because a restriction (some components less customizable than others) is often not a bad thing, but prevents harm to be done.
Gabe Newell even stated, that concerning VALVe games they achieved better performance on Linux systems rather than Windows.
Great!
I can only speak for myself, ofc...
Yes, I'm upset if a developer only supports "Nvidia".
However, this is only because there is no further
information WHY AMD Catalyst is not supported.
I guess, the detailed answer is often missing hiding
behind the usual "Catalyst is bad, slow, yadda, yadda".
Why not posting information about the actual issue?
Make a blog post, whatever.
This should not take too much time, really.
Maybe even here at GoL. ;)
But - imho - this is potentially damn interesting.
Furthermore, it might put more pressure on AMD.
In particular if it is an issue shared among different
AAA developers.
TL;DR
I won't start a riot if you state "AMD not supported".
But please be more transparent about the issues.
It's interesting and probably helpful.
Last edited by sub on 6 July 2015 at 11:27 pm UTC