Two ships share a starfield. Each has an engine, a launcher and a human pilot trying to destroy the other. While you decide what to do next, your ship keeps moving, the star keeps pulling, and your opponent is trying to get a shot into the space you’re about to occupy.
Spacewar! was doing this on the Massachusetts Institute of Technology’s (MIT) PDP-1 in 1962. It is one of the earliest video games: a moving contest on an electronic display, shaped continuously by the people at its controls. 1

Meet the two ships
Spacewar! 3.1 (MIT contributors, 1962, PDP-1), self-captured in Norbert Landsteiner's browser emulator. The Needle starts at upper right and the Wedge at lower left. Their outlines identify the ships and show their headings. The bright mark in the centre is the gravitational star; the background stars are scenery. These are emulator captures, not photographs of the original display.
What the players are trying to do
Hit the other ship with a torpedo while keeping yours intact. A collision between ships can destroy both. If both go down, neither has won that round. In this browser edition, the ships are set up again with fresh supplies after the ending delay. 9
Each pilot can turn either way, apply thrust, fire and attempt a hyperspace escape. Turning changes the ship’s heading. Thrust changes its velocity. Fire launches a torpedo when the tube is ready. Hyperspace takes the ship out of ordinary play for a time, with a dangerous return.
For the browser version used here, WASD controls the Wedge: A and D turn, S thrusts and W fires; Q requests hyperspace. IJKL controls the Needle: J and L turn, K thrusts and I fires; U requests hyperspace. These are the emulator’s keyboard assignments, not the original control-box labels. Start with version 3.1, 24 Sep 62, and the default switch settings. 7
You can begin by thinking of it as a shooting contest. Very quickly, steering becomes part of aiming, and survival becomes part of both.
Pointing, moving and changing your mind
Your ship is drifting right. Turn it to face upwards. Where does it go next?
It keeps drifting right. Facing and moving are different things. Velocity describes how fast something moves and in which direction. Turning the ship changes where its nose points; it doesn’t by itself replace the velocity it already has.
Facing and moving
First, leave gravity out. The engine is off and nothing is changing the ship's velocity. Equal distances in equal times mean a steady speed. The ship can point upwards throughout.
Now fire the engine. Thrust produces acceleration: a change in velocity over time. It adds an upward change to the rightward motion you already had. The ship starts travelling up and right. Release thrust, and that new motion carries on unless something else changes it. Acceleration can change direction as well as speed. 8
Add thrust to existing motion
The blue arrow is the old velocity. Add the orange change from a short upward burn. The green arrow is the result. These are velocity arrows, not a map of the flight path.
That’s why escaping takes more thought than pointing away from trouble. You need to change the motion you’ve already got. To brake a rightward drift, point left and thrust. Keep burning after you’ve cancelled that drift and you’ll start moving left. A button press can solve one problem and start the next.
Now put the star back. Gravity accelerates the ship towards it, so your velocity keeps changing even with the engine off. A ship already moving sideways can follow a curved course as gravity pulls it inward. The next diagram shows one small change, before the ship has moved on and the direction towards the star changes again.
Gravity changes velocity
Gravity supplies another change in velocity. The dashed orange arrow repeats that change at the tip of the old velocity so we can add them. The green result is the new velocity; it isn't an orbit prediction.
We can work with all of this as horizontal and vertical amounts. Add each change to the matching part of velocity, then use the new velocity to move the ship. That’s a small numerical model we can draw, calculate and eventually program.
In Maths for Games, Place a point introduces coordinates, and Keep fractional movement in integers shows how a stored velocity becomes a change of position on each tick. Spacewar! gives those ideas a pressing purpose: getting your ship and your shot where you want them. Gravity and changing velocity take the investigation further.
Getting a torpedo to meet a ship
Pointing at your opponent is a good way to miss. A torpedo needs time to get there, and the target can move during that time. You need to send the shot towards a future meeting point.
Your own motion complicates it. Graetz’s technical paper explains that the torpedo starts with your ship’s velocity added to its launch velocity. If you’re drifting sideways, the shot carries that sideways movement too. Turning the nose towards the target doesn’t remove it. 2

