Spacewar!: The Ship Remembers Its Momentum

Turn a spaceship around and it ought to face the other way. Whether it should immediately travel the other way is a separate question.

A game that preserves momentum makes the distinction matter. You can point toward an opponent while drifting sideways, or fire the engine against your motion and discover that slowing down takes time. The universe declines to treat the direction button as a formal cancellation of everything you did previously.

Spacewar! made that sort of moving, controllable world an early computer game. The interesting engineering begins with the information carried from one moment to the next.

A game assembled during 1962

J. Martin Graetz’s 1981 creator account traces the concept to Steve Russell, Graetz and Wayne Wiitanen. Russell’s controllable dot appeared in January 1962; a barebones two-ship game followed in February, with the game essentially complete by late April. The May open house brought scoring. Other contributors included Alan Kotok, Robert Saunders, Peter Samson and Dan Edwards.¹

That chronology matters. A moving dot, a playable early game and a more developed demonstration are separate milestones. Treating February as the release of every familiar feature would compress the actual work into an unusually productive announcement.

The article’s calculations below are original teaching models. They explain motion and display responsibilities without claiming to execute the first build or reproduce its numerical conventions.

Keep position and velocity separate

For a deliberately small example, place a ship on a line at position zero. Give it initial velocity zero. At each step, first update velocity using acceleration, then update position using the new velocity. Each step lasts one chosen unit.

Choose acceleration two for the first two steps:

Step        Acceleration    New velocity    New position
1                2               2               2
2                2               4               6

The second position is six because the ship starts that step at two and moves another four. Writing position four would confuse the total location with the most recent displacement.

Now release the engine for a step. Acceleration becomes zero, velocity remains four, and position becomes ten. Coasting still moves the ship.

Finally choose acceleration minus two. Velocity falls from four to two, and position increases from ten to twelve. Counter-thrust slowed the forward motion; it hasn’t yet reversed it.

A second counter-thrust step takes velocity to zero, leaving position twelve. A third produces velocity minus two and position ten. Several commands are needed to undo accumulated motion.

These chosen values are checked in the companion program. They aren’t a Spacewar! fuel table, a recovered timestep or a claim about actual machine precision.

Original explanatory SVG, created in 2026. Arbitrary positions, velocities and update intervals; no historical game code or screenshot reproduced.

Facing is another field

Add an angle to the ship’s state. Position says where it is; velocity says how it is moving; angle says where its nose points.

In our chosen model, rotating the ship without firing changes only its angle. Its existing velocity remains. Fire afterward and the new acceleration follows the new direction, combining with the velocity already present.

Suppose a ship moves right at four units per interval. Rotate it upward and apply an upward acceleration of two for one interval. The resulting velocity is four right and two up. It travels diagonally, even though its nose faces straight up.

This is a useful source of skill because the player has to plan around stored motion. A control can be perfectly responsive while the physical consequence remains gradual.

Graetz describes acceleration and counter-thrust, rotated outlines and later gravity. He also notes that the actual central star wasn’t wholly Newtonian.¹ Consequently, an idealized physics calculation shouldn’t be quietly presented as an audit of the original game’s accuracy.

A game can make consistent choices for play without serving as a laboratory instrument. The important question for our example is whether its own stated choices are applied consistently.

Draw an outline in its own coordinates

A ship shape doesn’t need a separate stored drawing for every location. Define points relative to the ship’s center, rotate them by its angle, then add its position.

For an original triangular outline, choose three local points: nose (2, 0), upper tail (-1, 1) and lower tail (-1, -1). These are invented coordinates, not the historical needle or wedge shape.

A quarter turn counterclockwise maps each point (x, y) to (-y, x). The nose becomes (0, 2). The tail points become (-1, -1) and (1, -1).

Place the ship’s center at (5, 7) by adding five to each x coordinate and seven to each y coordinate. The displayed points become (5, 9), (4, 6) and (6, 6).

The shape has moved and rotated, while its dimensions stay the same. The squared distance from nose to either tail is ten before and after rotation. The companion checker verifies those lengths and the final coordinates.

