In reviews like this, there's always one common complaint I see over and over:
It's too hard to support every possible combination of distro / WM / driver / library
My answer is: well then don't. Much like in Windows, 99% of your users will have a fairly sane and normal setup. I guarantee he doesn't lose sleep worrying about whether users can run his games in Windows 95, so why expend even a half-hour's effort getting it to work in somebody's mangled LFS installation?
There's only three WMs to worry about: Metacity, KWin, and Xfwm. They are all quite standards-compliant, and if your game will work in one, it'll work fine in another. "But what if a user's running ratpoison!?" Tell that user they're not using a supported configuration. Problem solved.
Ditto for sound. If your game uses OpenAL or GStreamer and doesn't work on their system, then the problem is their system. You're not obligated to support every half-wit Gentoo user who uninstalls ALSA to optimize his kernel.
If your game needs libfoo-1.1, released last year, and a user only has libfoo-0.83-rc2 installed, don't worry about it. It's OK if your game spits out an error and crashes. Just include what libraries you built against in the README, and try to make sure it'll work on the most recent versions of Ubuntu and Fedora. Anybody who installs some weird library version will have the knowhow to ldd the binary and install missing software themselves.
I'm not surprised by some of the observations. Windows software, being mainly closed source, has forced the platform to address compatibility and exotic configuration problems more thoroughly -- even sometimes to its detriment. First thought is that if game studios are serious about stepping up OSS support, a lot of effort could be saved by building a compatibility layer -- DirectX on steroids -- that can be targeted by the devs and left to the distros to properly support.
Actually, this seems a better idea than I first thought: done properly, it could also work as a standalone platform for consoles/handhelds, as a browser plugin for easy web gaming and as an open source flash replacement.
One thing I don't understand for people who release closed source products (including games) for Linux is: WHY DON'T THEY STATICALLY COMPILE THEM?
I mean seriously? You're worried about a little disk space? Tons of issues with distribution churn just vanish if you statically compile your product into one giant executable for most of your libraries.
I'm not sure this is possible (I've not done much GPL avoidance, most of my career is solving technical, not legal problems), but wouldn't you be able to accomplish the same idea by linking all of the libraries into one giant library and then dynamically link to that?
I mean, that is pretty much a great first step to that psudo compatibility layer that was talked about here.
games that need any kind of UI must link against heavy-weight UI libraries (GTK, QT, etc) which typically impose some kind of application framework
Library makers need to be aware of this danger and prevent their libraries from unnecessarily becoming frameworks. If you want to provide framework-like functionality, separate the core functionality from the framework and make it available separately. You don't want to impose your build tools, application structure, and a bunch of application infrastructure on some poor guy who just wants to pop up a dialog.
Even libraries that are advertised, documented, and distributed as simple libraries tend to acquire framework-like restrictions if the authors aren't careful. For instance, a few years ago I wanted to add some simple visualization to a program I wrote, so I linked in SDL and added a thread to plot the state of the program periodically. (It was the only graphical element of the program; the program's input and output were files.) My sample code worked in standalone tests, but it didn't work when I ran it in my program. Logically it had to be a threading problem, but I was only making SDL calls from a single thread in the application, so I was left scratching my head until I talked to a developer on IRC and discovered that I had to make all SDL calls from the main thread. I was flabbergasted. (It was clear in the documentation that you couldn't make calls from "other" threads, but I didn't realize "other" meant "other than the main thread.") Anyway, I was kind of stunned that this library wanted me to completely restructure my application before I could make a few simple function calls. I ended up sending state information to standard out and piping it to a separate process that used SDL to do the visualization. By that point I was pissed that I had chosen SDL, but I didn't want to throw away all the code I had written.
I could have changed the application to reserve the main thread for SDL, but the program was usually run without visualization, and besides, what would I do with the next library that forced me to make all my calls from the main thread? Create a main thread pipeline that did nothing but make calls to various libraries? And that's the final straw for self-centered, overly restrictive frameworks: they don't compose with each other. Even if structuring my program around your framework is totally worth all the awesome functionality, it won't be possible if I'm already committed to a different framework.
@ jmillikin : Two main issues I see what your propsal: it isn't a real solution to guaranteeing quality, because (for example) I was seeing different WM-XServer interaction between the 32bit and 64bit distros of the same Ubuntu version (9.04)! So I can't even say "The game experience is tuned for Ubuntu" with any real assurance my code will work. The best I can do is say "We tested our code on Ubuntu and managed to cobble something together that displays no known issues."
Secondly, I'm hard pressed to actually get an objective answer on the question "what are the major distros/versions" without igniting some kind of flame war.
Thirdly, how do we select distros/versions/etc without 1) the userbase crying foul for lack of support for their config; and 2) without subdividing an already small market for games? For example, even the support burden alone when dealing with folks who accidentally buy the game without reading the 'fine print' would be significant and prohibitive.
And our experience is that Linux users are not more forgiving when the app in question has been paid for. Expectations are low when something is free but high when something is not. So we need that work to be justified.
@ gte910h : you can't statically link LGPL'd libs without breaking license.
I was seeing different WM-XServer interaction between the 32bit and 64bit distros of the same Ubuntu version (9.04)
In this case, use the 32-bit behavior and file a Ubuntu and/or GNOME bug against the 64-bit behavior. I'm running a 64-bit system, and there are definitely cases where it's a second-class architecture to some maintainers.
Out of curiosity, what's the behavior difference that you're observing?
Secondly, I'm hard pressed to actually get an objective answer on the question "what are the major distros/versions" without igniting some kind of flame war.
Ubuntu, Fedora, and SUSE are the primary desktop distros. Mandriva is popular in Europe. In my experience, they are almost identical in terms of running proprietary software. Arch is also popular, but due to its source-based nature is mostly for more techy users -- they probably won't mind a bit of work if your software doesn't work out of the box.
There's a decent list on < http://distrowatch.com/ >, sorted by popularity, in right sidebar.
Thirdly, how do we select distros/versions/etc without 1) the userbase crying foul for lack of support for their config; and 2) without subdividing an already small market for games?
Use the most recent (or most and second-most, if you've got free time). The market is small, but there's different levels of small; most Linux gamers are going to be close to the bleeding edge, to take advantage of driver improvements.
If you're in doubt, run a poll -- ask which distro, version, and graphics card vendor your customers use. Publish the results. This will serve the dual purpose of 1) letting you know what to support and 2) giving users an idea of what configurations are best tested.
And our experience is that Linux users are not more forgiving when the app in question has been paid for. Expectations are low when something is free but high when something is not. So we need that work to be justified.
Some users are never forgiving, whether they're in the right or not. However, potential customers will be influenced by how reasonable other user's complaints are. "I use Ubuntu 10.04 and your game crashes on startup" is a legitimate complaint; "I run a four-year old Slackware install, and audio doesn't work because I replaced ALSA with OSSv4" will just be ignored as a crank.
14 comments
[ 3.2 ms ] story [ 28.0 ms ] threadIt's too hard to support every possible combination of distro / WM / driver / library
My answer is: well then don't. Much like in Windows, 99% of your users will have a fairly sane and normal setup. I guarantee he doesn't lose sleep worrying about whether users can run his games in Windows 95, so why expend even a half-hour's effort getting it to work in somebody's mangled LFS installation?
There's only three WMs to worry about: Metacity, KWin, and Xfwm. They are all quite standards-compliant, and if your game will work in one, it'll work fine in another. "But what if a user's running ratpoison!?" Tell that user they're not using a supported configuration. Problem solved.
Ditto for sound. If your game uses OpenAL or GStreamer and doesn't work on their system, then the problem is their system. You're not obligated to support every half-wit Gentoo user who uninstalls ALSA to optimize his kernel.
If your game needs libfoo-1.1, released last year, and a user only has libfoo-0.83-rc2 installed, don't worry about it. It's OK if your game spits out an error and crashes. Just include what libraries you built against in the README, and try to make sure it'll work on the most recent versions of Ubuntu and Fedora. Anybody who installs some weird library version will have the knowhow to ldd the binary and install missing software themselves.
Actually, this seems a better idea than I first thought: done properly, it could also work as a standalone platform for consoles/handhelds, as a browser plugin for easy web gaming and as an open source flash replacement.
I mean seriously? You're worried about a little disk space? Tons of issues with distribution churn just vanish if you statically compile your product into one giant executable for most of your libraries.
I mean, that is pretty much a great first step to that psudo compatibility layer that was talked about here.
I think if developers just followed jmillikin's post there could be a big step forward in Linux developement.
The userland, with which you are probably familiar, is the GNU part of GNU/Linux.
So if you want to blame somebody, blame Stinky Stallman, the baby hater.
http://edward.oconnor.cx/2005/04/rms
Library makers need to be aware of this danger and prevent their libraries from unnecessarily becoming frameworks. If you want to provide framework-like functionality, separate the core functionality from the framework and make it available separately. You don't want to impose your build tools, application structure, and a bunch of application infrastructure on some poor guy who just wants to pop up a dialog.
Even libraries that are advertised, documented, and distributed as simple libraries tend to acquire framework-like restrictions if the authors aren't careful. For instance, a few years ago I wanted to add some simple visualization to a program I wrote, so I linked in SDL and added a thread to plot the state of the program periodically. (It was the only graphical element of the program; the program's input and output were files.) My sample code worked in standalone tests, but it didn't work when I ran it in my program. Logically it had to be a threading problem, but I was only making SDL calls from a single thread in the application, so I was left scratching my head until I talked to a developer on IRC and discovered that I had to make all SDL calls from the main thread. I was flabbergasted. (It was clear in the documentation that you couldn't make calls from "other" threads, but I didn't realize "other" meant "other than the main thread.") Anyway, I was kind of stunned that this library wanted me to completely restructure my application before I could make a few simple function calls. I ended up sending state information to standard out and piping it to a separate process that used SDL to do the visualization. By that point I was pissed that I had chosen SDL, but I didn't want to throw away all the code I had written.
I could have changed the application to reserve the main thread for SDL, but the program was usually run without visualization, and besides, what would I do with the next library that forced me to make all my calls from the main thread? Create a main thread pipeline that did nothing but make calls to various libraries? And that's the final straw for self-centered, overly restrictive frameworks: they don't compose with each other. Even if structuring my program around your framework is totally worth all the awesome functionality, it won't be possible if I'm already committed to a different framework.
@ jmillikin : Two main issues I see what your propsal: it isn't a real solution to guaranteeing quality, because (for example) I was seeing different WM-XServer interaction between the 32bit and 64bit distros of the same Ubuntu version (9.04)! So I can't even say "The game experience is tuned for Ubuntu" with any real assurance my code will work. The best I can do is say "We tested our code on Ubuntu and managed to cobble something together that displays no known issues."
Secondly, I'm hard pressed to actually get an objective answer on the question "what are the major distros/versions" without igniting some kind of flame war.
Thirdly, how do we select distros/versions/etc without 1) the userbase crying foul for lack of support for their config; and 2) without subdividing an already small market for games? For example, even the support burden alone when dealing with folks who accidentally buy the game without reading the 'fine print' would be significant and prohibitive.
And our experience is that Linux users are not more forgiving when the app in question has been paid for. Expectations are low when something is free but high when something is not. So we need that work to be justified.
@ gte910h : you can't statically link LGPL'd libs without breaking license.
Dave, Hemisphere Games
Out of curiosity, what's the behavior difference that you're observing?
Ubuntu, Fedora, and SUSE are the primary desktop distros. Mandriva is popular in Europe. In my experience, they are almost identical in terms of running proprietary software. Arch is also popular, but due to its source-based nature is mostly for more techy users -- they probably won't mind a bit of work if your software doesn't work out of the box.There's a decent list on < http://distrowatch.com/ >, sorted by popularity, in right sidebar.
Use the most recent (or most and second-most, if you've got free time). The market is small, but there's different levels of small; most Linux gamers are going to be close to the bleeding edge, to take advantage of driver improvements.If you're in doubt, run a poll -- ask which distro, version, and graphics card vendor your customers use. Publish the results. This will serve the dual purpose of 1) letting you know what to support and 2) giving users an idea of what configurations are best tested.
Some users are never forgiving, whether they're in the right or not. However, potential customers will be influenced by how reasonable other user's complaints are. "I use Ubuntu 10.04 and your game crashes on startup" is a legitimate complaint; "I run a four-year old Slackware install, and audio doesn't work because I replaced ALSA with OSSv4" will just be ignored as a crank.