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.