Space Tyrant: A strategy game and C programming project [page 3]

Deep Space & Dark C

The Space Tyrant Programming Model

I considered several programming models for the Space Tyrant server design. The Last Resort (TLR), a predecessor to Space Tyrant (ST), is based on a process-per-user forking model using inetd or xinetd to handle the listening and spawning of new processes. While the forking model is inherently distributable to multiple processors, it introduces inefficiencies such as extra memory usage and it also makes coordinating user activities slow and difficult.

Second, I considered a non-blocking, single threaded, single process model. In this approach, one process handles everything in a single thread. It would use non-blocking IO, where IO functions return immediately if they encounter a would-be delay to their read or write operation. Obviously, the code logic has to keep track of pending IO operations and the user sessions dependent upon them. The thttpd web server is an example of a non-blocking, single process server. It's extremely fast and efficient although it only makes use of a single CPU core. However, this model is quite complicated to code, and might make it easier to introduce timing bugs.

Third, I considered a pure multithreaded, single process model with a thread for each player. While appealing in many ways, this model would require the same kind of coordination between threads that the process-per-user, forking model requires between processes. Such interprocess communication would be slightly simpler than the forking model in that the various threads inherently use the same memory, but the coordination issues otherwise remain the same.

Last, I considered a hybrid threaded model. This model would include IO threads for each user, a disk backup thread, a network listener thread, and a single master thread to implement all game logic and data manipulation. While that central thread might become a bottleneck on multicore systems, it does offload the IO processing, listening, and backup to any additional processors, and, best of all, it requires minimal coordination overhead.

The IO threads would write their requests to queues serviced by the game logic thread, which would send a response to each IO thread as that thread's requests are completed.

The listener thread's job would be to listen for new network connections and to spawn IO threads for each new player connection. The backup thread would periodically scan the game data and write any modified data blocks to disk.

This model combines the game logic simplicity of the non-blocking single process model with the coding simplicity of the threaded model, while separating the IO -- and its associated delays -- from the main logic.

The tradeoffs seemed quite acceptable so this last model was the approach used for the ST project.

The code is written in C to compile with GCC and runs under both Linux and Mac OS X.

mail this link | permapage | -Ray, March 6, 2007 (Updated: March 30, 2007)

The history of the Space Tyrant game design

In the fall of 1986 there was a BBS in Tallahassee called "The Eagle's Nest" that ran Chris Sherrick's version of a game inspired by Dave Kaufman's "Star Trader", originally published in the in People's Computer Company's newsletter and later in their "First Book of Computer Games". There are also reports that Star Trader was published in Hewlett-Packard's "People's book of computer games". This is the book that I remember Norm Pettus, the Sysop of The Eagle's Nest, telling me he had in his library.

In any event, Chris' versions were called Trade Wars and Trade Wars 2.

Trade Wars 2 (TW2) was a simple turn-based strategy game where players could explore a galaxy, earn money by trading commodities at planets and ports, buy fighters, guard sectors, and attack other players.

TW2 was set in a 99-sector galaxy which was filled with aliens called "the Cabal" who would harrass the players and generally prevent the kind of player-vs-player game that I wanted. While it had great potential as a PVP strategy game, it was small and further limited by bugs and the Cabal -- which, to me, took away from the core appeal. As a programmer with a copy of QuickBASIC for my 1985 PC, I decided to write the game that I saw struggling to get out of TW2.

My first Star Trader genre game, Czarwars, was designed as a stand-alone bulletin board system (BBS) which would answer the phone for each player, let them play, and then wait for the next player. The first running version was written from scratch over a period of two months, was 350 sectors in size, and was based on an extendable map design.

The initial series of games worked well and typically served 30 or 40 players per day in the one and only game universe. It was essentially an asynchronous turn-based game that used daily-issued 'antimatter' to fuel each ship's movements, rather than the traditional concept of 'turns'.

Czarwars grew to 4000 sectors and ran on several BBS's in Tallahassee, as well as elsewhere, until at least 1993, when my original Anarchy Garden BBS phone number was lost in a move across town.

Thus began a three-year Period of Darkness.

By the summer of 1996 I had been running Linux for a year and was looking for a C programming project. So, I started the new Tsarwars project from scratch. Like the first Czarwars, it took about two months to get the first functional game running. This time, however, it used TCP/IP networking so that multiple players could connect simultaneously. That version supported telnet and browser connections.

Tsarwars, by the beginning of 1999, was a pretty coherent and playable game. That's when I began designing a new scenario, "The Last Resort". TLR wasn't a straight retrofit of Tsarwars. It was a new game that borrowed what code it could and added everything else it needed. Instead of space, the TLR universe was set in old hotels in an abandoned resort city on Jupiter's moon, Io.

Eventually, that game got converted back into the space-based scenario, but because of its many changes, it was renamed Starship Traders. That wasn't to be the end of the TLR scenario, however. I next merged the two games so that space contained TLR-style planets -- embedded worlds within space that you could discover, take over, and defend.

Those worlds added new terrain, varying productivity, and initially unknown and defendable natural fortifications within the game. Unfortunately, Starship Traders' codebase was by then a mess. It was about 20,000 lines of C code, with two different in-game scenarios, and it included telnet, web browser, and graphical client interfaces. Since every game sector was stored on disk performance in large, busy games was poor.

Yep, it was time for yet another rewrite.

The new game, called Space Tyrant, is an open source implementation of a subset of the Starship Traders/TLR game design and was written entirely as a single C program based on a new programming model. Unlike its predecessors, Space Tyrant runs with all of its data in memory for optimal performance.

For a copy of the source code and instructions on how to compile and run it, go to the Space Tyrant source code and compile instructions page.

You can also take a more direct look at the game by logging in to a running game here.

mail this link | permapage | -Ray, March 6, 2007 (Updated: July 26, 2008)

More articles...