An Interview With A Linux Game Porter

Written by Michael Larabel in Linux Gaming on 3 July 2009. Page 2 of 4. 20 Comments

When dealing with game studios and publishers, what has been the biggest challenge on convincing them to have one of their titles brought over to Linux?

Convincing them that there really IS a market share for them- and it's not hard to support a decent number of distributions out of the box.

It doesn't help that we've had consistent issues with sales numbers being low for the game sales and things like IDC reports showing us "breaking the 1 percent mark" in the marketplace. Or, for that matter, having a lack of information in the general game developer public on the skills and tricks needed to make binaries that don't need recompilation every time a new version of some distribution comes out. More often than not, I've tried to talk to studios or publishers, only to have them tell me "there's no money in Linux" or "it's too difficult to support Linux- there's too many differing versions", especially when I went to the Game Developer's Conference a while back. Things are changing, but it's slow, sometimes disheartening work. Many times, rather than just a percentage of royalties like Paradox and Elecorn wanted, they want the same sorts of percentages plus anywhere from $20k and up- I just recently had a lead kind of go down to little more than a "maybe" on the list we've been building as a result of that problem. To many of the publishers and studios, we're a big money sink and they want the money up-front and aren't usually interested in someone contracting for the privilege- even if it's for something like 10% of the Linux proceeds of a title with no cash outlay on their part and no publishing risk either. What makes it additionally fun in that regard is that if they used something like RAD's toolchains, they have to expend ~$5k or so per library for the Linux version, in addition to the money they spent on the Windows version. If they don't see that expense being paid back to them, you're going to have to foot THAT bill as well.

I'm hoping the story with Caster will help quite a bit, even if it's only Indie studios I'm working with for a while yet. There IS a market there and it's underserved. Each win like World of Goo and Caster helps sell the story to other studios and to the mainline publishers. And it's a story that it doesn't have to be the way you see it and there's a seriously underserved market that's more than willing to pay you money for your product. If they see there's a market and it may well pay them the extra expenses, you'll see more stuff happening.

What generally is the biggest technical challenge you encounter in porting these games and engines to Linux?

The Middleware that a studio chooses to use in their game. It can either make it easier or harder to make the game happen.

It's almost never the 3D or input device support that's a problem. Most of D3D is decently handled by OpenGL and SDL's input layer does a well enough job of things that it's rare that you can't at least approximate the original games' look and input interaction on Linux fairly quickly. That's not to say there's not gotchas with the 3D support, but I'm thinking with things like MojoShader and HLSL2GLSL in hand, that you can gain purchase on most of the eye candy from the 3D side of things at this time with only some effort.

It's things like the sound support that can be a problem. Miles costs money that a studio is often unwilling to pay. The same goes for FMOD. IrrKlang's good on x86 platforms because the licensing is reasonable- but unfortunately, I'm having to use SDL and OpenAL for Caster because IrrKlang's not ON anything but x86 Linux and I'm targeting a bit more than x86 machines in the long run for that game. Not that this is a problem, but IrrKlang's nice and doesn't have you doing quite the amount of work that OpenAL makes you do.

It's things like the cut scene playback support, as well. Bink's _nice_, but it costs just like Miles does. So you end up rolling something up with OpenGL texture acceleration, OpenAL/SDL_Mixer, and ffmpeg. It's not as integrated as Bink is with being able to play it within the game. You have to come up with a framework for it and wire that in to the game.

Network multiplayer support can truly be problematic under some circumstances. If the game used OpenPlay, it's no problem. But OpenPlay's got some issues with some game types and is not often used outside of the world of MacOS titles. If the game used RakNet, again, little issues- it's got a Linux version and it's somewhat similar in nature to LGP's Grapple in how it's added in and the licensing is typically per title, not platform. But there's things like DirectPlay lurking about, even though it's been deprecated in the DirectX stack for a while. It's "easy" to use, and "free" so many indie studios have used it in the past. The big gotcha there is that there's really no Linux equivalent (RakNet and Grapple are close, but they're not the same beast...) as much because they've not disclosed the wireline protocol and nobody's gotten to reverse engineering it, really. Grapple's an LGPL'ed rough equivalent to RakNet that's got the potential of being cross-platform if someone were to have the inclination- but I'm unsure of anyone that's using that library in a commercial product yet.

Related Articles