A shot crosses the duel
Spacewar! 3.1 (MIT contributors, 1962, PDP-1), self-captured in Landsteiner's emulator. Both ships have turned and fired. The bright moving points are torpedoes; the green trails are fading marks retained by the emulator's phosphor simulation, not solid beams. The screenshot shows the contest's visible information; it cannot by itself establish a projectile's velocity.
Gravity pulls at the ships but not the torpedoes. That lets a shot cross the star’s neighbourhood while a ship’s course curves under its pull. You need to judge where the two paths will meet, and your opponent can spoil the prediction by thrusting. 2
Try imagining a ship moving upwards at 30 units per second. It fires right at 50 units per second relative to itself. The torpedo moves at (50, 30), not (50, 0). To get a shot that travels directly right, the launcher has to contribute a downward component that cancels the upward 30. The moving-shot explanation works through that calculation, then lets the target move too. These are teaching values, not Spacewar’s stored units.
Enough physics for a space battle
Spacewar! borrows from physics and chooses its own rules. Graetz’s technical account describes gravity acting on ships but not torpedoes. Real gravity doesn’t make that distinction. The game does. 2
That choice changes the contest. A ship follows a course under gravity while its shot travels without that pull. You have to judge two different sorts of movement at once. The familiar idea of a space battle has become a particular set of rules to learn.
Many games work this way. They borrow motion, friction, collisions or steering from the world around us, then simplify or alter them for the experience they want. Even a physics-based game has to choose what to calculate, how often to update it and how much precision to keep. Our Maths for Games velocity experiment makes one of those compromises visible: rounding the stored numbers can turn a hit into a miss.
The diagrams here isolate the ideas so we can see them. They’re original explanations of motion, rather than captured frames or a reconstruction of the PDP-1’s calculations.
Steve Russell later recalled preferring settings that left more time for marksmanship. Once the rules are in place, their pace is another choice. How much time should a player have to read a course, line up a shot and react? 3
Supplies, delays and a risky way out
In this 3.1 configuration, each ship has 32 torpedoes. Holding fire launches them repeatedly as the tube reloads. That pause matters: you can lay down a sequence of threats, but you can’t place an unlimited wall of shots wherever you want. Torpedoes also expire, so firing from any distance is not equally useful. 9
Fuel is limited too. Burning the engine spends it; coasting preserves it. Once the fuel is gone, you can still have motion to manage, but you have lost the thrust that could change it. Planning an approach includes leaving yourself a way out.
Hyperspace offers another escape. The ship disappears from normal play, then returns at a changed position with a changed velocity. Version 3.1 includes a recharge delay and a growing risk of destruction on re-entry. It gets you out of an immediate firing line without promising a safe landing. 9
Those rules make timing and restraint part of the duel. A shot costs ammunition, a manoeuvre costs fuel, and an escape can cost the ship. The duel-design companion examines those choices and what would change if we removed their limits.
The star has a surprise of its own. With this edition’s default switches, contact sends a ship to the screen’s antipoint, at the corner boundary, and clears its velocity. The lethal-star switch changes that to destruction. Learn which rule you’re playing: the star isn’t an unconditional death trap in every version or configuration. 9
Reading the next few seconds
Imagine you have just missed a shot. Your opponent is passing below you, your ship is still travelling right, and the star is pulling you inward. Turning towards the opponent changes your heading immediately, but it hasn’t yet put your next torpedo on a useful course.
There are several things to read together. Where will the opponent be when the shot arrives? How much sideways movement will your own ship pass on to it? If you burn the engine to improve the angle, where will that leave you when the opponent fires back?
You could fire as soon as the tube is ready, making the other pilot deal with a threat. You could save the shot and keep turning. You could spend fuel to change the approach, or coast and let gravity continue changing it. Each is a different bet about the next few seconds. Hyperspace offers a way out of ordinary movement, with its own wait and danger on return.
The controls fit in a few fingers; the decision doesn’t fit in one button. Even knowing all the rules leaves plenty to judge. Your opponent can change the situation while you are deciding, and a useful manoeuvre can become an awkward one before you’ve finished it.
Once you’re at the controls, look for your own example: a moment when aiming, movement and survival asked for different things. That is where the small set of rules begins to produce a much larger game.
When a round ends
Both pilots can lose the same exchange. In the round captured below, both ships broke up and the score stayed level. In the browser, a fresh pair appeared with new supplies after the ending delay.

