DE: A bit about yourself?

DH: I graduated in 1988 with a BA in Physics from UC Berkeley, after which I found a job in the defense industry performing calculations of nuclear explosions and hyper-velocity impacts for Star Wars. After The Wall came down in 1990, defense started looking bleak, so I went back to grad school to get a PhD in Physics. I started Stellar Frontier in September of 1995 with Neil Hillis at the same time I started writing my PhD dissertation, which I completed in March of 1996 at UC Irvine. Currently, I am back in the defense industry working in Ballistic Missile Defense for Computer Sciences Corporation. I live in Orange County, CA and have a wife and two kids.

DE: How did you get started with OS/2?

DH: In my first job out of college, a coworker and I were looking to port large scale hydrodynamic codes from Cray mainframes to PC's. OS/2 1.1 was the only option available where you could use the entire 4MB of memory available on a PC and be able to multitask without resorting to DOS memory extenders. I was hooked on OS/2 from that moment on.

DE: How many people were on the design team?

DH: The core design team pretty much consisted of 2 people, myself and Neil Hillis. The Stardock Team of Brad Wardell, David Braun, Mike Duffy and Kris Kwilas provided *much* help in the form of criticism, feature suggestions and testing. Stellar Frontier wouldn't be anywhere near as good as it is today without the Stardock input. It was Brad's persistence that got me to finally rewrite the network code, so it was finally workable over the internet.

DE: What tools did you use?

DH: We used IBM Visual Age C++ 3.0. Also our subscription to IBM Developer Connection provided the MMPM toolkit and the TCPIP toolkit which were necessary for internet and multimedia functionality. A couple years back I ported it to EMX GCC also.

DE: Did you use Dart or OpenGL?

DH: Unfortunately no :(

DE: What was the hardest technical challenge to overcome?

DH: From my vantage point, the hardest technical challenge was easily the network engine. The original code had a very poor model where I was sending timestamped keystrokes over the internet and computing changes in position and velocity based on a persons history of keyboard inputs. This particular model didn't work well over the internet where you can have periods of say, 2 seconds, with no data coming in.

Brad Wardell and David Braun pleaded with me to rewrite it to be more like SubSpace, where the the positions and velocities of each ship are sent over the internet and in the absence of data, the client just linearly extrapolates the ship's position. This worked out very well but for one problem . . .

Stellar Frontier is the only game of this genre with extensive AI. The AI ships can do everything that human pilots can do. This presented many many many complications in getting things to work well. This is where Neil Hillis came in. He rewrote the entire AI to be message based so things would stay in sync between all the clients and the server. This was a lot of work. It involved lots of code ripping and tons of testing. Luckily, we finally got it right :)

DE: Outside of your team, what people helped the most?

DH: As I said before, the Stardock team was extremely valuable in terms of their input. Others included my brother in law, Michl Binderbauer, who generated all the original artwork. Alex Gonouropolous from Stardock, who created all the current artwork, ships, planets, weapons, etc. Nate Allen, was our webmaster for a while. He created the splash screen and did a lot to take a tired old site and give it some pizazz. My dad who loaned me $2000 to buy a speedy new 166 MHz Pentium to replace my aging 486. My wife and children for putting up with the long hours for no apparent monetary rewards.

Lastly, I have to mention the veteran players like David Eckard, Anaxis, Chris Stumpf, etc. who have stuck around all these years during the beta.

DE: How long did SF take from start to finish?

DH: We started fiddling around with Stellar Frontier as an OS/2 advocacy project in September 1995. It was originally to be a better netrek than netrek. It soon sprialled out of control in terms of what we were trying to create. It was a classic example of a chaotic development process. The end product simply evolved until the day the players seemed to be having fun and the game wasn't crashing every hour ;) The game was released as 1.0 in June 2001. That's almost six years (^_^)

DE: What was the best part about working under the OS/2 OS? What was the worst part?

DH: The best part of working under OS/2 was that it truly was the most stable platform when we started SF. It came with all the tools (network, video, audio, etc.) necessary to create a cutting edge game at the time. Windows was just not as good.

The worst part of OS/2 was the stagnation of the platform. It really didn't evolve much after Warp 3 and it seemed after a while that fixpaks were breaking as many things as they were fixing. So it felt like it was falling behind the state of the art of operating systems while not really getting any less buggy.

DE: How does OS/2 compare to other platforms you have developed for?

