I posed a question on Twitter recently where I asked developers to jump in with thoughts on essential things to know about when bringing a game to Linux. Let’s look over some answers!
In this article I will go over a few useful answers, giving full credit to the person who sent it in with a link to the tweet they sent to us. I will then give my own thoughts on each point, with any relevant links to help. There's likely hundreds of things we could point up, but these are what I consider to be some of the more common and important issues to keep in mind.
Some of the answers made me laugh, let’s start off with a good old joke about Arch Linux (source):
I enjoy a good poke about distributions here and there, but it’s actually very true. Of all the distributions there are, Arch does end up being the most problematic. That's not saying Arch is bad, but being on the edge (it gets newer software faster than most other distributions) obviously increases the amount of issues that are likely to come up, since it's had less time in the oven to work out issues.
Test on Ubuntu and if you can, SteamOS too. If it doesn't work on other distributions, they likely have workarounds as they are likely doing something different. Do not feel the need to test every distribution around, it will be impossible and it's just not needed, don't overthink it. Don't be afraid to limit support to the main bigger distributions either. Some people may not like the idea, but it's too much work for little gain most of the time. Support the big distributions, forget the rest (at least until you're much more familiar with Linux).
One from David Gow (source):
It doesn't necessarily need to be SDL2, there's also SFML and likely others. The point is, projects like that can make your life a lot easier. You might be wanting to keep everything small, but these projects are bigger for a reason, as they cover tons of edge cases and nuisances you likely haven't even thought of.
There's a reason why Valve, Feral Interactive, Humble Indie Bundle and many others use SDL2 for the Linux ports. Heck, even the Unity game engine moved over to use SDL2 in Unity 5.6.
This next one comes from none other than Timothee Bessett, formerly of id Software (source):
I think this is an important point for any developer to remember. Linux users want your game to do well, we will often help you test for free, because we want to help. Any time I’ve seen a developer call for Linux testers, they end up getting overwhelmed with the amount of people willing to offer their free time to help out. Opening up a private beta to a few select people is always an option too, there's many ways to get users involved early.
However, this is not a replacement for your own testing! Linux is free to download and use forever, it can be installed by itself or along side Windows & Mac. You can install it inside a virtual machine too if you want to just give it a look over.
This little tidbit comes from Holarse Linux-Gaming, our German friends (source):
This in particular is something I’m keen for developers to know about. Please, for the love of my sanity, don’t put a plain folder of “Game Name” inside my home directory. If you want to know where to store config files and saved games, you can find more info here.
As an example, Unity games tend to be in /home/user/.config/unity3d. Notice the dot before “config”, it’s a hidden directory so it doesn’t pollute a user's home directory and fill it to the brim with random folders.
Another one from Holarse Linux-Gaming (source):
You likely know what this means, but in case you don't: "This" is not the same as "THIS" when it comes to filenames on Linux. A crash in a game that's absolutely bugging you? Check you're looking for the right filename. This single issue has tripped up a lot of developers I've personally spoken to.
Let’s break things up with another amusing one, this time from a Feral Interactive developer (source):
I would be lying if I said this didn’t make me laugh quite a lot. You think some bug reports you got from Windows were weird enough? Prepare yourself.
The same Feral Interactive developer also put forward probably one of the most important points possible (source):
The amount of times we’ve seen developers announce a Linux port, be it on Steam’s old Greenlight platform, Kickstarter or wherever else, only to announce much later they can’t do it due to something they use being Windows-only is quite staggering. Check early and often that the tools, middleware and whatever else will be able to work somehow on Linux. Don't get stuck in the professionally embarrassing position where you have to u-turn on platform support.
Asking for help is not embarrassing and should not be seen as any kind of weakness, if you put out a call for help finding replacements or getting something to work on Linux, you might be surprised to find people able to help out quite often. I've seen hundreds of developers chatting away on Twitter, Reddit and other sites giving out help and advice about Linux issues.
Another one from a Feral developer (source):
The amount of times I've seen developers put up builds where they talk about knowing nothing about Linux: how do you expect to fix bugs in it, if you don't know the first thing about the platform? A little early research and testing will go a long way. The terminal might seem a little scary at first, but from someone who doesn't consider himself even remotely smart: just do it! Learn it and you might find a new friend. Still scared? This site might help you with the basics of the Linux command line.
If you plan to release your game outside of Steam and you want to use a handy installer, take a look at MojoSetup. GOG, the well known game store actually use this for their Linux releases.
An important point I would like to also raise: don't expect Linux sales to make you rich. It's a smaller platform. Bringing a game to Linux isn't just about getting sales from the additional platform, you should also keep in mind all of us likely know people on Windows & Mac we will end up recommending the game to, especially if it has any form of multiplayer. The extra advertising through various Linux websites and the extra word of mouth can be useful.
If you're wondering whether you need to make a 32bit build of your game, in my honest opinion you don't need to bother. 64bit only is fine especially since our own statistics tell us out of 1921 people who answered about their distribution, only 1 person is on a 32bit distribution.
Also, please don't take loud and idiotic users to heart. All communities will have trolls and haters, please do ignore any you find.
If you're trying to port to Linux and you're stuck, don't fret! Take a breath, come have a chat. We have a Forum, our Email inbox is always open, we have an IRC channel, Discord and more.
Finally, if you are considering bringing your game to Linux — thank you, can't wait to try it!
Please do share any other general tips you have in the comments.
In this article I will go over a few useful answers, giving full credit to the person who sent it in with a link to the tweet they sent to us. I will then give my own thoughts on each point, with any relevant links to help. There's likely hundreds of things we could point up, but these are what I consider to be some of the more common and important issues to keep in mind.
Some of the answers made me laugh, let’s start off with a good old joke about Arch Linux (source):
QuoteIf you are getting completely impossible and weird bugs that is almost impossible to reproduce, check if they are running Arch Linux…
I enjoy a good poke about distributions here and there, but it’s actually very true. Of all the distributions there are, Arch does end up being the most problematic. That's not saying Arch is bad, but being on the edge (it gets newer software faster than most other distributions) obviously increases the amount of issues that are likely to come up, since it's had less time in the oven to work out issues.
Test on Ubuntu and if you can, SteamOS too. If it doesn't work on other distributions, they likely have workarounds as they are likely doing something different. Do not feel the need to test every distribution around, it will be impossible and it's just not needed, don't overthink it. Don't be afraid to limit support to the main bigger distributions either. Some people may not like the idea, but it's too much work for little gain most of the time. Support the big distributions, forget the rest (at least until you're much more familiar with Linux).
One from David Gow (source):
QuoteUse SDL2. Or use something which itself uses SDL. Under no circumstances write X11 code directly.
It doesn't necessarily need to be SDL2, there's also SFML and likely others. The point is, projects like that can make your life a lot easier. You might be wanting to keep everything small, but these projects are bigger for a reason, as they cover tons of edge cases and nuisances you likely haven't even thought of.
There's a reason why Valve, Feral Interactive, Humble Indie Bundle and many others use SDL2 for the Linux ports. Heck, even the Unity game engine moved over to use SDL2 in Unity 5.6.
This next one comes from none other than Timothee Bessett, formerly of id Software (source):
QuotePlayers want you to succeed with your Linux release. Get them involved, for instance have them test stuff up for you.
I think this is an important point for any developer to remember. Linux users want your game to do well, we will often help you test for free, because we want to help. Any time I’ve seen a developer call for Linux testers, they end up getting overwhelmed with the amount of people willing to offer their free time to help out. Opening up a private beta to a few select people is always an option too, there's many ways to get users involved early.
However, this is not a replacement for your own testing! Linux is free to download and use forever, it can be installed by itself or along side Windows & Mac. You can install it inside a virtual machine too if you want to just give it a look over.
This little tidbit comes from Holarse Linux-Gaming, our German friends (source):
QuoteFor your files and savegames there is XDG (like %approot% on windows
This in particular is something I’m keen for developers to know about. Please, for the love of my sanity, don’t put a plain folder of “Game Name” inside my home directory. If you want to know where to store config files and saved games, you can find more info here.
As an example, Unity games tend to be in /home/user/.config/unity3d. Notice the dot before “config”, it’s a hidden directory so it doesn’t pollute a user's home directory and fill it to the brim with random folders.
Another one from Holarse Linux-Gaming (source):
QuoteYes linux filesystems ARE case sensitive
You likely know what this means, but in case you don't: "This" is not the same as "THIS" when it comes to filenames on Linux. A crash in a game that's absolutely bugging you? Check you're looking for the right filename. This single issue has tripped up a lot of developers I've personally spoken to.
Let’s break things up with another amusing one, this time from a Feral Interactive developer (source):
QuoteSomeone WILL play your game on their work render farm, and report the bugs [..] I'd be lying if I said this had only happened once. 128 cores!? 1TB RAM!?
I would be lying if I said this didn’t make me laugh quite a lot. You think some bug reports you got from Windows were weird enough? Prepare yourself.
The same Feral Interactive developer also put forward probably one of the most important points possible (source):
QuoteUse cross compatible tools whenever and where ever, anything can turn into a crutch when you try and port
The amount of times we’ve seen developers announce a Linux port, be it on Steam’s old Greenlight platform, Kickstarter or wherever else, only to announce much later they can’t do it due to something they use being Windows-only is quite staggering. Check early and often that the tools, middleware and whatever else will be able to work somehow on Linux. Don't get stuck in the professionally embarrassing position where you have to u-turn on platform support.
Asking for help is not embarrassing and should not be seen as any kind of weakness, if you put out a call for help finding replacements or getting something to work on Linux, you might be surprised to find people able to help out quite often. I've seen hundreds of developers chatting away on Twitter, Reddit and other sites giving out help and advice about Linux issues.
Another one from a Feral developer (source):
Quoteembrace the shell, the sooner the better. The last thing you want 2 hours before release is to be fumbling around learning bash
The amount of times I've seen developers put up builds where they talk about knowing nothing about Linux: how do you expect to fix bugs in it, if you don't know the first thing about the platform? A little early research and testing will go a long way. The terminal might seem a little scary at first, but from someone who doesn't consider himself even remotely smart: just do it! Learn it and you might find a new friend. Still scared? This site might help you with the basics of the Linux command line.
If you plan to release your game outside of Steam and you want to use a handy installer, take a look at MojoSetup. GOG, the well known game store actually use this for their Linux releases.
An important point I would like to also raise: don't expect Linux sales to make you rich. It's a smaller platform. Bringing a game to Linux isn't just about getting sales from the additional platform, you should also keep in mind all of us likely know people on Windows & Mac we will end up recommending the game to, especially if it has any form of multiplayer. The extra advertising through various Linux websites and the extra word of mouth can be useful.
If you're wondering whether you need to make a 32bit build of your game, in my honest opinion you don't need to bother. 64bit only is fine especially since our own statistics tell us out of 1921 people who answered about their distribution, only 1 person is on a 32bit distribution.
Also, please don't take loud and idiotic users to heart. All communities will have trolls and haters, please do ignore any you find.
If you're trying to port to Linux and you're stuck, don't fret! Take a breath, come have a chat. We have a Forum, our Email inbox is always open, we have an IRC channel, Discord and more.
Finally, if you are considering bringing your game to Linux — thank you, can't wait to try it!
Please do share any other general tips you have in the comments.
Some you may have missed, popular articles from the last month:
Quoting: rkfgSTASIS is suffering from this right now. The engine needs newer libstdc++.so.6 than provided in SteamOS so it doesn't start there. So another advice: check your dependencies on older distros if possible and either ship the libs with the game or link them statically if you can.
libstdc++ is a mess. Even if you statically link it, you might still hit a snag. For instance Mesa is using system libstdc++ in libgl1-mesa-dri, and you can get a conflicting situation.
1 Likes, Who?
Quoting: rkfgQuoting: EhvisI remember one game where the developer had a Unity3D game running within a day, but had dependency problems when starting from the Steam runtime.STASIS is suffering from this right now. The engine needs newer libstdc++.so.6 than provided in SteamOS so it doesn't start there. So another advice: check your dependencies on older distros if possible and either ship the libs with the game or link them statically if you can.
These days it might also be worth looking into those Snap or Flatpak thingies. Extra fiddling maybe, but near as I understand it could buy you quite a bit of distribution-agnostic-ness.
1 Likes, Who?
Quoting: Purple Library GuyThese days it might also be worth looking into those Snap or Flatpak thingies. Extra fiddling maybe, but near as I understand it could buy you quite a bit of distribution-agnostic-ness.Snap isn't that good yet. Maybe on Ubuntu it just works but on Debian I only got the CLI apps working. As I understood it, the snap developers have to hardcode NVIDIA driver paths in the framework and I use the binary non-repo driver. So OpenGL doesn't work and at least Krita couldn't run.
Quoting: ShmerlWell, yes, if you load any system libs that dynamically depend on the same library you linked statically. I'd say libstdc++ poorly versioned and the messages it shows are kinda cryptic for non-savvy people. At least it's backward compatible so there should be no downsides supplying your own version.Quoting: rkfgSTASIS is suffering from this right now. The engine needs newer libstdc++.so.6 than provided in SteamOS so it doesn't start there. So another advice: check your dependencies on older distros if possible and either ship the libs with the game or link them statically if you can.
libstdc++ is a mess. Even if you statically link it, you might still hit a snag. For instance Mesa is using system libstdc++ in libgl1-mesa-dri, and you can get a conflicting situation.
0 Likes
Quoting: rkfgAt least it's backward compatible so there should be no downsides supplying your own version.
It's actually ABI forward compatible, not backward. See https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
QuoteVersioning gives subsequent releases of library binaries the ability to add new symbols and add functionality, all the while retaining compatibility with the previous releases in the series. Thus, program binaries linked with the initial release of a library binary will still run correctly if the library binary is replaced by carefully-managed subsequent library binaries. This is called forward compatibility.
The reverse (backwards compatibility) is not true. It is not possible to take program binaries linked with the latest version of a library binary in a release series (with additional symbols added), substitute in the initial release of the library binary, and remain link compatible.
I.e. you can run code built against older libstdc++, dynamically linked with newer one, but you aren't guaranteed anything if you use code built against newer libstdc++, dynamically linked with older version.
And the later case happens, when for example some game bundles older version of libstdc++ and preloads the bundled lib, and then loads something like radeonsi_dri.so that expects newer libstdc++. Things go haywire.
Last edited by Shmerl on 4 July 2017 at 5:54 pm UTC
2 Likes, Who?
QuotePlease, for the love of my sanity, don’t put a plain folder of “Game Name” inside my home directory.
Please, FOR THE LOVE OF GOD, listen to the man! My home folder is cluttered enough without Runescape, Project Zomboid, Eschalon, et cetera contributing to the problem.
QuoteDon't be afraid to limit support to the main bigger distributions either. Some people may not like the idea, but it's too much work for little gain most of the time.
As someone who uses Fedora, I can't echo this hard enough. Support, at minimum, SteamOS and the latest LTS of Ubuntu and everything should be mostly fine.
Quoting: Feral InteractiveSomeone WILL play your game on their work render farm, and report the bugs [..] I'd be lying if I said this had only happened once. 128 cores!? 1TB RAM!?
<insert "I LOVE IT" horse mask gif here>
1 Likes, Who?
Quoting: camocelticPlease, FOR THE LOVE OF GOD, listen to the man! My home folder is cluttered enough without Runescape, Project Zomboid, Eschalon, et cetera contributing to the problem.
While it's annoying, I found one relatively simple workaround. Run such games with:
HOME=$HOME/.local/share
Then all that clutter will move to more appropriate location.
Last edited by Shmerl on 4 July 2017 at 5:59 pm UTC
8 Likes, Who?
Quoting: ShmerlWhile it's annoying, I found one relatively simple workaround. Run such games with:
HOME=$HOME/.local/share
That's a beautiful workaround that I'll give a try.
0 Likes
Quoting: ShmerlIt's actually ABI forward compatible, not backward. See https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.htmlI always mistake forward/backward compatibility, it depends on the point of view, probably that's why. Yes, this seems impossible to solve once and for all. Either your game doesn't work because the system library is too old or the rest of the system (that's required for the game to run) doesn't work because you shipped a library too old now. The only solution is to constantly update the libs and ship them ASAP with the game binary or just don't use the modern C++ features and stick to stone ages of GCC 4.
0 Likes
I don't want to mix articles, but it got really funny to read that on reddit now....
QuoteQuoteI remember VP improved the port quickly and it works well now.No it does not work well now. It crashes from time to time which is really frustrating. I'm using Arch.
0 Likes
Quoting: ShmerlWhile it's annoying, I found one relatively simple workaround. Run such games with:Good find! Redefining HOME could be used for many things, it's a cheap "user isolation/virtualization" technology, like chroot but for data. You can add any number of "profiles" in terms of settings/accounts/data to any app, even if it doesn't directly support it.
HOME=$HOME/.local/share
Then all that clutter will move to more appropriate location.
0 Likes
See more from me