It is a problem and also a lame excuse. Steam has successfully made itself available on variety of distributions.
Even TF2 kept crashing with a cryptic error until I found the solution on some forum post.
thats a very ironic commandline option!
That portion of the development cycle can easily run to 40% of the cost of the project, that's a non-trivial area in which to throw in complexities.
I'm a big fan of linux, but I was a PM at Blizzard, I would be VERY reluctant to increase my problem surface in an unproven market.
If, over the long term, it's costing you 40% to keep the popular versions of Linux working, then you're doing something wrong. Could it hypothetically cost that much? Sure, but only if you're incompetent.
Long answer: Hell yes, especially over the long time. You've ever tried to target the Linux desktop ecosystem, you will know that it is a moving target. I'm not talking about the server/command line ecosystem, that one is relatively easy.
On the higher level, the desktop ecosystem has seen a number of major platform changes over the past years. GTK 2 -> 3, compositing, new X extensions, etc. Each change results in subtly different semantics that can break apps.
On the lower level, the ABI (not API) keeps changing. Many g++ releases change the C++ ABI, and most games are written in C++. Each glibc version adds new symbol versions.
Binaries that worked 5 years ago may not work anymore.
It took a week to have something that we could use. A week!! In a couple of months we had a serious product.
This is what you get when you program with standards in place. Developers love to use the last trick of the week, with new proprietary languages but you should not let them if that means not being portable or easy to upgrade.
Which is a baffling thing to have to wrap your head around when you look at all the people who say that Linux should be treated seriously by game developers--which will make people flock to Linux! so more people can make games for it! because that will really happen!
If you say you want people to build houses in your housing development (houses that have no buyers, but forget it, we're rolling) it really sort of behooves you to not be demanding that they build a house on land that starts at "silty" and doesn't really get better from there.
A game should primarily depend on OpenGL+X+audio, and while these do change, if the program works on one distribution of Linux, it tends to work on the next.
This comment deserves a LOL WUT pear of some kind but it's not quite appropriate here (so if you'd like to think of your favorite one I'd appreciate it). Audio? On Linux? Working from one distribution to another? No way. It's a mess, it's still a mess, and it's been a mess that is doing a wonderful impression of a full-blaze tire fire for going on a decade now, especially with older--yes, closed-source, it's not going away in games--software. Closed-source Linux games from the Loki era, by and large, don't work and when they do it's through fairly herculean efforts...and they do not exactly rely on GTK or KDE version π.
Oh! And JACK sucks and is bad and its developers should feel bad. (Not game-related, more music-production related, but I felt like throwing that in there. I tried to use Ardour this week and it's made me a bit militant.)
And anyway, the point wouldn't be to support all platforms, just the prevailing ones, so I'd say your remarks miss the mark.
It's easy to dismiss this with saying "it's part of the deal" but if it takes too much effort for minimal gain it's not worth it. I'm fine with breaking changes if they improve things but there should be at least a compatibility later for some period of time.
Unfortunately, simply shipping different versions of a library is not enough to provide compatibility. There are two issues at work: 1) as mentioned before, platform ABI changes 2) ELF works with a big flat symbol table, so if you load library foo version 1, but a dependency loads library foo version 2, then things blow up.
I guess I should thank all you naysayers for the compliment.