

Issues Linux game developers face: a post-mortem from the creators of Osmos - sgentle
http://www.hemispheregames.com/2010/05/18/porting-osmos-to-linux-a-post-mortem-part-23/

======
jmillikin
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.

~~~
theschwa
I would even go so far as to say that Linux users might even be more forgiving
than a mac or a windows user to issues like this.

~~~
fwez
I would even go so far as to say that Linux users might even LOVE the
challenge of tinkering with their non-standard distro to make it work.

------
MealWorms
Thanks for the comments all!

@ 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

~~~
jmillikin

      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.

------
cicada
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.

~~~
bitwize
Working on it.

------
gte910h
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.

~~~
ramidarigaz
Licensing is an issue. Many libraries are GPL licensed, and that's an issue if
your game isn't open source.

~~~
gte910h
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.

------
dkarl
_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.

------
theschwa
This sounds almost exactly like the "Why Desktop Linux (Still) Sucks. And What
We Can Do To Fix It." video <http://blip.tv/file/3538476/>

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

~~~
wendroid
Linux is a kernel. It has over 400 syscalls.

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>