For general angles, sine and cosine supply the two-dimensional rotation. The quarter-turn example uses exact integers so we can inspect the transformation without rounding distracting from the idea.

Original explanatory SVG, created in 2026. Chosen triangle and coordinates demonstrate a transformation; they don’t reproduce the original game’s outline encoding.

Movement and appearance therefore share a position but needn’t share an orientation of travel. Rotating the display points doesn’t itself change the stored velocity. Combining those operations accidentally would make the renderer decide the physics.

Choose an update rule explicitly

Our motion model updates velocity before position. Another possible model updates position using the old velocity, then changes velocity. Both can be written with small formulas, but they produce different discrete results.

Start at position zero and velocity zero with constant acceleration two. One full step under our chosen rule reaches position two and velocity two. Under the old-velocity rule, the same first step reaches position zero and velocity two.

Neither is the exact continuously accelerated result at time one, which would be position one. A discrete simulation approximates change in finite steps. The chosen step size is part of its behavior.

Split our one interval into two half-steps. After the first, velocity is one and position is one-half. After the second, velocity is two and position is one-and-a-half. Split it into four quarter-steps and final position becomes one-and-a-quarter, while final velocity remains two.

The checker uses exact fractions for these values. Reducing the step size moves this simple constant-acceleration example closer to the continuous result. It also requires more updates over the same duration.

This calculation is a teaching comparison of integration rules, not evidence that Spacewar! used our rule or those particular intervals.

A small gravity example, with a clear boundary

For a separate idealized example, put a star at the origin and a ship at (4, 0). Choose a gravitational parameter of sixteen. Under an inverse-square attraction, the acceleration magnitude is sixteen divided by four squared: one, directed left.

Give the ship velocity (0, 2) and choose a quarter-unit step. Updating velocity first gives (-0.25, 2). Updating position with that velocity gives (3.9375, 0.5).

The ship moves upward while bending toward the center. Position determines the attraction direction; the existing velocity determines the part of its movement that continues alongside that attraction.

The next step must calculate attraction from the new position. Reusing the original leftward acceleration forever would turn a central field into a fixed push. Our checker verifies the first-step values and that the next acceleration has a downward component as well as a leftward one.

The model excludes a collision with the star and refuses the singular case of distance zero. A complete game would need a deliberate policy for that event. Dividing by zero is a poor explosion effect.

Again, this is explicitly Newtonian teaching arithmetic, not a recovered rule for the original central star.

A world has to be updated and shown

Our conceptual loop has three responsibilities: read the current controls, advance the stored world according to defined rules, then derive the visible outlines from the updated state.

Keeping those responsibilities explicit makes errors easier to identify. A ship can have correct motion and a wrong display transformation. It can also have a beautiful outline while its saved velocity gets reset every frame.

Graetz recalls that adding gravity strained the display budget, and Edwards accelerated outline generation.¹ The broad engineering tradeoff is easy to reproduce conceptually: more work inside each update can reduce how often the result is shown.

Take a wholly invented display budget of one hundred work units per frame. If motion costs twenty, controls five and drawing seventy, the total is ninety-five. Add fifteen units of extra simulation and the total becomes one hundred ten. Something has to change if the same budget is to hold.

Reducing repeated drawing work by twenty brings the total to ninety. This arithmetic doesn’t estimate PDP-1 speed. It simply makes visible why a feature and an optimization can be linked: the feature consumes room the optimization restores.

The command meets the next state

I find Spacewar!‘s persistent motion more interesting than a claim about which game deserves a universal first-place medal. A command becomes one contribution to a world already in progress.

Our checked examples separate position, velocity, orientation, update interval and display coordinates. Each field has a job. Preserving those distinctions produces coasting, gradual braking and a shape that can face somewhere other than its direction of travel.

The ship remembers its momentum. The player has to remember it too.

Footnotes

1. J. Martin Graetz, “The Origin of Spacewar”, Creative Computing, August 1981. Creator recollection used for development milestones, contributions, motion/display observations and the central star’s numerical caveat. All worked coordinates, update rules and budgets here are original models. ↩ ↩² ↩³