JS-Spacewar 3.1


Sense Switches


FPS: 22 (orig) 60 (30)


Size: 1:2 1:1 (768, reset)

Background (“Expensive Planetarium”)


Ship 1: 0

Ship 2: 0


Ship 1 (JKLI): Left: J, Right: L, Thrust: K, Fire: I

Ship 2 (WASD): Left: A, Right: D, Thrust: S, Fire: W

Hyperspace: Left + Right

Keyboard Type:

About JS-Spacewar 3.1

This is a genuine port of Spacewar!, the first digital video game, to JavaScript. The implementation is based on the code analysis (cf. “Inside Spacewar!”) of the original program, "spacewar 3.1, 24 sept 1962" by Steve Russell et al. It is meant to illustrate the logic of the program using JavaScript as a modern lingua franca and to verify the code analysis. (Compare the original program in emulation.)

"JS-Spacewar 3.1" by Norbert Landsteiner, www.masswerk.at, March 2015.

Source Code

For usage notes, see below.

The Game

Spacewar! was conceived in 1961 by Martin Graetz, Stephen Russell, and Wayne Wiitanen. It was first realized on the PDP-1 in 1962 by Stephen Russell, Peter Samson, Dan Edwards, and Martin Graetz, together with Alan Kotok, Steve Piner, and Robert A Saunders. — Spacewar! is in the public domain, but this credit paragraph must accompany all distributed versions of the program.

(Standard credits.)

Spacewar! was initially intended to serve as an entertaining demonstration object for the real-time capabilities of the DEC PDP-1, then newly donated to MIT. A group of students and employees, the Hingham Institute Study Group on Space Warfare (named after Steve Russell's lodging), conceived the game in summer 1961 and progressed to implemen­ta­tion over the fall of the same year under the lead of Steve Russell, programmer-in-chief. A first version (without gravity or the background starfield) was operational in late 1961 and the game was basically ready in February 1962. Version 2b saw the addition of a background display featuring the slowly moving stars of the heavens (Peter Samson's Expensive Planetarium, March 1962) and was announced in the first issue of Decuscope (the DEC users' information) in April 1962. The program, complemented by a few patches, was presented to the public at the MIT Science Open House in May 1962. Finally, the program was refactored into its final form (final as far as the original group of authors was concerned), Spacewar! 3.1, in September 1962.

For more on how the program came into being, see “The Origin of Spacewar” by J. M. Graetz, Creative Computing, August 1981. (The game described in this seminal article is Spacewar! 2b with patches.)

"The most important feature of the program is that one can simulate a reasonably complicated physical system and actually see what is going on."

(Steve Russell, quoted in “PDP-1 PLAYS AT SPACEWAR!”, in Decuscope – Information for Digital Equipment Computer Users,
Vol. 1 No. 1, April 1962, pp 2, 4.)

The game features the epic battle of two spaceships, the Needle and the Wedge, each of them to be controlled by a human player. The two ships are subject to the gravity excerted by the central star, closely simulating the laws of Newtonian physics. Photon torpedoes of limited supply (not affected by gravity for the limited resources of the PDP-1) may be fired in order to destroy the opponent and eventually scores are (optionally) displayed in binary at the operator's console of the PDP-1. (The scoring device did not only display the scores in the two main registers of the PDP-1, it also allowed to set up a number of games for a match of Spacewar!.) A number of options could be set using the sense switches, a group of switches on the operator's console dedicated to user interaction. Moreover, some important parameters where put into the first few memory locations of the program and could be "hacked" on the fly. As for the spaceship controls, the game could be set up (by the start address) to read the control input either from the operator's console using the testword switches, or from special "control boxes", which were probably the first gamepads in history.

Usage and Implementation Details

The user interface exhibits all options and controls but the testword, as well as some additional emulation settings. Control input is provided either by the keyboard (WASD and IJKL, Left + Right for hyperspace) or by gamepads, if supported by the browser. (As of writing, the Gamepad-API is supported by Google Chrome and Mozilla Firefox only. The support may vary with the individual make of the input device, putting a gamepad in direct mode may help.) Like with the original "control boxes", UP is used for hyperspace. Any major button should work for fire. Left shoulder buttons are hyperspace, right shoulder is fire. Hit the tab-key of the keyboard to swap the assignment of pads and ships.

The display is implented by a HTML5 canvas element using vector graphics for seamless scaling. The emulation should be really run in P7-phosphor mode, recreating the effects of the dual phosphor of the Type 30 Visual CRT Display. (As of writing, Apple Safari on Mac OS performs best without any-slow down at stable frame rates. We may expect other browsers to follow soon.) There are additional options (notably for the Expensive Planetarium) in order to provide a simplified view for best performance and also to inspect the actual graphics as produced by the program.

The Expensive Planetarium, the famous program-in-the-program, is implemented in two flavors: Once, as in Spacewar! 3.1 (default), using the built-in intensities of the Type 30 CRT to produce the brightnesses of the individual magnitudes of stars, and once, as originally implemented in Spacewar! 2b, varying the frequency of updates (refreshes) to provide the individual brighnesses. (In Spacewar! 3.1 the background stars are subject to a modulation by frequency, too, as the background is only refreshed every second frame. This also effects in a normally imperceptible alternation of frame rate at ca. 19/25 fps in the original program. A special option was added in the JS-implementation for a forced update at every frame in order to reduce any arising flicker. However, the JS-implementation does not attempt to reproduce any variations in frame rate and rather runs at a fixed interval.)

Recommended Reading & Links

Vienna, March 2015