Support us on Patreon
PayPal
We see a lot of games get delayed for Linux, but why is this? I decided to ask around about the difficulties facing developers when porting games to Linux.
I posed a question to a bunch of people involved in games development and Linux porting. I asked three simple questions, the same questions to each of them.
I've included links to get in touch with these developers, for any game developer wanting their game ported to Linux, these should be on your list.
First up, is well known and long-time Linux game porter Ryan “Icculus” Gordon [Website, Twitter]. Noted Linux ports include: multiple Unreal Tournament titles, Prey, Psychonauts, Killing Floor and plenty more.
Why do you think Linux games get delayed?
Ryan “Icculus” Gordon: Often times, for me at least, I get brought onto a project that has already shipped for Windows, made by a team with dozens of developers over several years. Almost always, I'm showing up for the race after it's already been run.
My attitude has always been that building a Linux game library--as in a historical archive of human creation, not your Steam game list--is important to the common good and that Hot Fresh New Bestsellers aren't.
This wasn't what you were asking; mostly I'm just telling you that I'm really bad at Capitalism. I understand why being a good _consumer_ demands that we demand same-day releases, but being defined by what we swallow and how quickly we get to choke it down is just not a way I want to live.
What do developers need to do to ensure a timely Linux release?
Ryan “Icculus” Gordon: The rare times where I shipped at the same time as the Windows version, it was because I was working with the team before they shipped, and was making portability changes in the same codebase everyone else was working out of.
- Don't make a game that depends on Direct3D. All the hard hard work is getting the thing to run with OpenGL.
- If you're building something big and complex, use Unity or Unreal Engine 4 so most of the heavy lifting is already done, and the Linux guy is mostly fixing and polishing instead of rewriting large pieces of complex code. If you wrote your own engine for a AAA-level game, expect a port of it to take 6 to 12 months. If this is a small indie game, this advice isn't so important.
(I usually have a lecture here about "use SDL, OpenGL, OpenAL, scripting languages, etc"...but honestly, the companies building big big games are way past the point where this advice is going to help.)
What is so difficult about bringing games to Linux?
Ryan “Icculus” Gordon: The first 90% of the work is getting it to compile at all. The next 90% of the work is rewriting the renderer.
And now we have Aaron Melcher of Knockout Games [Website, Twitter]. Notable Linux ports include: Xenonauts, SOMA, Shadow Warrior, Darkest Dungeon and more.
Why do you think Linux games get delayed?
Aaron Melcher: All other platforms have better total sales. There is no grantee that a game is successful and timing is everything. To hit release windows things have to get cut. If the developer has to chose to cut a game feature OR the Linux port, the Linux port will always be cut/delayed. Almost all of my ports are for games that have been proven successful and can afford to release a Linux version.
What do developers need to do to ensure a timely Linux release?
Aaron Melcher: Plan for the port realistically. Be able to easily develop Linux ports on Windows. Almost all other target platforms for games can be developed and deployed from a windows dev machine. The less friction involved with compiling a Linux executable the more likely there is a day one Linux release. We see hard examples of this from engines that have a Linux export target (Unity, Gamemaker, etc.). Even then there is always some amount of extra effort and without the fiscal motivation (large game sale potential) Linux ports will rank lower in priority.
What is so difficult about bringing games to Linux?
Aaron Melcher: Actually developing/testing on target Linux distributions. Debugging tools are foreign and primitive compared to what Windows/Mac developers are used to. Many game developers are not even super users so getting around on a Linux distro can be a challenge to the average developer. Even translating what a Linux player has in a bug report they send to a developer can be a challenge. Developers don't use Linux regularly (on average) so players are more informed of problems/solutions then them. This is not the case on other platforms for the most part.
Now for another point of view we have Ethan "flibitijibibo" Lee [Website, Twitter]. Ethan is responsible for the FNA project and tons of Linux ports like the soon to be released Charlie Murder & The Dishwasher: Vampire Smile and a great many more.
He went about answering the questions in a different way, so all three are essentially together in this one bit below.
Ethan Lee: You and I both know that these are age-old questions. They've not become any less important, but it makes you wonder what makes the same question remain interesting no matter how much time passes. On the surface, it's easy to give the most comprehensive answer possible:
Q: Why do you think Linux games get delayed?
A: Programming is hard.
Q: What do developers need to do to ensure a timely Linux release?
A: Don't make release dates.
Q: What is so difficult about bringing games to Linux?
A: Programming is hard.
While comprehensive, they are certainly very frustrating answers. Even to other programmers reading, it may seem like it's just a cop-out answer. But I suspect it's no different from what you get out of a typical interview, other than that it is a whole lot shorter in word count.
But much like how the best programming is done from data-oriented design rather than object-oriented design, a proper answer that would solve the mystery wouldn't be to please a crowd with the Cure-All Magic Potion, which is what people want, but to explain a solution to a real, actual problem, which is actually what's prevalent in the sort of work that we do.
The real actual problem, however, is different every time. So it's almost pointless to answer it just a single time without context.
I could bring up a point about how FNA XACT worked fine on CLRs where the GC doesn't compress unpinned memory but fails silently based on an exact point in time where, say, an OpenAL buffer is allocated at the same time the GC is reorganizing the heap even for blocks of memory that should be pinned but just aren't for some reason, but it turns out that is relevant only to Windows, which I suspect isn't what the readers care about.
On the other hand, I could talk about how a few games require specific Visual Studio C# compilers for all of its platforms, where it would then be relevant to making games on Linux stable and reliable, but that has no relevance to standard XNA games, much less programs not written in C#, which are in the majority.
Unless you count Unity games which are written entirely in C# by the game developer, but that's all game scripts run on top of a special branch of the Mono (or IL2CPP?) runtime which is wired to a black-box engine which could have various different behaviors on any platform (as is admitted even by Unity developers, particularly for things like CultureInfo behavior), no matter how much the developer worked to target each platform, all of which have different behaviors no matter what it is the game scripter does.
And that's on an engine that's supposed to have multiplatform support, which most don't actually have unless they're one of those licensed engines which at best only advertise it rather than actually have it to the extent that is the easiest to advertise without having dozens of asterisks that would undermine its alleged amazingness, but it's not that big of a deal because they'll figure it out eventually, unless it's """""open""""" source in which case we probably never actually knew but whatever because they can figure it out for us I guess.
But forget all that anyway, the games people apparently care about are on engines that are either entirely internal or are branched off to the point of being entirely self-made, where either way there's not even the facade of it working anywhere other than perhaps Win64/PS4/Xbone, and that may only be after it's been mutated from an engine that was Win32/360-only with some kind of demonic PS3-ish code path that might have only tangentially been relevant to *nix platforms had it not been written entirely with PPC intrinsics for even the tiniest of things because lord knows what it was like to get anything running on any console of that time, much less a console that was deliberately as difficult to work with as possible.
And that's with an engine that is wholly internal and thus we don't have a full understanding of how it works from the outside, and all the real legitimate answers that one could give to these questions are under NDA by order of either the owner of the product or the owner of the middleware, whichever is making it more inconvenient for someone who wants to actually explain why the grass is clipping through the clouds several miles high while no sound is playing.
Also, programming is hard.
Now we have Simon Roth [Twitter], developer of colony simulator Maia who wrote an interesting blog post titled 'How to delay your indie game'.
Why do you think Linux games get delayed?
Simon Roth: Two things. Firstly, I think lack of awareness is a factor. Some developers don't know about Linux, and so don't really plan for it. It's assumed to be a minuscule job and put off again and again until it is only considered approaching beta. That's when it's properly accessed and the time put aside for it breaches past the release date.
Secondly the financial aspect. If a Linux release will give a developer 2-5% more sales, they might put it off. Sometimes indefinitely. In pure business terms an extra round of localisations might be more fruitful for many titles (such as reworking aspects of a game for the Chinese market).
What do developers need to do to ensure a timely Linux release?
Simon Roth: A platform agnostic engine and a game that runs cleanly within the engine. It's really a no-brainer for most devs, since having multiple compilers building the same code is a good way to find some of the insidious low level bugs that make it past Visual Studio or Xcode.
What is so difficult about bringing games to Linux?
Simon Roth: On the porting front, many developers are still sitting on engines that have not progressed much beyond DirectX 9. Modern graphics programming has closed the gaps between the graphics pipelines, the older the pipeline the more time consuming a port will be.
There's also a surprising lack of people with Linux in their skill sets in the game development pipeline. Programmers who will work (well) on Linux are nowhere near as common as those comfortable on Windows and OSX.
It's even worse when it comes to testing, as you need quite technically adept QA to be able to work on many different Linux setups. This specifically has been particular trouble for my own development efforts.
Next up, we have Josh “Cheeseness” Bush [Website, Twitter]. Notable Linux ports include: Day of the Tentacle Remastered. He’s also writing his own game engine named icicle.
Why do you think Linux games get delayed?
Josh “Cheeseness” Bush: Personally, I feel the number one cause of delayed game releases or game ports are hurdles or priority changes that couldn't have been foreseen when previous timeframes were settled on.
I think it's worth considering that there are two types of "delays", deviations from internal timelines, and changes in dates that have been announced to future customers.
The first of these is normal, and is an accepted and acceptable part of software development. All the scheduling and planning we do when making a game isn't a hard and fast set of rules, it's a baseline against which to judge and compare the impact of changes so that every decision that's made along the way can be more informed. This flexibility is important because it gives developers the freedom to make the right decisions based on the insights they've gained during development. Remember that SimCity has its origins as a level editor for a shootemup, Halo was first envisioned as an RTS, and closer to home for us Linux users, Half-Life 2 underwent massive structural shifts later in development - by growing beyond their initial implementations, all of these titles were able to give players better and more enjoyable experiences.
Making games is a lot different from say, building construction, where millennia of industry culture anchored around our static laws of physics and materials that change very little from decade to decade has created a safe and predictable development environment that has very few unknowns.
By comparison, software APIs, hardware capabilities, development models, best practices and consumer expectations change near-constantly - it'd be more like trying to design and construct a building in an environment where at least half the laws of physics and your materials are different between any two given projects. There's a lot more exploring, inventing and iterating involved, and because of this, time schedules and budgets aren't the same kind of tools.
Thinking about the technical hurdles that hit Linux support at this level, it's usually a mix of unfamiliarity with what's involved, existing platform specific code, and needing to respond to other commitments to existing customers and deliverables.
Having Linux support fall behind other platforms is a sad reality that I think Linux users need to be understanding of. If a game is already released on another platform, then I'd have more respect for a developer who gives priority to existing customers over customers they don't yet have - the opposite only suggests that we'll be treated poorly when we are finally supported!
To some developers, staggered platform releases means more opportunities for press coverage and does offer more opportunity to focus on/engage with each platform's audience when it's their turn for release. Conversely, it means a lower initial player base and makes it a little more difficult for awareness of the game to travel via word-of-mouth when part of its audience can't play.
When a game is developed without ongoing testing of all target platforms, it's possible for platform specific code to creep into the codebase. Different compilers and different platforms tend to do things a little differently, and what works in one place happily might be a significant problem elsewhere. It doesn't help that Windows tends to be a little more slap-happy and code that might crash on Linux can still appear to run happily (while causing problems that aren't immediately visible or don't manifest themselves in significant ways).
Sometimes, a lack of familiarity, whether that's first-time Linux supporters finding some unexpected work when they realise that we generally have platform sensitive filesystems, or an experienced porter not being familiar with the testing and QA timeframes of a developer they're working with. Since so much of game development is carving a piece of software out of unknowns, there's a huge amount of room for unfamiliarity to impact on Linux development. Realistically, it's often impossible to understand how long a problem will take to fix until after it's been resolved.
Pressure and attention from expectant future customers can also slow down some developers, and it can often come down to a situation where for every 30 second "How's that Linux version coming along?" question that needs answering, there's another 20 minutes lost regaining focus and getting back into development.
Having to regularly give people answers that aren't "The Linux version is ready!" can also make it hard for a developer to feel positive about their work. Since developers who feel happy about their work are more productive than developers who don't, this can also slow things down a little.
The second type of "delay" is one that I think is the one that I would love to see more developers giving attention toward, and although they're usually the result of the first type, the way that they're handled is entirely different.
Handling these situations appropriately is an exercise in expectation management, and I think the slip-up that many developers make is in not helping their future Linux customers avoid making assumptions.
Some developers (particularly porters!) don't have the ability to speak openly about their projects, and sometimes that can lead to people making guesses or assumptions about the state of things - a situation that sadly often results in disappointment.
For many independent developers without dedicated PR people, it can often feel like the best option is to knuckle under and keep working instead of breaking momentum to stop and explain what's going on and risking making things take longer.
You might notice that few of these items seem specifically relevant to supporting Linux, and you're right. Generally speaking, Linux games are subject to the same kinds of pressures and hurdles and timeframe adjustments that projects on any other platform are.
The difference is that we just happen to typically be on the tail end, and when people on other platforms are happily playing their games, it becomes easy for us to have negative feelings when visible "delays" occur.
What do developers need to do to ensure a timely Linux release?
Josh “Cheeseness” Bush: Assuming that timely means "relative to other platforms", then the most effective way that I can think of is to develop games on Linux. In some ways, you can consider compatibility with your development/primary testing environment to be gained "for free".
As a developer, if you write a piece of code that doesn't compile or doesn't do what you're expecting on your development machine, you address it straight away (whether that's through debugging and fixing or trying a different approach).
You're unaware of any code that would crash/misbehave on platforms you're not writing on, and so don't have any reason to reconsider them, resulting in "platform specific code". The more of these that build up and slip through, the more work there is to do, and the longer they go unnoticed, the more work it's likely to take to dig them out without breaking behaviour on other platforms.
This leads to the second most effective way to keep Linux support up to speed with other platforms: treat Linux as a first class platform and include Linux builds in automated and manual testing throughout development. Platform specific code gets identified quickly, and even if it's not addressed right away, where it is and what implications it has are known and can be taken into consideration before making other functionality dependent on that.
Beyond that, if a developer can hold old off on releasing on any platforms until Linux support is ready, that prevents any Linux specific delay, but does mean delaying revenue - not something that all developers can afford to do.
For a lot of developers though, those options are difficult to embrace, either through ties to existing development environments, limited testing resources, unfamiliarity/uncertainty toward working with Linux, or contractual obligations giving certain platforms time constraints that other platforms aren't subject to.
For those, I feel the best option is to avoid talking about dates or timeframes until work is completed. If you haven't accidentally communicated dates that can be construed as deadlines, then there's nothing that can be seen as a "delay".
If a developer is finding that they're struggling to overcome a Linux specific issue, they may find value in reaching out either to any Linux users in their community, or someone like myself who's willing to lend a hand to help other developers have positive experiences.
Making use of enthusiasm and experience within the community can often help speed things along, but this can often require a level of open communication that some developers don't feel comfortable with or are unable to embrace.
What is so difficult about bringing games to Linux?
Josh “Cheeseness” Bush: I think each project has its own set of ups and downs, and even for those who do a lot of porting, there are going to be pitfalls and hurdles that slow things down.
Even when using engines with cross-platform support like Unity, or like FNA that in an ideal situation are a drop-in replacement for non-Linux supporting technologies, there's still often an issue here or there to address.
I develop all of my games on Linux, so this is thankfully something I don't have to worry about. The Linux ports that I've been involved with personally have been about as straightforward and friendly as ports possibly could be.
Over the years though, I've helped a lot of other developers overcome their own problems, and there are a few things that stand out to me.
When approaching something new, it's often easy to feel that problems are more difficult than they would be if they were in a more familiar environment. Less experienced developers pursuing Linux support have an additional psychological hurdle to cross (that's not to say that problems are trivial, just that it's harder to objectively assess them without experience and context).
Similarly, unfamiliar tools can be significant hurdles for people. For those not used to working with the debuggers available on Linux, embracing them can be an insurmountable challenge. Sometimes different tools require different workflows, and that too, is more disruption than some developers are willing to put up with. For some, new tools or alternative interfaces might help make working on Linux a little more accessible.
Third party Linux porters often have to deal with decisions made by upstream developers that were not made in the best interests of Linux builds. Many games are developed before Linux support is on the roadmap - for example, when working on Day of the Tentacle Remastered in 2016, I had to deal with the consequences of the original game having case consistency in include statements was important. There was no possible way for the SCUMM engine developers in the 80s to foresee that that would be a problem, but it increased the work I had to do regardless.
For developers doing in-house Linux support, this can be a problem too. It's not uncommon (though perhaps less common now than a few years ago) for a developer to make dependency, middleware, engine or other tech choices with the assumption that they will behave on Linux, only to later find that that those choices mean additional work is now involved.
I would like to thank each person for taking time out of their always busy schedule of being awesome. It's great to get some insight into how developers think on issues such as this, even if the questions are something that repeatedly gets asked, getting up to date thoughts from such developers is always a fun read. It's good to keep checking in too, so we can see how Linux has changed each time and if any new issues need addressing.
To sum it up: it seems like there's a rather large variety of issues developers have to deal with when bringing games to Linux including (but certainly not limited to):
We have a tough hill to climb as a gaming platform, so hopefully this gives you a small insight as to what developers face and think.
I think market-share is always going to be an issue, it's an absolute mountain we have to climb if we are to push our numbers up. Still, being small in terms of percentage isn't as bad as some think, since that percentage is of a large number it still means there's quite a lot of us. Just not a lot when in comparison to Windows.
When looking at NetMarketShare, in Q2 2014 we had a total share of ~1.58% and now in Q2 of 2017 we have ~2.14% with it being above 2% for 10 months in a row now. Doesn't seem like much, but that's likely quite a large of sum people. It's also pretty healthy to see us remain above that 2% spot for so many months in a row. Who knows, maybe in another year we can hit 3%? I can dream!
Hopefully you enjoyed a little longer read than usual from us!
Other well known developers were asked, but it seems others are too busy porting awesome games. Article taken from GamingOnLinux.com.
I posed a question to a bunch of people involved in games development and Linux porting. I asked three simple questions, the same questions to each of them.
I've included links to get in touch with these developers, for any game developer wanting their game ported to Linux, these should be on your list.
First up, is well known and long-time Linux game porter Ryan “Icculus” Gordon [Website, Twitter]. Noted Linux ports include: multiple Unreal Tournament titles, Prey, Psychonauts, Killing Floor and plenty more.
Why do you think Linux games get delayed?
Ryan “Icculus” Gordon: Often times, for me at least, I get brought onto a project that has already shipped for Windows, made by a team with dozens of developers over several years. Almost always, I'm showing up for the race after it's already been run.
My attitude has always been that building a Linux game library--as in a historical archive of human creation, not your Steam game list--is important to the common good and that Hot Fresh New Bestsellers aren't.
This wasn't what you were asking; mostly I'm just telling you that I'm really bad at Capitalism. I understand why being a good _consumer_ demands that we demand same-day releases, but being defined by what we swallow and how quickly we get to choke it down is just not a way I want to live.
What do developers need to do to ensure a timely Linux release?
Ryan “Icculus” Gordon: The rare times where I shipped at the same time as the Windows version, it was because I was working with the team before they shipped, and was making portability changes in the same codebase everyone else was working out of.
- Don't make a game that depends on Direct3D. All the hard hard work is getting the thing to run with OpenGL.
- If you're building something big and complex, use Unity or Unreal Engine 4 so most of the heavy lifting is already done, and the Linux guy is mostly fixing and polishing instead of rewriting large pieces of complex code. If you wrote your own engine for a AAA-level game, expect a port of it to take 6 to 12 months. If this is a small indie game, this advice isn't so important.
(I usually have a lecture here about "use SDL, OpenGL, OpenAL, scripting languages, etc"...but honestly, the companies building big big games are way past the point where this advice is going to help.)
What is so difficult about bringing games to Linux?
Ryan “Icculus” Gordon: The first 90% of the work is getting it to compile at all. The next 90% of the work is rewriting the renderer.
And now we have Aaron Melcher of Knockout Games [Website, Twitter]. Notable Linux ports include: Xenonauts, SOMA, Shadow Warrior, Darkest Dungeon and more.
Why do you think Linux games get delayed?
Aaron Melcher: All other platforms have better total sales. There is no grantee that a game is successful and timing is everything. To hit release windows things have to get cut. If the developer has to chose to cut a game feature OR the Linux port, the Linux port will always be cut/delayed. Almost all of my ports are for games that have been proven successful and can afford to release a Linux version.
What do developers need to do to ensure a timely Linux release?
Aaron Melcher: Plan for the port realistically. Be able to easily develop Linux ports on Windows. Almost all other target platforms for games can be developed and deployed from a windows dev machine. The less friction involved with compiling a Linux executable the more likely there is a day one Linux release. We see hard examples of this from engines that have a Linux export target (Unity, Gamemaker, etc.). Even then there is always some amount of extra effort and without the fiscal motivation (large game sale potential) Linux ports will rank lower in priority.
What is so difficult about bringing games to Linux?
Aaron Melcher: Actually developing/testing on target Linux distributions. Debugging tools are foreign and primitive compared to what Windows/Mac developers are used to. Many game developers are not even super users so getting around on a Linux distro can be a challenge to the average developer. Even translating what a Linux player has in a bug report they send to a developer can be a challenge. Developers don't use Linux regularly (on average) so players are more informed of problems/solutions then them. This is not the case on other platforms for the most part.
Now for another point of view we have Ethan "flibitijibibo" Lee [Website, Twitter]. Ethan is responsible for the FNA project and tons of Linux ports like the soon to be released Charlie Murder & The Dishwasher: Vampire Smile and a great many more.
He went about answering the questions in a different way, so all three are essentially together in this one bit below.
Ethan Lee: You and I both know that these are age-old questions. They've not become any less important, but it makes you wonder what makes the same question remain interesting no matter how much time passes. On the surface, it's easy to give the most comprehensive answer possible:
Q: Why do you think Linux games get delayed?
A: Programming is hard.
Q: What do developers need to do to ensure a timely Linux release?
A: Don't make release dates.
Q: What is so difficult about bringing games to Linux?
A: Programming is hard.
While comprehensive, they are certainly very frustrating answers. Even to other programmers reading, it may seem like it's just a cop-out answer. But I suspect it's no different from what you get out of a typical interview, other than that it is a whole lot shorter in word count.
But much like how the best programming is done from data-oriented design rather than object-oriented design, a proper answer that would solve the mystery wouldn't be to please a crowd with the Cure-All Magic Potion, which is what people want, but to explain a solution to a real, actual problem, which is actually what's prevalent in the sort of work that we do.
The real actual problem, however, is different every time. So it's almost pointless to answer it just a single time without context.
I could bring up a point about how FNA XACT worked fine on CLRs where the GC doesn't compress unpinned memory but fails silently based on an exact point in time where, say, an OpenAL buffer is allocated at the same time the GC is reorganizing the heap even for blocks of memory that should be pinned but just aren't for some reason, but it turns out that is relevant only to Windows, which I suspect isn't what the readers care about.
On the other hand, I could talk about how a few games require specific Visual Studio C# compilers for all of its platforms, where it would then be relevant to making games on Linux stable and reliable, but that has no relevance to standard XNA games, much less programs not written in C#, which are in the majority.
Unless you count Unity games which are written entirely in C# by the game developer, but that's all game scripts run on top of a special branch of the Mono (or IL2CPP?) runtime which is wired to a black-box engine which could have various different behaviors on any platform (as is admitted even by Unity developers, particularly for things like CultureInfo behavior), no matter how much the developer worked to target each platform, all of which have different behaviors no matter what it is the game scripter does.
And that's on an engine that's supposed to have multiplatform support, which most don't actually have unless they're one of those licensed engines which at best only advertise it rather than actually have it to the extent that is the easiest to advertise without having dozens of asterisks that would undermine its alleged amazingness, but it's not that big of a deal because they'll figure it out eventually, unless it's """""open""""" source in which case we probably never actually knew but whatever because they can figure it out for us I guess.
But forget all that anyway, the games people apparently care about are on engines that are either entirely internal or are branched off to the point of being entirely self-made, where either way there's not even the facade of it working anywhere other than perhaps Win64/PS4/Xbone, and that may only be after it's been mutated from an engine that was Win32/360-only with some kind of demonic PS3-ish code path that might have only tangentially been relevant to *nix platforms had it not been written entirely with PPC intrinsics for even the tiniest of things because lord knows what it was like to get anything running on any console of that time, much less a console that was deliberately as difficult to work with as possible.
And that's with an engine that is wholly internal and thus we don't have a full understanding of how it works from the outside, and all the real legitimate answers that one could give to these questions are under NDA by order of either the owner of the product or the owner of the middleware, whichever is making it more inconvenient for someone who wants to actually explain why the grass is clipping through the clouds several miles high while no sound is playing.
Also, programming is hard.
Now we have Simon Roth [Twitter], developer of colony simulator Maia who wrote an interesting blog post titled 'How to delay your indie game'.
Why do you think Linux games get delayed?
Simon Roth: Two things. Firstly, I think lack of awareness is a factor. Some developers don't know about Linux, and so don't really plan for it. It's assumed to be a minuscule job and put off again and again until it is only considered approaching beta. That's when it's properly accessed and the time put aside for it breaches past the release date.
Secondly the financial aspect. If a Linux release will give a developer 2-5% more sales, they might put it off. Sometimes indefinitely. In pure business terms an extra round of localisations might be more fruitful for many titles (such as reworking aspects of a game for the Chinese market).
What do developers need to do to ensure a timely Linux release?
Simon Roth: A platform agnostic engine and a game that runs cleanly within the engine. It's really a no-brainer for most devs, since having multiple compilers building the same code is a good way to find some of the insidious low level bugs that make it past Visual Studio or Xcode.
What is so difficult about bringing games to Linux?
Simon Roth: On the porting front, many developers are still sitting on engines that have not progressed much beyond DirectX 9. Modern graphics programming has closed the gaps between the graphics pipelines, the older the pipeline the more time consuming a port will be.
There's also a surprising lack of people with Linux in their skill sets in the game development pipeline. Programmers who will work (well) on Linux are nowhere near as common as those comfortable on Windows and OSX.
It's even worse when it comes to testing, as you need quite technically adept QA to be able to work on many different Linux setups. This specifically has been particular trouble for my own development efforts.
Next up, we have Josh “Cheeseness” Bush [Website, Twitter]. Notable Linux ports include: Day of the Tentacle Remastered. He’s also writing his own game engine named icicle.
Why do you think Linux games get delayed?
Josh “Cheeseness” Bush: Personally, I feel the number one cause of delayed game releases or game ports are hurdles or priority changes that couldn't have been foreseen when previous timeframes were settled on.
I think it's worth considering that there are two types of "delays", deviations from internal timelines, and changes in dates that have been announced to future customers.
The first of these is normal, and is an accepted and acceptable part of software development. All the scheduling and planning we do when making a game isn't a hard and fast set of rules, it's a baseline against which to judge and compare the impact of changes so that every decision that's made along the way can be more informed. This flexibility is important because it gives developers the freedom to make the right decisions based on the insights they've gained during development. Remember that SimCity has its origins as a level editor for a shootemup, Halo was first envisioned as an RTS, and closer to home for us Linux users, Half-Life 2 underwent massive structural shifts later in development - by growing beyond their initial implementations, all of these titles were able to give players better and more enjoyable experiences.
Making games is a lot different from say, building construction, where millennia of industry culture anchored around our static laws of physics and materials that change very little from decade to decade has created a safe and predictable development environment that has very few unknowns.
By comparison, software APIs, hardware capabilities, development models, best practices and consumer expectations change near-constantly - it'd be more like trying to design and construct a building in an environment where at least half the laws of physics and your materials are different between any two given projects. There's a lot more exploring, inventing and iterating involved, and because of this, time schedules and budgets aren't the same kind of tools.
Thinking about the technical hurdles that hit Linux support at this level, it's usually a mix of unfamiliarity with what's involved, existing platform specific code, and needing to respond to other commitments to existing customers and deliverables.
Having Linux support fall behind other platforms is a sad reality that I think Linux users need to be understanding of. If a game is already released on another platform, then I'd have more respect for a developer who gives priority to existing customers over customers they don't yet have - the opposite only suggests that we'll be treated poorly when we are finally supported!
To some developers, staggered platform releases means more opportunities for press coverage and does offer more opportunity to focus on/engage with each platform's audience when it's their turn for release. Conversely, it means a lower initial player base and makes it a little more difficult for awareness of the game to travel via word-of-mouth when part of its audience can't play.
When a game is developed without ongoing testing of all target platforms, it's possible for platform specific code to creep into the codebase. Different compilers and different platforms tend to do things a little differently, and what works in one place happily might be a significant problem elsewhere. It doesn't help that Windows tends to be a little more slap-happy and code that might crash on Linux can still appear to run happily (while causing problems that aren't immediately visible or don't manifest themselves in significant ways).
Sometimes, a lack of familiarity, whether that's first-time Linux supporters finding some unexpected work when they realise that we generally have platform sensitive filesystems, or an experienced porter not being familiar with the testing and QA timeframes of a developer they're working with. Since so much of game development is carving a piece of software out of unknowns, there's a huge amount of room for unfamiliarity to impact on Linux development. Realistically, it's often impossible to understand how long a problem will take to fix until after it's been resolved.
Pressure and attention from expectant future customers can also slow down some developers, and it can often come down to a situation where for every 30 second "How's that Linux version coming along?" question that needs answering, there's another 20 minutes lost regaining focus and getting back into development.
Having to regularly give people answers that aren't "The Linux version is ready!" can also make it hard for a developer to feel positive about their work. Since developers who feel happy about their work are more productive than developers who don't, this can also slow things down a little.
The second type of "delay" is one that I think is the one that I would love to see more developers giving attention toward, and although they're usually the result of the first type, the way that they're handled is entirely different.
Handling these situations appropriately is an exercise in expectation management, and I think the slip-up that many developers make is in not helping their future Linux customers avoid making assumptions.
Some developers (particularly porters!) don't have the ability to speak openly about their projects, and sometimes that can lead to people making guesses or assumptions about the state of things - a situation that sadly often results in disappointment.
For many independent developers without dedicated PR people, it can often feel like the best option is to knuckle under and keep working instead of breaking momentum to stop and explain what's going on and risking making things take longer.
You might notice that few of these items seem specifically relevant to supporting Linux, and you're right. Generally speaking, Linux games are subject to the same kinds of pressures and hurdles and timeframe adjustments that projects on any other platform are.
The difference is that we just happen to typically be on the tail end, and when people on other platforms are happily playing their games, it becomes easy for us to have negative feelings when visible "delays" occur.
What do developers need to do to ensure a timely Linux release?
Josh “Cheeseness” Bush: Assuming that timely means "relative to other platforms", then the most effective way that I can think of is to develop games on Linux. In some ways, you can consider compatibility with your development/primary testing environment to be gained "for free".
As a developer, if you write a piece of code that doesn't compile or doesn't do what you're expecting on your development machine, you address it straight away (whether that's through debugging and fixing or trying a different approach).
You're unaware of any code that would crash/misbehave on platforms you're not writing on, and so don't have any reason to reconsider them, resulting in "platform specific code". The more of these that build up and slip through, the more work there is to do, and the longer they go unnoticed, the more work it's likely to take to dig them out without breaking behaviour on other platforms.
This leads to the second most effective way to keep Linux support up to speed with other platforms: treat Linux as a first class platform and include Linux builds in automated and manual testing throughout development. Platform specific code gets identified quickly, and even if it's not addressed right away, where it is and what implications it has are known and can be taken into consideration before making other functionality dependent on that.
Beyond that, if a developer can hold old off on releasing on any platforms until Linux support is ready, that prevents any Linux specific delay, but does mean delaying revenue - not something that all developers can afford to do.
For a lot of developers though, those options are difficult to embrace, either through ties to existing development environments, limited testing resources, unfamiliarity/uncertainty toward working with Linux, or contractual obligations giving certain platforms time constraints that other platforms aren't subject to.
For those, I feel the best option is to avoid talking about dates or timeframes until work is completed. If you haven't accidentally communicated dates that can be construed as deadlines, then there's nothing that can be seen as a "delay".
If a developer is finding that they're struggling to overcome a Linux specific issue, they may find value in reaching out either to any Linux users in their community, or someone like myself who's willing to lend a hand to help other developers have positive experiences.
Making use of enthusiasm and experience within the community can often help speed things along, but this can often require a level of open communication that some developers don't feel comfortable with or are unable to embrace.
What is so difficult about bringing games to Linux?
Josh “Cheeseness” Bush: I think each project has its own set of ups and downs, and even for those who do a lot of porting, there are going to be pitfalls and hurdles that slow things down.
Even when using engines with cross-platform support like Unity, or like FNA that in an ideal situation are a drop-in replacement for non-Linux supporting technologies, there's still often an issue here or there to address.
I develop all of my games on Linux, so this is thankfully something I don't have to worry about. The Linux ports that I've been involved with personally have been about as straightforward and friendly as ports possibly could be.
Over the years though, I've helped a lot of other developers overcome their own problems, and there are a few things that stand out to me.
When approaching something new, it's often easy to feel that problems are more difficult than they would be if they were in a more familiar environment. Less experienced developers pursuing Linux support have an additional psychological hurdle to cross (that's not to say that problems are trivial, just that it's harder to objectively assess them without experience and context).
Similarly, unfamiliar tools can be significant hurdles for people. For those not used to working with the debuggers available on Linux, embracing them can be an insurmountable challenge. Sometimes different tools require different workflows, and that too, is more disruption than some developers are willing to put up with. For some, new tools or alternative interfaces might help make working on Linux a little more accessible.
Third party Linux porters often have to deal with decisions made by upstream developers that were not made in the best interests of Linux builds. Many games are developed before Linux support is on the roadmap - for example, when working on Day of the Tentacle Remastered in 2016, I had to deal with the consequences of the original game having case consistency in include statements was important. There was no possible way for the SCUMM engine developers in the 80s to foresee that that would be a problem, but it increased the work I had to do regardless.
For developers doing in-house Linux support, this can be a problem too. It's not uncommon (though perhaps less common now than a few years ago) for a developer to make dependency, middleware, engine or other tech choices with the assumption that they will behave on Linux, only to later find that that those choices mean additional work is now involved.
I would like to thank each person for taking time out of their always busy schedule of being awesome. It's great to get some insight into how developers think on issues such as this, even if the questions are something that repeatedly gets asked, getting up to date thoughts from such developers is always a fun read. It's good to keep checking in too, so we can see how Linux has changed each time and if any new issues need addressing.
To sum it up: it seems like there's a rather large variety of issues developers have to deal with when bringing games to Linux including (but certainly not limited to):
- Linux market-share
- Case Sensitivity
- Games branching off from the original engine and becoming a whole different beast
- Design differences between DirectX and OpenGL (hopefully lesser so with Vulkan)
- Programming is hard.
- Summaries are hard.
We have a tough hill to climb as a gaming platform, so hopefully this gives you a small insight as to what developers face and think.
I think market-share is always going to be an issue, it's an absolute mountain we have to climb if we are to push our numbers up. Still, being small in terms of percentage isn't as bad as some think, since that percentage is of a large number it still means there's quite a lot of us. Just not a lot when in comparison to Windows.
When looking at NetMarketShare, in Q2 2014 we had a total share of ~1.58% and now in Q2 of 2017 we have ~2.14% with it being above 2% for 10 months in a row now. Doesn't seem like much, but that's likely quite a large of sum people. It's also pretty healthy to see us remain above that 2% spot for so many months in a row. Who knows, maybe in another year we can hit 3%? I can dream!
Hopefully you enjoyed a little longer read than usual from us!
Other well known developers were asked, but it seems others are too busy porting awesome games. Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Quoting: Doc AngeloI wonder how many Linux gamers won't buy games with DRM?/
I expect percentage to be higher than among Windows users. People who reject DRM can use Linux itself for similar reasons.
Quoting: Doc AngeloNitpicking: Even those who would never buy a game with DRM can still buy games on Steam.
I don't, and many of those who avoid DRM also don't. Since buying on Steam proliferates DRM based approach.
Last edited by Shmerl on 23 April 2017 at 7:01 pm UTC
0 Likes
Quoting: natewardawgQuoting: Doc AngeloI wonder how many Linux gamers won't buy games with DRM?
This would be a nice bit to have on the GoL survey :)
I agree. Attitude to DRM is a good point to include in the survey.
0 Likes
Cheeseness Apr 29, 2017
Ah! I'd been so busy with Amnesia Fortnight stuff that I didn't notice that got published.
There are some great responses provided by the interviewees. I think they all show slightly different perspectives on similar hurdles, which is super valuable to have!
I'm less comfortable with platform specific delays when affected users are already customers (or in the case of crowdfunded games, supporters). I think you make a valid point.
That said, sometimes it comes down to a developer making a decision to give a particular platform priority over others in exchange for upfront payment that lets them continue working on the game. As much as I don't like those kinds of arrangements, I'd rather see a Linux version delayed than a game not get finished.
There are some great responses provided by the interviewees. I think they all show slightly different perspectives on similar hurdles, which is super valuable to have!
Quoting: wintermuteQuoteHaving Linux support fall behind other platforms is a sad reality that I think Linux users need to be understanding of. If a game is already released on another platform, then I'd have more respect for a developer who gives priority to existing customers over customers they don't yet have - the opposite only suggests that we'll be treated poorly when we are finally supported!
Except in the case of Kickstarters we're all existing customers, so we're already being treated poorly.
I'm less comfortable with platform specific delays when affected users are already customers (or in the case of crowdfunded games, supporters). I think you make a valid point.
That said, sometimes it comes down to a developer making a decision to give a particular platform priority over others in exchange for upfront payment that lets them continue working on the game. As much as I don't like those kinds of arrangements, I'd rather see a Linux version delayed than a game not get finished.
1 Likes, Who?
Quoting: LeopardQuoting: SeegrasI actually know casual gamers on Linux that refuse to use steam. They only buy software from humblebundle, gog, itch and so on.
If you look at that way , there are many (posssibly much more than Linux) Windows users who are pirating games or buying drm-free games. That is not a valid reasoning.
Also , are you sure that your friends are 'buying' drm-free games ; right?
Of course, you're right in respect of the percentages.
But also: Ever seen illegal copies of Linux games floating around? Yes there are, but they're far and few between, so yes, they are BUYING them.
0 Likes
See more from me