Netrek is a multiplayer action game for two teams of 8 players each. It was written for play over the Internet long before such things became commonplace. It feels more like a sport than a video game, and is seriously addictive. College students used to say that "GPA + netrek rating is a constant".
While it looks easy enough to jump in and play, it takes a while to become proficient with basic dogfighting skills, and the rule of thumb is that it takes 200 hours of play time before somebody becomes fully "clued" to the subtleties. Talking to your teammates isn't a nice feature, it's an absolute necessity, so much so that some "clue servers" would throw you off if you didn't respond to automatic messages.
I had little to do with the game's initial development, but I made other contributions from late 1991 to mid-1992:
- Ported client and server to Amdahl's IBM-compatible mainframes running UTS2.1 (SVR3). The "Amdahl client" had some features that got blended into other clients (like visible tractor beams) and other features that didn't (scanning beams).
- Wrote XShowGalaxy, a/k/a XSG, a server monitoring and tweaking tool. This was greatly enhanced and extended by Tedd Hadley and others.
- Modified the network code to use UDP packets instead of TCP.
- Wrote pledit, a curses-based player list editor.
- Wrote gw to get past the bastion-host firewall.
- Wrote trekhopd after I got caught using gw on the bastion-host firewall. It serves the same purpose, but is more secure.
- Wrote MetaServerII, a "meta-server" for Netrek. Last I checked, you could still query it by telnetting to metaserver.netrek.org:3521 (there are other ports that return different sets of information).
- Developed the MUCUS PIG translator (in the tradition of valspeak and jive).
Support for most of the programs was taken over by other Netrek enthusiasts after I started working on other projects in my spare time.
I also created the FOCS (Frequently Offered Clever Suggestions) list to address game improvement ideas that were being made over and over on the rec.games.netrek Usenet group. Here's a copy from Nov 1994.
The original version of Netrek used TCP as a reliable transport to send game updates to the various players. One weekend in 1992 I modified the client and server to use a mix of TCP and UDP. The trick with UDP is that it's an unreliable transport -- packets can arrive out of order or be dropped entirely. This has an obvious downside, in that game state updates can be lost, but one major upside: if a packet is lost, the game client doesn't have to wait for the server to re-send it before it can receive additional updates. For an action game, there are updates that must not be lost (e.g. "you died"), and updates that are only useful for a very brief period because they will be replaced next frame ("the enemy ship moved to a new position"). So, I changed the code to send the critical stuff over TCP, and the ephemeral stuff over UDP.
The improvement was remarkable. Laggy, stuttering connections became smooth. Many people who weren't able to play because of poor network connectivity were suddenly getting performance near what local players got.
As far as I know, Netrek was the first Internet game to use UDP for updates. There were some LAN games, like ACM, that used it to broadcast updates, but those expected UDP to be a reliable transport.
As it turns out, mixing and matching TCP and UDP is a bad idea, because it means some game state can arrive well out of sync with other state (you'll see your ship explode, then wait a while for the "you died" message to show up). You can get much better results by building a reliable transport on top of UDP, which is what pretty much every Internet game since has done.
For historical interest there are two documents here that explain the UDP changes. When reading these, bear in mind that there were a multitude of Netrek clients being supported by several different people. The UDP changes weren't made to "the source code", they were made to my source code and then distributed as context diffs. It had to be as simple and as tightly contained as possible. As a result, the UDP features were disabled by default, and enabled either in the config file or by bringing up a separate panel in the user interface.
- UDPCLIent.doc - Explanation of the user interface changes.
- UDP_README - Details about the implementation of the protocol.
There were a lot of conflicting stories about how Netrek began. Some people claimed it came out of a lab at MIT, others felt it must have originated at CMU since so many of the great players were there in the early 1990s. In 1994 I did some research and tried to set the record straight, publishing three documents:
- History (raw) - A discussion of how Netrek came to be. I never got around to finishing this, but it's got some good info about the early days.
- Timeline (raw) - Important events in Netrek's history, from the very beginning up to January 1, 1994.
- Servers (raw) - As complete a list of public Netrek servers as I could manage.
These are the unmodified files from 1994. Each "raw" file is in a meta-format that can be converted to plain text or passable HTML with "grep" (which I have done for the non-raw version).
A couple of utilities I wrote that may be hard to find elsewhere.
|Name: trekhopd v1.52|
|File: thd1.52.tar.gz||Size: 41K|
|Author: Andy McFadden||Written: September 1993|
|Summary: Bastion-host firewall packet-passing daemon|
I wrote trekhopd because Amdahl used a dual-homed host as its Internet firewall. Netrek's TCP connection setup didn't work very well with this scheme, and of course UDP didn't work at all. The previous program, "gw", played a little fast and loose with connections, which didn't make the firewall admins terribly happy. This was written to placate them.
The last version I touched was trekhopd v1.51. v1.52 was done by Otmar Lendl, who ported it to Linux (which was mostly a matter of fixing the endianess problems), and cleaned up the code a bit.
BTW, if the firewall you're behind is a router that blocks UDP, ask your firewall admin to cut a hole in a high port range (like 48000-48015), and use one of the clients that supports the "-U" flag.
|Name: pledit v1.02|
|File: pledit1.02.tar.gz||Size: 17K|
|Author: Andy McFadden||Written: August 1992|
|Summary: Netrek player list editor|
The traditional way to edit the Netrek player list file was to run a program that converted it from a fixed-record-size binary format to ASCII, make the changes, and then convert it from ASCII back to binary. This was a bit cumbersome when the player lists got large, didn't provide a very intuitive user interface, and broke rather badly when the "Pig client" started sticking newlines into the keymap section.
Pledit is a nifty little curses-based player list editor with form-based editing and a configurable keymap. If for some bizarre reason you want to write something that uses curses, you might want to look at what I did here.