Spacewar on the MIT Lisp Machine

Released System 46 path

The public loader lmio1/load.swar declares the SPACEWAR package, loads lmio1;swar and lmfont;ship, prints the form used to stop the game, and calls SPACEWAR:SPACEWAR. A contemporary INFO-LISPM record gives the compact user route:

(load "lmio1;load swar")

The released implementation creates a process and global roving blinkers. It does not define the later SPACEWAR-WINDOW, introductory Listener, or System W entry.

Maintained System 303 path

System 87 release notes instead say to load SYS:IO1;SWAR and call the entry point:

(spacewar:spacewar)

SPACEWAR presets and enables the reusable Spacewar process. INIT loads SYS:FONTS;SHIP QFASL if necessary, creates and selects a square SPACEWAR-WINDOW, explains the controls, and waits until any Control, Meta, Super, or Hyper modifier is depressed. It then clears the explanatory display, creates the sun and both ships, and enters the simulation loop.

The maintained implementation registers System key W with the label Spacewar!. This selects or creates the Spacewar window through the ordinary TV system-key registry. The three explicit lifecycle operations are:

FREEZE and RESUME are additions in the maintained source; the System 46 version supplies only start and stop. Neither version has a score table, single player mode, network mode, save file, or independent settings dialog in the inspected source.

Clock and coordinate system

The maintained game requests ten cycles per second (CPS = 10) and uses 1,000 internal position units per display dot (UPD = 1000). Each cycle:

1. waits until the next scheduled time;
2. waits if the Spacewar window is not exposed;
3. decodes held controls;
4. returns any ships whose hyperspace delay has expired;
5. expires old torpedoes and checks the end condition;
6. detects collisions;
7. moves, accelerates, and rotates objects; and
8. applies gravity.

The order matters. A held control alters acceleration or angular velocity before movement physics later in the same cycle; gravity is applied after the position update and therefore affects subsequent movement. This ordering is an implementation finding not stated on the introductory screen.

The maintained window chooses its inside size from the smaller screen dimension minus 20 dots. The playable minimum is five dots inside each edge and the maximum is six dots short of the computed size. System 46 instead hard-codes a much larger coordinate rectangle, with maxima of 1,377 by 1,530 dots, and renders through global roving blinkers rather than a dedicated square window.

Objects and sprite glyphs

Each sun, ship, or torpedo is an OBJECT array structure. Its fields include type, sprite base character, collision radius symbol, position and velocity, acceleration, orientation and angular velocity, unit-vector projections, collision function, immovability, ammunition and fuel, last-fire and last-hyperspace cycles, blinker, and death state.

The rendering is deliberately small:

• a ship is a TV:CHARACTER-BLINKER whose character changes among 32 consecutive glyphs as its angle changes;
• a torpedo is another character blinker using the first sprite character;
• the sun uses the next sprite character and is marked immovable; and
• object motion changes the blinker's cursor position after rounding internal coordinates to display dots.

This design makes the font part of the executable visual logic. Removing or replacing FONTS:SHIP does not merely change typography; it removes the shapes that communicate object type and direction. The broader sprite-font evidence is cataloged in the CADR visual-assets inventory and font-usage audit.

Motion and the playfield edge

With the default WALL-BOUNCE = NIL, an object crossing an edge reappears at the opposite edge. Setting it true reflects both position and the corresponding velocity component; the loop permits repeated reflection when one cycle would cross more than one boundary.

The collision detector sorts all objects by horizontal position, then stops comparing once later objects are too far away. This normally reduces the work from all-pairs quadratic scanning toward a linear pass. The source explicitly retains a left-edge exception in the stopping test because wraparound can put an object near the left edge in collision range of one near the right edge. The optimization is thus aware of the topology rather than treating screen coordinates as an ordinary bounded plane.

The effective collision threshold is the greater of the two objects' summed radii and TORP-TORP-COLLISION-DISTANCE. The latter is intentionally larger than two torpedo radii, making defensive torpedo-to-torpedo interception easier. The same minimum applies to any pair whose radii sum to less than it, a broader effect noted in the source comment.

Sun and gravity

The sun is stationary and does not itself take collision damage. Every movable object receives an acceleration directed toward each sun, scaled by the inverse of the squared distance. The default collision policy is :CORNER: contact sets an object's velocity to zero and moves it to the minimum horizontal and vertical coordinates. Setting the policy to true instead invokes the object's ordinary collision function; setting it to another value, including NIL, leaves no source-defined collision effect.

Torpedoes, death, and the end of a game

A fired torpedo begins just beyond the firing ship's and torpedo's combined radii. Its velocity is the ship's current velocity plus a forward component, so it inherits the motion of its launcher. Firing decrements the ship's supply and records the current cycle. Each torpedo becomes eligible for removal after its lifetime, and collided or expired torpedo objects are kept on a free list for reuse rather than repeatedly allocated.

A ship collision stops its acceleration and rotation, makes its blinker flash, and sounds a ship-specific death tone—1,000 for FOO, 2,000 for BAR—for the same fixed duration. It also schedules the game to end after the death delay.

If no ship has fuel or torpedoes and no fired torpedo remains on screen, the game beeps and schedules the same delayed ending. SPACEWAR-TOP-LEVEL then starts a new game rather than terminating the process. The inspected implementation does not record a winner, count kills, or preserve results across that restart.

Hyperspace

Hyperspace removes the ship from the active-object list and hides its blinker. After the delay, the ship returns at a random position, with a random orientation and a fixed-magnitude velocity in a random direction. It has a 12 percent chance of immediately invoking its death function. The reload timer is recorded on return, so the source-defined delay between entries is measured from reappearance, not departure.

Reproduced route

Session spacewar-d55-20260718, generation 1, booted the repository's fresh System 303-0 disk under Xvfb. The local Chaos host was LOCAL-BRIDGE; the FILE server root exposed the public System tree as tree. Ordinary MAKE-PATHNAME components are canonicalized to uppercase, which does not identify the lowercase Unix files reliably. The successful route therefore used raw components:

(load (fs:make-pathname
        :host "LOCAL-BRIDGE"
        :raw-directory '("tree" "io1")
        :raw-name "swar"
        :raw-type "lisp"))

(load (fs:make-pathname
        :host "LOCAL-BRIDGE"
        :raw-directory '("tree" "fonts")
        :raw-name "ship"
        :raw-type "qfasl"))

The source reported that it loaded into package SPACEWAR; the font reported package FONTS. Calling SPACEWAR:INIT synchronously selected the real window and displayed its own introduction. A held left Control key satisfied the source-defined start predicate. The live playfield then showed both opposed ship glyphs and the central sun. The runtime did not contact an external peer, alter the public source trees, or write the base disk.

The initial attempt to call the asynchronous SPACEWAR entry from inside an unrelated nested Listener debugger left the background process unable to claim its display cleanly. That was harness setup noise, not a game defect. Returning to the Listener top level and invoking INIT produced the expected window. The article's behavioral claims rely on that successful state and the source, not on the failed exploratory screens.

Capture and session identity