Issues Linux game developers face: a post-mortem from the creators of Osmos

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.

@ 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

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.

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.

I think if developers just followed jmillikin's post there could be a big step forward in Linux developement.