Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Steam for Linux is out today and I was surprised to see many games already being sold, which made me wonder what are going to be the difficulties for all those games to be ported to Linux. I broke this though into 3 questions:

  1. Is it a matter of basically make the game run in OpenGL?
  2. Are there any engines that build to Linux?
  3. Did Valve have any hand on the development of some framework/toolset/OpenGL to make porting easier?
share|improve this question

closed as not a real question by Trevor Powell, bummzack, Josh Petrie, Maik Semder, Byte56 Feb 16 '13 at 23:53

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

    
SDL will build to Linux, Windows and MacOS. –  Almo Feb 14 '13 at 20:08
2  
Pick a question. You asked three different ones. One of them (which engines build on Linux) is very off-topic for GDSE. –  Sean Middleditch Feb 14 '13 at 22:07
1  
About Valve, note that they hired Sam Lantinga, the original author of libSDL. –  Sam Hocevar Feb 14 '13 at 23:01
    
Is there a practical question here, or is this just you wondering things? –  Trevor Powell Feb 15 '13 at 2:01
    
Voted to close; there are multiple questions in this post (you should ask one question per post) and none of them seem to directly related to any practical game development problem you are having. –  Josh Petrie Feb 15 '13 at 16:13

4 Answers 4

up vote 5 down vote accepted

Generally speaking, it depends on how the game is programmed.

In the case of Source-engine games, they used a multi-tier software architecture, and moved everything platform-specific into /tier0 in their code. When they need to port something, at least by the original engine design, they just swap out /tier0 files for platform-specific ones, and reimplement the Source engine executable for, say, Linux, re-binding things like audio (ALSA/etc. vs. DirectSound), graphics (OpenGL vs. Direct3D), video playback (who knows), window generation (X/GLUT/whatever vs. Win32/64), and I/O (XInput/whatever vs. DirectInput) to their system-specific counterparts. It was designed like that from the very beginning, though a lot of system-specific stuff has crept into higher tiers of the engine due to bad maintenance over the years. Most of what they did to "port" the Source titles to Linux was just refactoring out the Windows-specific stuff, and reimplementing the core executable.

In terms of "Are there engines that build to Linux?": Of course. With the changes made for this big release, the Source engine now runs on Linux. There are literally hundreds of others, of varying quality or availability.

As for your third question, porting happens by the developers. If you don't design your software with platform-nonspecificity in mind, then it just makes it harder. Nothing is truly impossible to port, disregarding hardware capabilities and computing speed. There's no such comprehensive "tool" for porting games to other platforms, though, since they all work differently under the hood.

share|improve this answer

I'll share our experience of porting a certain game to Linux (and Mac).

  • System-specific APIs - window creation, rendering, audio, networking, input, non-trivial filesystem access etc. The other answers go into details. I'll just say that portable libraries (SFML, SDL, but also things like boost) help a lot.
  • Driver bugs - happen on Linux a bit more often than Windows. Or maybe that's a thing of the past, I'm not up to date.
  • Storing user data - generally in $HOME on Linux. Perhaps not an issue if you're using Steam?
  • Paths to resources - UTF characters, slashes/backslashes, spaces and non-alphanumeric characters can all cause problems. You'll need to check all your paths, especially those generated programmatically.
  • System fonts - your game might be using some default resources provided by the operating system; in particular, fonts could be pitfall.
  • Quirks of "portable" code interoperations - I think it's pretty obvious that even though every single function you use is portable, it doesn't mean that your whole game will be using those functions in a portable way. For instance, on Mac our SFML code crashed because we tried to preload a font before creating the game window.
  • Compiler differences - you might stumble into some if you were using Visual Studio for Windows. g++ and Clang can be used on both platforms, and behave similarly. Applies in a limited fashion to Java and C# code as well.
  • Build-system - actually building a proper Linux binary, depending on appropriate shared libraries and providing your own where needed, can actually be a bit tiresome. Again, Steam might help you a lot here.

One more thing - if you were to develop future games which you would intend to port, I would suggest developing them on two platforms at once. Setting up a continuous integration server which run compilation + smoke tests on Linux builds every time our source code was updated (most of us worked on Windows) saved us a ton of time while working on our game.

share|improve this answer
    
If you tell the compiler to compile statically, which compiles the libraries into your binary, you don't have to worry about shared system libraries. –  mmstick Nov 30 at 22:13

It's not just graphics (though that might be the hardest part). Consider also audio, input devices and other OS APIs (no Windows registry, etc.)

Additionally, if you are using any third-party library, the library must also be available for Linux.

Different Linux distributions may use different versions of the same library (or provide different libraries for the same purpose). Note that, officially, Steam only runs on Ubuntu so this issue is avoided.

There are multiple engines that can run on Linux. Among the open-source ones are Irrlicht and Ogre. Other compatible engines include Unity 3D 4.0 and (now) the Source engine.

Apparently, Valve used a layer to translate Direct3D calls to OpenGL. However, it required more effort than that. I can't find any information saying what they're using for Audio, Input and I/O.

share|improve this answer
    
Steam runs fine on Arch and Debian, they're just recommending Ubuntu. –  jco Feb 21 '13 at 12:51

To answer your 2nd sub-question: A great engine that not only builds on Linux, Windows, OS X and other platforms, but also abstracts away from all the OS-specific build tasks is Unity 3D.

It gives you SDK which allows you to build your project for any of those platforms.

share|improve this answer
    
Does it? My Unity 3.5.5 doesn't build to Linux. –  Roberto Feb 15 '13 at 13:13
    
It's available since Unity 4.0. –  Liosan Feb 15 '13 at 13:27
    
Yep, sorry, forgot to mention that. Here's a Unity 4 game that's being created for Win, Lin and OS X: en.wikipedia.org/wiki/Wasteland_2 –  Shivan Dragon Feb 15 '13 at 13:36
    
Nice! I wonder if they would do it if it wasn't for Valve. –  Roberto Feb 15 '13 at 16:08

Not the answer you're looking for? Browse other questions tagged or ask your own question.