9 ms·
Afaik Blizzard always had an internal Linux client [1] but never wanted to make it public. One of the big problems with Linux, and this is from other game deve
by spdy 14y ago
Afaik Blizzard always had an internal Linux client [1] but never wanted to make it public.
One of the big problems with Linux, and this is from other game developers too, is the problem of targeting a specific version of the platform. Since everyone is free to create their own distros, they can become somewhat unstandardized. That makes "targeting linux" difficult.
Add on that there are far fewer linux users than windows/mac users, and that you can play wow on linux using Wine... and there isn't a lot of reason to target even a specific distro
[1] http://www.phoronix.com/scan.php?page=news_item&px=OTA0NQ http://www.phoronix.com/scan.php?page=news_item&px=OTA0N...
- donniezazen 14y agoIt is a problem and also a lame excuse. Steam has successfully made itself available on variety of distributions.
- wissler 14y agoYes, if you have the resources and client base of Blizzard, it's a lame excuse. Most of the time if you want it to run on different versions of Linux all you need to do is recompile.
- liljimmytables 14y ago... + test + support 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.
- wissler 14y agocan easily run to 40% of the cost of the project 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.
- FooBarWidget 14y agoShort answer: Yes. 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.
- wissler 14y agoYes, if you're going to target Linux, all of that's part of the deal. 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. The worst issue I've found is that when a new distribution first comes out, it can be glitchy, also I had problems with Intel's Sandy Bridge architecture when it first came out, but the same scope of problem did not occur cross-distribution, given the same kernel.
- eropple 14y agoYes, if you're going to target Linux, all of that's part of the deal. 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.)
- veeti 14y agoThey're not there yet. Steam for Linux only supports Ubuntu officially. Otherwise, you have to resort to installing dependencies for some of the games manually and other tinkering. Serious Sam 3 even asks for root access that it can install the libraries it needs.
- viraptor 14y agoI don't get this. It's a multi-GB game that already needs to be downloaded over internet. Why don't they just bundle the dependencies, or at least make it installable via steam as a separate component? There should be no reason for a game to ever ask you to become root.
- donniezazen 14y agoSteam is working out a system which would automatically install dependencies from system repository. About root, that is just a bug.
- mertd 14y agoSteam yes, but games no. I had to jump through several non trivial hoops to get some games running on my 64bit Arch. Even TF2 kept crashing with a cryptic error until I found the solution on some forum post.
- LukaD 14y agoI also had a really cryptic error that I was able to solve by unplugging my xbox 360 controller wireless adapter. I later figured out that I could have also just started TF2 with the -nojoy option. Things feel really beta (but that's ok given that it is one).
- chii 14y ago> started TF2 with the -nojoy option thats a very ironic commandline option!
- sliverstorm 14y agoBecause a porting a game client is just like porting a game.
- voltagex_ 14y agoNo. Valve released a highly-Ubuntu specific .deb and everyone else hacked the crap out of it to get it working. Including pulling in libc from Ubuntu.
- udp 14y agoThis is what the LSB[1] is for. [1] http://www.linuxfoundation.org/collaborate/workgroups/lsb http://www.linuxfoundation.org/collaborate/workgroups/lsb
- k3n 14y agoThe article actually talks directly to that point for an entire paragraph.
- tsotha 14y agoThe way to deal with that is pick a few standard versions. Businesses do that all the time - my workplace is standardized on RHEL 6. Then you release a client and say "We know it runs on this flavor of Linux. You're welcome to try running it on other stuff, but if it doesn't work that's on you."
- littledot5566 14y agoWhy is different distros a problem? I never understood what was missing in *nix that was so game-changing.
- Shish2k 14y ago> you can play wow on linux using Wine Speaking of which, why is a native binary better than wine? I know wine is typically associated with pain, because the app developers don't support it properly, but then native doesn't work /at all/ without developer support. If developers /are/ going to support linux in some way, why should they support multiple platforms [distros] when they could support one [treating wine as a minor variation on their existing windows support]? (Not trolling, I'm sure there are good reasons that I haven't had enough morning caffeine to think of; plus it might be useful for someone to make a definitive list somewhere)
- anonymous 14y agoThe issue is with them using Direct3D, which will be slower on wine, as well as platform differences that wine can't abstract well. Past that, wine isn't that bad of a target. Limbo's linux port for instance is simply a bundled CrossOver installation.