DH: OS/2 was the premier OS platform for PC's from 1990 to 1996. In my opinion, NT 4 eclipsed OS/2 when it was released, although I personally avoided it until 1 year after its release.

DE: What part of SF are you most proud of?

DH: I am most proud of all the network code from the game physics to the nexus. The entire system keeps track of servers all over the world with a database of over 35,000 players and rarely needs my attention. I can go months without even logging in the nexus to see whats going on. The whole thing just runs itself.

I would bet that if you asked the same thing of Neil, he would say he is most proud of the AI and the overall design of the game. The AI is easily the most advanced in any game of the genre. You have to play for a while to be able to figure out who is human and who is AI. The game design was truly a work of genius on the part of Neil. He wrote it to be more of a virtual physics engine than a set of game rules. It was designed to be extrememly extendable and flexible. We don't impose arbitrary rules on what you can do in the Stellar Frontier universe, players are only limited by the physics model. Players are always coming up with new ways to use the weapons and other ship's systems and also there is always a constant buzz of people making custom servers with graphics and sound effects that rival the graphics that we created ourselves.

I might add that I am extremely proud of the community that has built up around Stellar Frontier. From the people chatting it up on the newsgroups and in the game to the people working away on custom servers. They really make the game what it is today. In fact, there was period of time when Neil and I hadn't been active at all in the game for period of over 6 months due to other obligations. When we came back, we were amazed to find a thriving community had grown up in our absence.

DE: What hints or tips do you have for anyone playing SF?

DH: Read the help a little, listen to the advice of veterans, read the newsgroups and most of all, be civil online :)

DE: In hindsight is there anything you would have developed or designed differently.

DH: I think we eventually got it right. We took several wrong turns, but where we are right now is exactly where we wanted to be. I might add that over time, we have learned many tricks of the trade and programming practices that weren't used to code SF, but that were learned over time. I sometimes still get the urge to go in and do massive rewrites of what I consider to be old *bad* code. But then my wife bonks me on the head and I'm cured of my momentary insanity ;)

DE: Can you explain what you meant by porting it to GCC?

DH: Yes. I wrote Stellar Frontier in C++ by encapsulating all the OS specific functions into generalized C++ wrapper classes. This was to make it portable between OS/2, Windows and UNIX.

Example:
inline _TcpipSetSocketBlockingMode( long sock,int flag ) {
flag = !flag;
# ifdef WIN32
ioctlsocket (sock,FIONBIO,(unsigned long *)&flag);
# endif
# ifdef OS2
ioctl (sock,FIONBIO,(char*)&flag,sizeof(int));
# endif
# ifdef UNIX
ioctl (sock,FIONBIO,(char*)&flag,sizeof(int));
# endif
return(0);
}

GCC can be operated in two modes, one of them supports a more UNIXY way of doing some things, like the structure of the include files, the socket API, multimedia, etc. Porting was really simply a matter of adding a bunch of #ifdef GCC statements wherever necessary to get things to compile.

In the other mode, things are more OS/2ish, so I had to add some #ifdef GCCOMF (I forget what OMF stands for) to differentiate between different options. For example:
#if defined(OS2_MODE) && defined(__GNUC__)
# define OS2
# define GNUCPP
# define PLATFORM "IBM OS/2 Presentation Manager API"
# define COMPILER "GNU C/C++ Compiler for OS/2"
# ifdef GNUCPPOMF
# define IBMTCPIP
/*# define IBMMMOS2*/
# endif
#endif

DE: What compiler would you recommend for anyone wanting to create native PM apps? GCC, VisualAge C++ (V3 or V4) or other?

DH: I would always recommend using the tools that are going to be supported for the longest period of time. As long an Eberhard Mattias, is active in developing GCC, I would recommend it. By using this compiler, you are saving money and you can more easily make a transition to Linux if you want.

DE: What tips, tricks or traps come mind about writing PM apps under OS/2?

DH: Definitely, write your own set of C++ classes to wrap around the OS/2 API. It makes life soooooo much easier. You still learn the API, but you don't have to repaste 20 lines of code to create a window every time you start a new project. The classes I created act as a great way of archiving all I know about the OS/2 API.

Here is an example of what I mean. The following is a button class I wrote. If you have all the appropriate headers, it compiles on OS/2 and any flavor of Windows or UNIX.

If I want to create a new button all I do is

 .
.
.
OKButtonHandler(S_Button *b)
{
return b->parent->Close();
}
.
.
.
new S_Button(parent,"OK",OKButtonHandler);
.
.
.