Month: January 2013

We Want Linux to be a First-Class Citizen for Game Development

Right now, Linux has some great programming libraries for developing games, but when it comes to working as a level designer or an artist, the tools are lagging behind Windows and Mac OS X. It’s not from lack of trying. There are great developers working on tools day and night for Linux, but the going is slow. Unity announced an export option for their engine so that game developers on Mac and Windows can export to Linux. This is EXCELLENT news for Linux game players. It’s the same news as always for Linux game developers: to make games: buy a Mac or pay for Windows if you want to make games.

[vimeo id=”55989997″ width=”600″ height=”350″]

We started this campaign to change that message. We want Linux to be a first-class citizen for game developers. We recently open sourced Torque 3D under the MIT license, and the first deluge of questions were about Linux compatibility. The move to open source Torque was something that the founders of GarageGames wanted to do over 10 years ago, but they also needed a business model for their studio.

Torque is the engine that was originally used in the Tribes series of games, and has seen a number of advancements throughout its history. Since open sourcing it, we have had nearly 300 forks of the codebase on GitHub. You can find out more information about Torque at the GarageGames site and download it from GitHub to kick the tires. Unfortunately, it’s only for Windows right now, so you might have to flex your Wine or dual-booting muscles to try it out.

What’s In It for All of Us?

We want a dedicated Linux-native game development platform. We don’t think that Linux game developers should have to switch between machines so that they can develop on Windows and just test on Linux. We don’t think that they should have to fiddle with Wine to get the simplest of editors to work natively, only to have the whole thing crash when importing models. We want Linux to be a native platform for game developers.

Workflow for Engines without Native Support

If you use any of the popular engines out there that have Linux support, here is a workflow (assuming dual-booting).

Open editor. Import models, edit level, add logic, etc. Build the game. Export to Linux. Copy the binary to a shared drive. Reboot and load Linux. Copy from the shared drive locally. Run the game. Crash. Get crash report. Copy crash report to shared drive. Reboot. Load engine and crash report. Find mistake and attempt to repair. Repeat.

This loop is a little faster if you have two computers next to each other and a shared device, but even then you’re switching gears and doing a lot of waiting. Waiting means that you have time to get coffee or check Slashdot for news, but it’s also time that you could be making your game.

Our Solution: Linux-Native Game Development

Obvious, right? Well, it should be. But it’s also an answer that takes a lot of time and money to implement. When commercial software companies look at their bottom line, the return on investment for developing software for Linux is really low (and often unknown) in the game engine development world. John Carmack noted during his keynote at QuakeCon that “Valve announcing Steam Linux support changes things a bit but we have made two forays into Linux commercial market, most recently with Quake Live client but that platform just hasn’t carried its weight compared to Mac” (45:26, QuakeCon 2012 – John Carmack Keynote). This was specifically about game targets, but the lack of commercial editor support for game development on Linux speaks volumes on how the engine industry feels about Linux.

Luckily, our platform layer has some of the core functionality needed for a Linux port. Our dedicated server has been used on Linux for a number of years with different games, and that handles much of the core engine functionality. What currently is not working on Linux is the game editor and shared client. That’s where you come in.

Read more