Both ships lost
Spacewar! 3.1 (MIT contributors, 1962, PDP-1), self-captured in Landsteiner's emulator. Both ship outlines have become bursts of points. Destruction is a visible state change, distinct from an intact ship passing out of view. This round ended without a surviving winner. The capture record also follows it through the next reset.
The original score wasn’t another number drawn beside the ships. The 3.1 program puts the results in two processor registers, whose bits could be read on the PDP-1’s console lights, and executes a halt instruction. The browser supplies its own score bar outside the game display and continues into the next round. Some later editions added on-screen score displays. 7, 9
The reset gives the players another attempt at the same problem. You can change an opening manoeuvre, wait longer before firing or conserve more fuel, then see what happens. One encounter gives you something to bring to the next.
What the computer keeps doing
Behind the moving display, the program keeps track of objects: their positions, movement and current state. A ship can be flying normally, travelling through hyperspace or exploding. A torpedo has a position, motion and remaining life. The program repeatedly reads controls, updates the objects, checks contacts and plots the display. 9
That repeating work is a game loop. It lets two people act while the world continues around them. You don’t take a turn, submit a command and wait for the other person to finish. An unpressed control is still a decision made while the ship moves.
The screen edges belong to the rules too. Coordinates wrap rather than making the edge a wall. A ship that leaves one side can return on the other; disappearing at the boundary is different from being destroyed or entering hyperspace. Watch what reappears, where it reappears and which way it is moving.
Space battles begin somewhere
Before there were ships on the screen, there were space adventures in the common room.
Writing in 1981, Martin Graetz recalled reading E. E. “Doc” Smith’s Skylark and Lensman novels with Russell and Wiitanen, watching Japanese studio Toho’s effects-heavy films in Boston cinemas, and imagining space epics of their own. Their joking “Hingham Institute” was shared accommodation in Cambridge, Massachusetts. The name makes it sound rather grander. 4
What sort of adventure were they imagining? In The Skylark of Space, scientific discovery opens the way to travel beyond Earth. Its 1928 serial credits Edward Elmer Smith in collaboration with Lee Hawkins Garby. Following the books back to their pages brings another contributor into view. 13
During a rescue in chapter X, the travellers have to slow their ship to meet another moving craft. They calculate both speeds, reverse the drive and allow time to lose velocity. Pointing the right way isn’t enough: they must deal with the motion they already have. 13
If you’ve just overshot an opponent in Spacewar!, that predicament should feel familiar. The novel turns calculation into suspense; the game makes you judge the manoeuvre yourself, with someone else trying to spoil it. This is a comparison we can make from the two works. Graetz names the novels as an influence, but that doesn’t establish this passage as the source of a particular game rule.
Nor is Spacewar! a playable adaptation of the novel. There is no chapter-by-chapter plot to follow and no requirement to know the characters. You get a ship, another pilot and a situation. The little outline in the screenshot is enough to put you inside it. Turning a story’s excitement into something a player can do is a substantial act of invention.
The film connection opens another question. Cinema can choose the angle, the cut and the instant of an explosion. A game has to keep presenting a scene while the players change what happens. Look again at the exchange of fire: the ships must remain readable while moving points compete for your attention. Spectacle and useful information have to share the display.
A game made in America can contain journeys from elsewhere. Here, part of that journey led from Japanese film studios to a Boston cinema.
Before the spaceships
Russell’s interests had already taken him through several worlds. In his 2008 interview, he traced his interest in electronics to the signals and increasingly elaborate layouts of his childhood model railway. At college he became a student technical director, then spent a summer working in theatre. He did less theatre later: “Computers were more absorbing, at the time anyway.” 3
That last qualification leaves room for a person beyond the invention we remember. Here is someone talking about things he enjoyed doing and how his attention shifted. Spacewar! was one thing he made along the way.

