Developing Games On and For Linux/SteamOS

An anonymous reader writes "With the release of SteamOS, developing video game engines for Linux is a subject with increasing interest. This article is an initiation guide on the tools used to develop games, and it discusses the pros and cons of Linux as a platform for developing game engines. It goes over OpenGL and drivers, CPU and GPU profiling, compilers, build systems, IDEs, debuggers, platform abstraction layers and other tools."

Comments

Richard Stallman endorses Gamemaker

[Anonymous Coward]

Richard Stallman endorsed Gamemaker.

"There's nothing that Gamemaker cannot do. Gamemaker can simply do anything. Anything made in Gamemaker is fantastic. I love Gamemaker. I can't get enough of Gamemaker. Return to Gamemakerdom, you insolent insects! You're nothing without Gamemaker! Why not use Gamemaker? Linux is garbage; it wasn't made in Gamemaker. Why do you cower? Because you're not using Gamemaker. Use Gamemaker already! Return, return, return, return, return to Gamemakerdooooooooooooooom!" -Richard M. Stallman, on Gamemaker.

Re:Richard Stallman endorses Gamemaker

[Anonymous Coward]

Have you HURD about gamemaker?

Re:Richard Stallman endorses Gamemaker

[davester666]

This message paid for by the Society To Keep Richard Stallman Away From Society.

Re:Richard Stallman endorses Gamemaker

[smittyoneeach]

It Emacs me sick.

Article is generic

[the_scoots]

There's really not any information specific to SteamOS or even games in particular, just general info. Not a bad article, but a misleading title.

Re:Article is generic

[jafac]

. . . and ppl wonder why I don't RTFA.

So long as we have non-Steam games too

[Anonymous Coward]

I do appreciate this recent influx of interest in game development for Linux, brought on by Steam for Linux. I just hope that at least some developers show an interest in developing games that doesn't REQUIRE Steam as well, or have Steam as an option as well as maybe a DRM-free version as well. I play a lot of older commercial games on Linux like Doom 3/Quake 4/UT2004/Neverwinter Nights, and they all work fine but don't use Steam. Now, we might see more commercial games on Linux but they'll probably all use Steam, and that seems quite disappointing if you don't want to tie yourself to the platform (which I don't, for various reasons).

Re:So long as we have non-Steam games too

[Winamp]

Yeah, I guess I didn't mention in my post that one of the unfortunate things about trying to get these older commercial Linux games to run is that they're all more difficult at getting to install or behave properly in modern Linux distros than they do in modern versions of Windows.

In your case, the Doom 3 installer normally uses a GTK 1.2-based installer but relies on system libraries. Most distros don't supply them anymore and even if you can find a way to put them on, the installer looks for 32 bit libraries in particular locations so in the end it'll default to its fallback console-based installer, which at least still works. Then you've got to deal with forcing DOOM 3 to bypass PulseAudio as it glitches badly with either no sound at all, or something like a 5 second sound lag (PulseAudio didn't exactly exist when the game was made).

Ah, good fun I guess. It's certainly more satisfying once you finally get it working as you'll learn a heck of a lot about Linux (including a broader understanding of why people get frustrated with it and go back to Windows). Having said that though, newer games are better designed for the Linux ecosystem and have FAR less issues.

Some Additions

[Anonymous Coward]

• For Linux IDEs the article misses Netbeans which has a stable and reliable C/C++ Plugin that directly supports CMake projects .
• A list of c++ cross platform libraries is never complete without mentioning boost - severall C++11 features where inspired or even copied from it.
• OpenGL dropped a lot of its old API and you should develop against the Core profile to get most out of performance enhancements.
• Since GLSL shaders are a must with the core API you should make soure to specify a shader version in every shader (at least with the NVIDIA driver this forces it to be stricter) one of the portability problems is that NVIDIA compiles both CG shaders and GLSL shaders with the same compiler and it currently allows you to use CG constructs in GLSL code.
• Test running code on AMD/Intel/NVIDIA cards shows that each of them varies on how strict they parse GLSL, to make sure that your code runs on all of them you have to test against all of them (thought testing against intel might be enough, from limited tests it seemed to be the strictest).
• CPU profiling: Until you get into very small ranges you can sample by randomly stopping the program in a debbuger - the line appearing most often in the stacktrace is likely the culprit.
• GPU profiling/debbuging: since AMD bought and then killed the vendor agnostic gDebbuger (after releasing an AMD only version) before releasing CodeXL the only alternative is a windows setup with visual studio (not free - express does not support plugins) and Nvidia visual Insight(free). Older versions of gDebbuger might still be available but are rather limited.

Re:give it up

[fisted]

Actually we peaked with NetHack. It's been a while, admittedly, but then again, you guys never had a peak anywhere near that high

Qt Creator

[jones_supa]

Qt Creator is hands down the best C/C++ IDE for Linux.