BACK IN DECEMBER OF 2001, Eric Gunnerson coded a C# implementation of the classic game Spacewar using the interop capabilities of .NET to access the DirectX 7 API. In May of 2002, he uploaded the code to help launch the .NET community Web site, GotDotNet (http://www.gotdotnet.com). Eric is a Microsoft Visual C#.NET program manager and author of the Apress book A Programmer's Introduction to C#, Second Edition. Eric also writes a C# column for MSDN Online called "Working with C#."

With the release of the Managed DirectX libraries, we decided it would be fun to update the Spacewar game. If you would like to see Eric's original Spacewar DirectX 7 source code, you can find it at the GotDotNet site in the sample code section. In addition, this version of the Spacewar game, shown in Figure 5-1, can be found on the GotDotNet site as Spacewar2D (http://workspaces.gotdotnet.com/spacewar2d).

About Spacewar

Spacewar was conceived in 1961 by Martin Graetz, Stephen Russell, and Wayne Wiitanen. It was first realized on the PDP-1 at MIT in 1962 by Stephen Russell, Peter Samson, Dan Edwards, and Martin Graetz, together with Alan Kotok, Steve Piner, and Robert A. Saunders. It's widely credited as the first video game. Although the graphics are primitive compared to today's standards, the game play is still outstanding even after more than 40 years! (Figure 5-3 shows the coin-operated version.)

Deciding What to Change

Although we wanted to bring the game up to date with respect to the source code, we didn't want to alter the gameplay. In fact, we've worked pretty hard to make the game faithful to the coin-operated version. Scott Haynie, a game developer with great Managed DirectX experience, came to us about porting the Spacewar game to Managed DirectX. After looking over Eric's source, we made a list of the changes to make to the code. The obvious first choice was to remove any DirectX 7 interop calls and replace them with Managed DirectX methods and classes. For network play, Eric used the System.Net.Sockets namespace. Although we could have left the networking piece alone, we felt that using DirectPlay (which was covered in the previous chapter) was a more logical choice for the upgrade. The same applies to the input and audio classes. Instead of the custom KeyEvent handlers, we could now use DirectInput and the Managed DirectSound namespace.

Those are the major changes, but we made a few others design decisions along the way:

• Eliminating the use of pointers: Eric used the pointers in the original version to increase speed in the network routines, but using DirectPlay eliminates that problem. In addition, using "unsafe" programming in C# should always be a last resort.
• Scoring: Scott was up late one night working on converting the player update code, and was getting a headache trying to figure out how the points got passed in the ship update packets. He cut them out of the ship updates and made each score update a separate, guaranteed delivery packet. In the process, he introduced an interesting side effect: It reduced the network load because it only sends a 1-byte score update message when someone dies. A very nice side effect!
• Game configuration:We created a GameSettings class to allow you to change the way the game plays without recompiling. This made it easy to add some of the options from the coin operated game, such as
  • Variable gravity
  • Inverse gravity
  • Variable game speed
  • Bouncing off the game boundaries
  • Black hole (invisible sun)

Originally, we considered converting the ship graphics over to sprites and just animating them, but the clever line drawing classes Eric put together for the font and the ships looked pretty darn good, and added to the retro feel that we wanted to preserve in the game, so they remain the same as he originally coded them.