Linux DevCenter    
 Published on Linux DevCenter (http://www.linuxdevcenter.com/)
 See this if you're having trouble printing code examples


The Ur-Quan Masters

by Howard Wen
08/11/2005

When the original developers of Star Control 2 contacted the online Star Control fan community, they presented an enticing question: if they released the source to the 3DO version of Star Control 2 under GPL, would anybody be interested in porting it to modern-day computers?

Michael Martin, a 26-year-old Ph.D. student at Stanford University, answered the call. After removing proprietary 3DO-specific components from the code, the developers released the source for Star Control 2 to the public. Martin and other Star Control fans then organized themselves to port the game to run on modern systems and operating systems. They renamed the project The Ur-Quan Masters, because they do not actually have the rights to the name Star Control.

In November 2002, the fans-turned-developers released an alpha of their port. The current release is still in an alpha state, but it's playable from beginning to end. The only major missing features that correspond with the original 3DO version of Star Control 2 are a user-friendly, in-game configuration system, and content displays. The Ur-Quan Masters is a fully playable port of the 3DO version of Star Control 2 done by fans of the Star Control games. Figure 1 shows the Linux version of the port.

Thumbnail, click for full-size image.
Figure 1. The Linux version of The Ur-Quan Masters--click for full-size image

"While it's an alpha, it's more stable than many commercially released games," claims Serge van den Boom, a 26-year-old computer science student at Eindhoven University of Technology in the Netherlands. Among his contributions to Ur-Quan, he developed the Linux port of the game.

The most obvious question is: why port Star Control 2 at all? It ran on Windows 98 with some effort, but rarely if at all on newer versions of Windows without the use of an emulator such as DOSBox. As the project's goals page suggests, bringing the story and game humor to other platforms for the first time was a major reason for the work. As Figure 2 shows, even the original graphics still look nice, though UQM scales them to look prettier at higher resolutions.

Thumbnail, click for full-size image.
Figure 2. The port features improved graphics resolutions--click for full-size image

Related Reading

Gaming Hacks
100 Industrial-Strength Tips & Tools
By Simon Carless

Speaking of graphics, another project goal is to allow people to make their own modifications for the game. There are no plans currently to produce new graphics add-ons, but there are three or four new music packs. Of course, the game will still be playable and fun with the original media files.

"Star Control 2 is generally considered to have been one of the greatest sleeper hits of the early '90s," says Martin. "It also hasn't really been runnable on any system once Windows 98 became standard, and its 1993 console port was to a system, the 3DO, that sank without a trace. Those of us working on the project are all part of its fan base, so the project more or less justifies itself for us." Martin's primary work on Ur-Quan has involved updating the original code's 2D graphics rendering engine.

Additionally, the 3DO version of Star Control 2 contained a lot of extra content and some modifications that made for a smoother gameplay experience. To reiterate, it is the source code of this version that Martin, van den Boom, and their fellow fan developers have used to update for play on modern computers.

Martin and van den Boom spoke with us about the unique process they've been going through in their porting of GPL, formerly closed, code.

Howard Wen: What would you like people to pay notice to most about your Star Control 2 project?

Michael Martin: The game itself. It borrows a number of gameplay elements from earlier games. The Starflight series is the most obvious influence on the exploration segments, and the combat system was explicitly designed as a modernized version of SpaceWar. The synthesis [the Star Control games] created of them has not been credibly--or even feebly--imitated since.

Serge van den Boom: Everyone I know who played Star Control when it was originally released loved it. Anyone who is bored of modern games, which provide little more than fancy graphics, should try it. Those who originally played the game on the PC may want to try [our port] too, as it includes the speech and other enhancements of the 3DO [version].

Also, I'd like to direct your attention to a related project by a group called Precursors. They are remixing all the music of the Star Control game. It was started at the same time as the source was released. We've been in constant contact with them.

HW: For now, what are the technical limitations of your port?

MM: The core code is still convinced that it's running on a 320-by-240 screen. So drop-in replacement of higher-resolution graphics or the like isn't really feasible.

The code also does a lot of rather questionable pointer arithmetic, and as a result is not currently "64-bit clean." Issues have been seen to arise on architectures where structure alignment is a requirement as well.

SvdB: On the other hand, the game is already playable on [32 bit] big-endian systems, like Macs.

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.

Copyright © 2009 O'Reilly Media, Inc.