Steve Russell at the Computer History Museum in January 2011, decades after the original game. Photograph by vonguard, existing crop by Jonny Nixon, CC BY-SA 2.0; converted to PNG without further cropping.
Photograph source and credit · CC BY-SA 2.0.
A place to make it happen
Enthusiasm needed access to a machine. Graetz contrasts operator-mediated work on Harvard’s IBM 704 with running programs himself on MIT’s TX-0. 4
That difference gives experimentation a practical meaning. How readily can you try an idea, see its result and change it? A shared interest in space adventures doesn’t by itself provide computer time, a display, working equipment or people who can help. The room and the institution belong in the game’s history alongside the program.
The wider world could also take people away. Graetz recalled Wiitanen being called to active military duty during the Berlin crisis. That interrupted his involvement. 4
That gives the Cold War a very immediate place in this story: one of the people who conceived the game was no longer there to help develop it.
Making the battle readable
Once you’ve imagined a space battle, you still have to make it playable.
The ships need to look different enough for each player to recognise their own. Their outlines need to show which way they’re facing. Exhaust can tell us when a ship is thrusting. Graetz’s contemporary account describes these choices, along with a wonderfully awkward problem: torpedoes drawn as points can resemble the stars behind them. 2
Look at how much those small visual decisions are being asked to do. A shape helps you find your ship, read its direction and decide what to do next. Movement helps you tell a threat from the background. When attention is divided between two ships and an incoming shot, that information has to earn its place.
Try changing a ship’s outline in a sketch, or imagine removing its exhaust. What becomes harder to read? More detail might help, but which detail helps the player act?
The game in your hands
In a 2008 interview, Russell remembered controllers with quiet switches. Why did quiet matter? Because otherwise an opponent could hear you trying to fire after you’d run out of ammunition. The controls could give away your predicament. He also recalled earlier controls wearing out under heavy use. 3
Graetz recalled Kotok and Saunders building control boxes from wood, wire, Bakelite and switchboard parts around the Tech Model Railroad Club’s layout. 4 Making the game included finding parts and arranging the controls for two people at a screen.
The controller affects what each player knows, as well as what they can do. Even the sound of a switch can become part of the contest.
A switch also gives a particular kind of instruction: on or off. Hold a thrust control and the game keeps applying thrust; releasing it ends that instruction. It doesn’t mean “stop the ship”. The physics and the meaning of the control have to agree.
From a control to a change of position
Releasing the control removes thrust's contribution. Gravity can still be acting.
The wider story continues in the Vault: analogue controls, trackballs, steering wheels and light guns give games different kinds of input. For what a game does with that input, our Game Feel experiments explore movement and release behaviour. Here, the immediate lesson is in your ship: letting go of thrust doesn’t undo the motion you’ve acquired.
More hands, a better game
Russell wrote the first implementation, but the Spacewar! we remember grew through other people’s work. Graetz and Wiitanen shared in its conception; Peter Samson and Dan Edwards contributed to its development. The preserved program’s collective credit also names Alan Kotok, Steve Piner and Robert A. Saunders. 1, 7
Graetz recalled Samson’s astronomical starfield, Expensive Planetarium, and Edwards’s gravity calculations. Edwards also compiled the ship outlines once at the start of play, replacing work repeated in every display cycle. 4
It’s easy to look backwards and see a finished design waiting to be discovered. The more interesting story is people noticing an opportunity, making a change and giving one another something new to respond to.
A feature earns its keep through what it does for the experience. A handsome background might also help you judge motion. A physical switch might be comfortable but reveal information you meant to conceal. We can learn a great deal by asking what a change solved, and what new trouble it introduced.
One of the earliest video games
Spacewar! arrived early enough that even the screen needs some explanation. A game didn’t have to use a television set. An electronic display could be an oscilloscope or a computer’s cathode-ray tube, with very different machinery behind it.
In 1952, A. S. Douglas’s noughts-and-crosses program, now known as OXO, ran on Cambridge’s EDSAC. A player entered moves with a telephone dial; the machine displayed the board on a cathode-ray tube. 10
In 1958, William Higinbotham and Bob Dvorak made Tennis for Two at Brookhaven National Laboratory. Two visitors used controllers to play a ball game on an oscilloscope, with an analogue computer producing its motion. They showed it to visitors on 18 October 1958. Screen-based play and simulated movement were already taking shape before Spacewar! 11
In 1962, Spacewar! put a freely moving, two-person space duel on a programmable digital computer. Its pilots could turn, thrust and shoot while the program maintained the moving world. Its creators could change that world by changing the program. The stars, gravity, controls and hyperspace grew through different people’s contributions. 1
These examples give us a clearer history than awarding one game every “first”. Spacewar! belongs among the earliest video games, and its particular combination is worth understanding: simultaneous human opposition, movement you have to learn, rules you can change, and software that could travel to other suitable computers.
How do you share a game in 1962?
There was no home-computer cassette to take to the counter. The April 1962 Decuscope account offered symbolic and binary program tapes through Russell. Reaching another player meant reaching someone with a suitable computer and the means to run the program. The same account describes people watching as well as playing. 5
Access began well before anyone picked up a controller. The Computer History Museum’s catalogue describes a February 1963 DEC price list with a $120,000 base price for the PDP-1. That is a dated machine price, not the cost of a Spacewar package or a bill for MIT’s installation. 15
Put the offer of program tapes beside that figure. The program could travel without a retail box, but its audience still needed access to substantial equipment. Someone had to provide the machine, keep it working and allow people to spend time at it. Distributing a program and making it accessible are different parts of the task.
The emulator changes that starting point. We can open a browser where the original players needed access to a particular kind of computer. We gain a route into the game, while encountering different keys, display behaviour and timing. It is easier to reach the rules than to recreate the room around them.
A retail game’s box has to attract a buyer and promise an experience. Spacewar! could put an experience in front of an audience directly. The museum describes it being used to demonstrate the PDP-1 to prospective customers. Here was something a visitor could watch happening, with human decisions producing visible results. 1
The influence also reached coin-operated games. The Computer History Museum traces Nolan Bushnell and Ted Dabney’s 1971 Computer Space to Spacewar! and other early space-battle games. That required a different technical and commercial form: an arcade game for people who didn’t have access to a research computer. 12
Ten years later, Stewart Brand’s Rolling Stone report took readers into organised Spacewar play at Stanford, with spectators and competition around a PDP-10 variant. This was a later game scene on a different machine, with different match arrangements. The activity had continued to develop around the program. 6
Brand noticed anti-Vietnam-War posters and door labels in Tolkien’s Elvish script. 6 The room had its own mixture of work, play, politics and shared reading. Another group had made a setting of its own for playing the game.
Stanford’s report on its first ten years of artificial intelligence research acknowledged support from the US Department of Defense. 14 Set that beside Brand’s description of anti-war posters. Funding and the views displayed by people in a workplace are different parts of its history.
The move from MIT to later Stanford play gives us a small journey to follow. Who could use the machine? Who could change the program? Who brought other people in? Those answers help explain the game that a particular group encountered.
A decade after its creation, people were still finding reasons to play, change and compete at Spacewar! A game first shared on program tapes had become an activity people organised around.
Spacewar comes home
A space duel could eventually reach a home through a purchased disk as well as a shared program tape. Bill Budge’s Space War for the Apple II appeared in California Pacific’s Trilogy, alongside Night Driver and Pinball. A contemporary player described its two-person battles and complained that gravity affected one ship more strongly than the other. That’s a useful reason to investigate this version on its own terms. 16, 17
Star Control took the duel into a game of different ships and a wider strategic contest. Its creators identify the arcade Space Wars as an influence: the route from the PDP-1 game to a home computer could pass through an arcade cabinet. 18, 19
Those versions deserve their own close attention. Their Vault entries follow the changes, rather than treating every space duel as the same game on a smaller machine. What did a version keep, what did it change, and what new decisions did that give its players?
Take the controls
You can explore Spacewar! in Norbert Landsteiner’s browser emulator. For this study, we’ve selected the edition labelled Spacewar! 3.1, 24 Sep 62. The page supplies controls and several other versions. Start with the named edition and leave its options unchanged while getting acquainted. 7
Versions matter here because the game kept changing. For example, Graetz’s early technical paper describes three hyperspace jumps and being transported after capture by the star. We shouldn’t carry those rules unexamined into every later edition. The browser’s display and keyboard arrangement also give us a different encounter from standing at a PDP-1. 2, 7
Find someone to explore it with if you can. Give yourselves permission to spend a while learning to move before trying to win. Turn without thrusting, then thrust and release. What can you control immediately? What have you set in motion that you now need to live with?
Once you’re exchanging shots, look for a moment worth talking about. Perhaps you missed an apparently easy target, escaped by accident or noticed what the other player was about to do. Compare accounts. The same encounter can look very different from the other set of controls.
Then return to the game as a designer. Which choice would you change? Would you make the ships easier to steer, give people more time to aim, or make an incoming shot easier to recognise? What would your change give the players, and what might they lose?
Those are questions we can take into our own work. Spacewar! gives us a small enough world to examine closely and enough happening inside it to keep us arguing. Put two people at the controls and there’s still something to discover.
Sources
-
Steve Russell interviewed by Al Kossow, 9 August 2008, pp. 4, 6–7 and 14–16
-
Edwards and Graetz: “PDP-1 Plays at Spacewar,” April 1962; transcription
-
Norbert Landsteiner: Spacewar! browser emulator and version documentation
-
Spacewar! 3.1 source listing: parameters
tno,rlt,tlf,foo; object tables; torpedo, hyperspace and star-contact routines. Capture configuration, tape identity and observed results are recorded in the accompanying research notes. -
Cambridge’s EDSAC example-program collection and Computer History Museum, 1952: OXO.
-
Edward Elmer Smith in collaboration with Lee Hawkins Garby: The Skylark of Space, 1928 serial text, title credit and chapter X, “The Rescue”. This transcription does not establish which edition the Spacewar creators read.
-
Stanford Artificial Intelligence Laboratory: The First Ten Years of Artificial Intelligence Research at Stanford, AIM-228, dated July 1973, title and abstract; archived PUB source. The title also carries report number STAN-CS-74-409.
-
Computer History Museum: DEC PDP-1 price list, dated 1 February 1963, accession 102652408, catalogue description. The base-price figure follows the museum’s catalogue summary.
-
California Pacific: other titles advertisement, included with the original Ultima manual, “Bill Budge’s Trilogy”.
-
Michael Decker: “Unlocking Bill Budge’s Trilogy”, Hardcore Computist no. 5, p. 13. The unequal-gravity statement is his report, not our measurement.
This study has not yet been fact-checked. Sources and capture conditions are included so you can follow the evidence.
Game captures: Spacewar!, MIT contributors, 1962, PDP-1; captured in Norbert Landsteiner's emulator. Full credits and capture conditions. Original illustration is separate from the historical game imagery.
