The Ur-Quan Masters

Howard Wen: What programming language did you use in the porting process?

Michael Martin: We're trying to leave the game logic itself more or less intact--as such, we stick with C. We have translated it into something much more resembling standard ANSI C now.

The original code included sizable chunks of preprocessor directives to let it compile under several incompatible commercial compilers. I would have been a preteen back then, so I can't really give a lot of insight as to which compilers were being straddled.

HW: Besides the game's original source, does your port incorporate outside code or libraries which your team did not originally develop?

MM: The most important one is the Simple DirectMedia Layer, which provides a uniform interface for input and high-speed graphics output across a great many platforms. An OpenGL rendering engine is available as well.

Audio data is stored either in the original MOD format or was converted into Ogg Vorbis, so the Vorbis decoder and the MikMod decoder are also incorporated into our system.

Serge van den Boom: The main reason these were chosen was because they would run on a wide range of platforms. We wouldn't have to worry about the system-specific features ourselves.

HW: Did you create any new technology specifically for the port?

MM: A number of libraries have been created to assist in the back end for the project--to date, only the VControl input library has been released in its own right. But a number of file- and content-management and indexing libraries are also being developed to replace the somewhat brittle original system.

SvdB: The file I/O system I created consists of a virtual file system, which is composed of the directory structures from various locations, including from .zip files. It allows for easy overriding of the standard files with files from add-on modules, as well as having data split up in various locations--game data on a [read-only] CD-ROM, saved games in a user directory.

HW: What are the biggest technical challenges you've faced in the porting process?

SvdB: While the code is really smart in some ways, it was written in an age of different programming practices. Combined with the fact that this code was never intended to be read by others--and, as a consequence, has close to no documentation--we frequently run into hidden invariants.

MM: I'd say the biggest was getting familiar enough with the code to determine which aspects of it are critical to operation, and which were kludges to make it run acceptably fast on a 286 [processor].

The code was inherited from console code for the 3DO and assumed, among other things, an asynchronous "fire and forget" threading model, which does not translate well to modern operating systems. I'm currently working on filling in new configuration menus so that features may be controlled outside of the command line.

HW: What advice can you give to somebody when attempting a port of this scale?

SvdB: Assume everything is there for a reason, however strange it may look. If you're going to replace something, don't just write from scratch, but first understand what the original code was meant to do.

MM: If the program has seen continuous use unpatched for as long as Star Control 2 did, a healthy respect for the original code is a good attitude to have. Also, focusing on writing a clean working interface to the target platform means you have runnable code much sooner.

HW: What advice do you have for others who want to port or enhance the code of a GPLed program that was once a commercial product?

SvdB: If you're porting an old game to a modern system, make use of the capabilities of the new system; trade speed and memory for portability and extensibility. Also, unless the program you are porting already included much documentation, document as you discover more of the workings of the code. And as I said before, know what the original code did before you replace [any of] it.

MM: For porting, focus on providing the interface layer between the original code and the target platform or library, and push the emulation layer as high up as possible for maximum portability.

For enhancement, keep it modular, and keep the ability to roll back to a simulation of the original game. If the game was popular enough to be GPLed but not reiterable enough to have perpetual sequels, it's a worthy goal to keep the original playable for historical interest.

Also, for either, get licensing issues straight with the company at the beginning; it's much harder to recruit an effort around something if it's not clear what the status of works derived from the content, but not the code, is.

HW: If somebody wants to contribute to your project, what skills from them could you use now?

MM: We've generally been reluctant to actively recruit developers once the project got under way, because the features we need are pretty dependent on one another. At any given time, there usually aren't more than five or six outstanding things that need to be done, and can be done, given the state of everything else.

That said, the bug list has gotten rather long as of late, and many of them involve interactions with the core code, which we haven't really studied in enormous detail. Debugging these would require more information about the structure of the core than we really have had time to discover. So code analysis and reverse engineering from the source would probably be the most useful skills [from volunteers].

HW: In the end, what are your thoughts about the open source philosophy of program development, based on your own experience in porting Star Control 2?

MM: I don't really think this is a good project to measure the OSS philosophy with.

The kinds of features that this project needs are actually mostly "orthogonal" to what the community it targets desires--in this case, to play a favorite old game again. This produces friction and makes it much easier for real life to intrude upon its developers. The other, mostly academic OSS projects I've been on were driven by new needs amongst the developers themselves.

SvdB: One large advantage of open source that has been apparent in this project is that you can build on work by others.

It's unlikely that a company like Toys for Bob, the original developer of Star Control, who makes games for a living, would spend their resources on a port of a game that never reached a large audience, when they could be making something new. Without the open source philosophy, The Ur-Quan Masters would never have existed.

Howard Wen is a freelance writer who has contributed frequently to O'Reilly Network and written for Salon.com, Playboy.com, and Wired, among others.

Return to the Linux DevCenter.

Prev  [1] [2]