Linux DevCenter    
 Published on Linux DevCenter (
 See this if you're having trouble printing code examples

An Interview with Loki Games' Scott Draeker

by J. S. Kelly

Loki Games was the first company dedicated to commercially porting best-selling computer game titles to Linux (because "world domination should be fun").

The company was a pioneer in porting applications from Windows to Linux, and has been deeply involved in the Linux community. Most recently, it spearheaded the OpenAL project, which is devoted to the development of an open-source, cross-platform 3D-Audio library which hopes to become the equivalent, for sound, of what OpenGL is for video.

The O'Reilly Network talked to Loki founder and President Scott Draeker about porting Windows applications to Linux, the Linux market, and the importance of giving back to the Open Source development community.

J.S. Kelly: As far as I can tell, you founded Loki with the intention of porting the best games from the Windows and Mac world to Linux. That is, you founded the company first -- and then set about finding your first product to port. Is that correct?

Scott Draeker: That's right. I spent several months after leaving my previous job putting together the company, finding the people we needed, and negotiating licenses with publishers. We signed the CivCTP contract on December 31, 1998, and started coding January 4.

Kelly: When you did strike your first deal, with Activision, to port Civilization: Call to Power to Linux? What happened next? Had you already assembled a team that was experienced in porting applications across platforms, or was it a completely new kind of challenge?

Draeker: We had a great team, but no one anywhere had ever done this before. In fact the tools we use -- GCC, GDB, and others -- were in some cases inadequate and needed to be enhanced. A year later, we still spend a significant amount of time enhancing tools, as games tend to always push the state of the art.


When Richard Stallman founded GNU, which stands for GNU's Not Unix, the first thing that needed to be created was a compiler -- the software that translates the source code a programmer writes into the object code a computer understands. Stallman's free C compiler, (EGCS) was later renamed GCC (GNU Compiler Collection). Today, development of GCC is controlled neither by Stallman, nor -- as is commonly believed -- by Cygnus (now a part of Red Hat), but by an independent steering committee.

GDB is the GNU source-level debugger, which monitors a program at runtime to analyze what it was doing at the time of a crash, in order to narrow down the possible location of a bug.

It is not possible to overstate the importance of these and other free GNU tools to the history and development of free software.

To this day, proprietary compilers and debuggers are not standard components of proprietary Unix systems. They are usually licensed as expensive "developer" add-ons. These free tools which gave power to individual developers and small companies, and which made the rise of Linux -- and innumerable other open source projects -- possible at all.

One of the reasons we've been successful is that we have always believed in open source development. Once we started coding, we had questions and problems which needed to be addressed, and in each case we received the help we needed from the developer lists.

Kelly: Were you able to take advantage of tools which already existed, and if yes, which ones? Or did you have to write a lot of your own toolset?

Draeker: We strongly favor open source tools over proprietary alternatives. That cuts both ways. The downside is that sometimes the only way to get something fixed is to do it yourself. The good part is that you have the source so that fixing things is possible.

In the course of developing Heavy Gear II, we've added several significant functionalities to the GCC compiler. We contracted with Mark Mitchell's CodeSourcery to rectify code-generation problems present in g++ that prevent the proper destruction of static C++ objects in shared libraries at the library close time, rather than the program exit time. This functionality was also contributed back to the community.

Kelly: Have new tools emerged since then, that you wish you'd been able to use from the start?

Draeker: We're very much looking forward to GCC 3.0, particularly for the C++ enhancements. We're also looking forward to better debugging tools, an incremental linker and possible support of Visual C++ extensions.

Kelly: It seems to me that until recently, most Unix developers didn't know much (or care much) about Windows and most Windows developers didn't know much (or care much) about Unix ... Which kind of knowledge was most useful to you in different phases of the project to port a sophisticated Windows application to Linux: developers who had an intimate knowledge of Windows programming, those who had an intimate knowledge of Unix and Linux programming, or those who were familiar with the programming environments of both platforms at the same time?

Draeker: Knowledge of Windows is helpful, but not necessary. This seems counterintuitive as we're porting Windows code, but in fact, most of the Windows specific stuff just gets dumped anyway. Knowledge of Linux is absolutely necessary. A lot of the value we add is not in making a Windows product operate under Linux, but in creating a Linux application that takes full advantage of its new environment.

Kelly: In the Loki Games press release announcing the deal with Activision, you are quoted as saying that Loki Games was "committed to providing an identical port of the new release" of Civilization: Call to Power. Was the Linux version, in the end, an "identical port"? If yes, what were the biggest obstacles that you had to overcome to achieve that goal? And if no, what were the unforseen things that prevented it? Is it possible to overcome them these days, or are they easier to spot ahead of time, now that you know what they are?

Draeker: Civilization: Call to Power on Linux was virtually identical to the original. We even left bugs in that had to persist in order to preserve network game compatibility between the Linux and Windows versions.

The last frontier for 100-percent seamless transition from Windows to Linux games is DirectPlay, Microsoft's networking API. DirectPlay is closed and proprietary, which means there is currently no way to achieve network compatibility with Windows games that use it. [Civilization: Call to Power does not use DirectPlay.] We're looking at ways of surmounting this last barrier.

Kelly: In addition to Loki, companies like Oracle, Corel, and MetroWerks were early to decide to port applications from other platforms to Linux. As far as I know, most of them do this work in-house. Meanwhile, Sendmail has decided to port their traditionally Unix product to NT. To do so, they acquired a company which had been developing a Sendmail-like program for NT, and if I am not mistaken is currently working to merge the code base for the two [Unix and NT] versions. They are also working in-house, but with code they acquired from somewhere else. Your company seems to follow a different model still -- I know that you work very closely with ie Activision when porting a game, but in a way they are outsourcing their porting to Loki instead of doing it themselves. In your opinion, what are the pluses and minuses of these different ways of porting applications?

Draeker: I think the different models you describe are driven by the economies of the particular market. Porting itself just takes takes the proper developer talent. But how many times has a developer wound up with cool code that he or she can't get to market?

Our model addresses the biggest reason why game companies don't port to Linux -- the QA, distribution, and end-user support. Game companies are set up to do these things for Windows, not Linux. A great example is Quake III Arena for Linux. We didn't do the port, but we are publishing it.

Kelly: I see on your web site that you are supporting several open source projects, like SDL Motion JPEG Library (SMJPEG). How valuable is this kind of activity for you in advancing the overall ease and/or quality of your porting efforts?

Draeker: SMPEG, SMJEP, Setup, and others are required pieces for games to run on Linux. We had to create them in order to develop our products. The questions was whether we would give them away as open source. Releasing the source code can be a scary thing. We spent nearly a year figuring out the "right" way to do full screen support for non-root users. Once we had it down, the code was on our web site within days, and any fool could download it and compete with us if they chose.

Of course, people could also use our code to create new games and other applications for Linux -- and that's a good thing. In addition, we've received numerous patches and suggestions from the community. One of the enhancements I'm most proud of is the upcoming hardware MPEG playback for SMPEG. We're working with ATI to add this functionality for ATI's Rage 128 and Rage 128 Pro video cards. In the future this could lead to full DVD support under Linux using SMPEG, ATI hardware, and third-party drivers. I believe all of this is a direct benefit from our releasing the source.

Kelly: I've heard from Corel that they are cooperating closely with the WINE project. As far as I know, they started out thinking they'd have to port all of their code by hand, then found out that they could run their applications on top of WINE, then changed their tactics again and are now compiling their applications to link in to WINE as a library. Are there other possibilities to find synergy between independent projects -- like WINE, FreeMWare, Samba, etc. -- or other tools and porting efforts? What are the pluses and minuses of each of these?

Related Resources

• Other press coverage of Loki

• Recent Slashdot interview with Scott Draeker

• Recent Game Daily interview with Scott Draeker

• The Hacking Contest Nobody Tried to Win

Draeker: I view applications such as VMWare and WINE as sort of a "spare tire" for people leaving Windows in favor of Linux. Porting legacy code and even running Windows apps is nice to have available, as you don't have to wait as long to make the transition. On the other hand, Linux won't be successful in the long term if it's just another way to run Windows apps. That's why we don't use emulation or take other shortcuts. By creating a Linux application, we are able to show off the advantages Linux has as an OS, something which even perfect emulation can never do.

Kelly: Is there anything that I forgot to ask about which I should have asked, or any piece of advice that you'd like to give to developers who are just starting out on the porting path?

Draeker: I would recommend that developers looking at creating Linux apps think first about their market. Linux users are very well informed, technically savvy, and have high expectations. Just slamming out a Linux version of your failed Windows application won't cut it. Set your standards higher. I would also recommend that you keep in mind the things that have made Linux successful commercially and in the development community. If your business model doesn't take into account the things that make Linux successful, if you pretend this is the Windows or Mac market, then you are in for a tough time.

Discuss this article in the O'Reilly Network Linux Forum.

Return to the Linux DevCenter.

Related articles:

Interview: Mendel Rosenblum of VMware - VMWare's Chief Scientist explains the virtual machine that runs multiple operating systems on your desktop.

VMware and My Alien Dream - Years ago, I dreamed an alien tinkered under the hood of my computer, leaving it running Unix, Windows, OS/2, MacOS...


Copyright © 2009 O'Reilly Media, Inc.