1. Cited everywhere, read nowhere

Spacewar! is one of the most invoked origin software objects in the history of computing, yet as far as we can establish no one has ever published a close reading of its source code. The scholarship that exists treats the game as an event: a circulation history of how it spread from lab to lab (Monnens and Goldberg 2015), a media-philosophical account of early computer games (Pias 2002/2017), a genealogy of war and simulation (Crogan 2011), a study of its place in the cybernetic imaginary (Hong 2021), and the preservation work that placed it in the 2007 Game Canon (Lowood 2009). None of it treats the program as a text. Critical Code Studies has produced sustained readings of 10 PRINT, of ELIZA, of the Transborder Immigrant Tool; Spacewar! is the conspicuous missing origin object.

2. The retro turn, as method

Interest in historical computing has never been higher: restored machines run in museums, emulators run in browsers, and retro systems circulate as aesthetic and commodity. The Computer History Museum's restored PDP-1 plays Spacewar! for visitors; this site runs the same code in your browser. What the retro turn has lacked is interpretive method, a way of converting fascination into scholarship. We treat emulation as evidence and programming as reading: running, modifying, and porting the program so that claims about it are tested against the code artefact.

3. A machine you can know completely

Four thousand and ninety-six words of core memory, an 18-bit word, one room, one program with the whole machine to itself. Spacewar! is a limit case of the completely readable computational object: every instruction can be followed, every effect traced to its cause. That clarity is precisely what makes it the right counter-object for the present. Contemporary AI systems are constitutively resistant to this kind of reading; their behaviour lives in billions of weights rather than two thousand lines. Reading something whose workings are fully clear sharpens our account of what, in contemporary systems, resists reading, and of what is lost when computation stops being the kind of thing a single person can hold in their mind.

4. War, space, and the imaginaries written into code

The PDP-1 descends from the TX-0 and Lincoln Laboratory, and behind them the Cold-War SAGE air-defence project; the game itself compiles E. E. Smith's pulp space opera into a playable simulation of armed encounter in space, in 1962, the year of the Cuban missile crisis. The funding trail makes the point concrete. MIT's Whirlwind computer was paid for first by the Office of Naval Research and then by the US Air Force, which needed it as the prototype for SAGE, one of the largest computing projects of its era; Lincoln Laboratory was established in 1951 with Air Force money to build that air-defence system, and the TX-0 was its transistorised testbed. Digital Equipment Corporation was founded in 1957 by Lincoln Laboratory engineers, and the PDP-1 on which the game was written was given by DEC to MIT. The "free" machine time the hackers enjoyed was, in other words, the residue of air-defence money: play was subsidised by the warfare state, and the game's physics ran on hardware derived, at least in part, from weapons system. The lineage is also a surveillance lineage: the Type 30 display was derived from radar, a screen built for watching the sky, and in Spacewar! the apparatus of tracking becomes a playfield, an early reminder that the histories of play and of surveillance share their screens. The imaginary of space as combat frontier entered the machine here, and it has never left: the entanglement of space, frontier, and military money still organises technology discourse, down to the casual industry label "frontier models." Reading the code lets us examine that imaginary at the moment of its inscription. And following Nooney's archaeology of gender in videogame history (Nooney 2013), we read the founding myth itself critically: who the story of the MIT hackers makes visible, and who and what it leaves out.

5. Whose origin? Gender and the writing of game history

The history of videogames has, as Nooney argues, largely been written as a gendered timeline, a chronicle of founding fathers, hacker heroes, and game gods, and Spacewar! stands at the head of that litany (Nooney 2013). Her methodological lesson is that simply adding women on to such a history changes nothing: gender is an infrastructure that shapes who has access to which historical possibilities at a given moment, and the question to ask is not "where are the women in game history?" but "why are they there in the way that they are?" A project like ours has to take this seriously, because a close reading of Spacewar! could easily re-consecrate the very canon Nooney unsettles. We therefore read the code together with its conditions: who had access to a PDP-1 in 1962, whose bodies were at the console at two in the morning, what the Tech Model Railroad Club afforded and to whom, and how "the hackers" became historical subjects while others around the machine did not. Her counter-example is interesting: Roberta Williams designing Mystery House at a kitchen table, without code, from inside domestic labour, a site game history struggles to count. Reading the machine room closely should make the kitchen table more visible, not less, and the reading of the founding myth in this project is part of the critical reflexive approach of critical code studies.

Gender is one axis of this erasure; the record has others. Our own close reading of the versions turned up an interesting case. The most polished MIT version, 4.8 of July 1963, is signed only "dfw," initials that neither Steve Russell nor Joe Morris could place when asked in 2005; the on-screen score display that version carries is, in the surviving listings, signed by no one at all. The canon remembers Russell, Graetz, and Samson, lets "ddp" and "prs" through as initials, and drops the author of the last MIT version to three letters. Who the record preserves, and in what form, is itself part of why we need a close reading of the code and its context.

6. The first playable model, and the road to AI

Spacewar! is arguably the first widely circulated real-time simulation that people could play from within: a physics model experienced rather than observed, with gravity, torque, and playability.¹ That line runs to the present twice over. Games became AI's training grounds, with the arcade descendants of Spacewar! serving as canonical environments for reinforcement learning; and AI now presents itself as world-modelling at scale. Read alongside its companion project on ELIZA, the pairing is quite fascinating: conversation and play, the chatbot and the world model, the two original imaginaries of the thinking machine, both emerging from 1960s MIT culture, and both still structuring what we ask of AI today.

¹ Earlier graphical games existed, but as one-off installations that did not circulate: William Higinbotham's analogue Tennis for Two (Brookhaven National Laboratory, 1958), and earlier still a real-time billiards simulation, Pool, written by William Brown and Ted Lewis on the MIDSAC computer at the University of Michigan in 1954, displayed on a CRT but turn-based at the point of play (see masswerk.at). Spacewar!'s narrower and stronger claim is to be the first continuously interactive digital game to circulate widely and be rewritten across many machines.

There is a media-theoretical point here too. Spacewar! is synthetic media in the strict sense: its images, its motion, and its world are generated entirely by computation (Berry 2025). But it is human-created synthetic media, every behaviour written, every effect accountable to a line of source, where the generative media of contemporary AI is probabilistic, sampled from learned distributions rather than written by anyone. Setting the two side by side clarifies precisely what has changed in the passage from program to model.²

² There is a recursion worth marking here: Spacewar!, its history, its ideas, and its source code circulate in the corpora on which current AI systems are trained. The origin object is now inside the models we ask about it.

7. The gift before open source

Almost as soon as it ran, Spacewar! was copied: paper tape passed from PDP-1 to PDP-1, modified, extended, and given onward, until DEC shipped it with the machine. Its status was ambiguous: occasionally banned at installations such as BBN, where the constant play wore out the console switches, yet at the same time the single most important showcase for the PDP-1, so that machines eventually shipped with a copy of Spacewar! already in core. Because the magnetic core memory was persistent, the program survived shipping and was present the moment the computer was unpacked and switched on, ready for a test run, a hardware self-test that happened also to be a game, and a fitting one, since it exercised nearly every resource of the machine.³ This was an economy of the gift operating inside a Cold-War research budget, decades before "open source" had a name. The politics of this mode of circulation, and of the copyleft and open-source movements it prefigures, is examined at length in Berry's Copy, Rip, Burn: The Politics of Copyleft and Open Source (2008). The same questions return today with force in the argument between open-weight and proprietary AI models: who may inspect the artefact, who may change it, what circulation does to a technology and its culture. The 1962 case is small enough to see whole, which makes it an excellent case study for thinking the present and the disputes over ownership, control and our shared common heritage of software and computation, a heritage that initiatives such as Software Heritage now work to preserve at planetary scale.

³ On the game's ambiguous standing and its shipping in core for testing, see "PDP-1 Computer and Spacewar" at masswerk.at.

A digression: games and software as research objects

How should a sixty-year-old program be studied? Each of the fields that might claim Spacewar! constitutes it as a different object. Game studies takes the played game as its object: rules, mechanics, the experience and culture of play. Digital media and screen studies attend to the interface and the image, to what appears and circulates, a tradition given its systematic form in Manovich's The Language of New Media (Manovich 2001). Platform studies reads the affordances of particular hardware as a shaping force on creative work, the approach inaugurated by Montfort and Bogost's study of the Atari VCS (Montfort and Bogost 2009). Software studies treats software as a cultural artefact among others (Fuller 2008), while the history of computing and the preservation community treat the game as a document and a machine to be conserved. The digital humanities, as Berry and Fagerjord argue, bring computational methods and critical reflection together, insisting that the methods themselves be objects of critique rather than neutral instruments (Berry and Fagerjord 2017). Each approach provides a useful perspective, and almost all of them stop at the same place: the source code itself, cited as an origin but too often left unread. There is a further wrinkle the disciplines tend to pass over: there is no single text to read. Spacewar! is not one program but a variorum of more than a dozen versions written across 1962 and 1963, several now lost, and the differences between them, gravity added in one, an on-screen score in another, a subjective cockpit view in a third, are themselves the evidence a code reading works from.

Critical Code Studies begins from a different starting position. Its claim, set out programmatically by Marino, is that source code can be read as a text with extra-functional significance: meaning that grows out of what the code does but is not exhausted by it (Marino 2020). Close reading the source is not a rejection of the other approaches but the missing layer beneath them: the rules game studies describes are implemented in particular instructions, the images screen studies interprets are drawn by particular routines, and the platform's affordances appear in the code precisely as workarounds, tricks, and economies. There is also an older methodological ancestor here in Agre's call for a critical technical practice, a way of working that holds technical craft and critical reflexivity together in one discipline rather than splitting them between engineers and commentators (Agre 1997/2014). This is not a programme we are proposing in the abstract: it is the approach our team has already carried through for ELIZA, recovering Weizenbaum's original source from the MIT archives, reading it closely, and re-creating it as a running artefact, work published as Inventing ELIZA (Ciston, Berry, Hay, Marino, Millican, Schwarz, Shrager and Weil 2026) and discussed in "Reading ELIZA: Critical Code Studies in Action" (Berry and Marino 2024). The Spacewar! reading extends that practice from conversation to play.

Spacewar! then adds methodological challenges of its own. The code is inseparable from the machine: an 18-bit word, octal addresses, sense switches, and a display list cannot be read as if they were pseudocode, and the assembler listing has to be read with the kind of forensic attention to material inscription that Kirschenbaum brings to storage media (Kirschenbaum 2008/2012). Two examples make the point. First, the PDP-1 offers no source of randomness, so the game manufactures its own: the random macro in the source is five instructions, loading a stored word, rotating it one bit, folding it against one octal constant and adding another before storing it back, and the number it yields decides, among other things, where a ship re-enters from hyperspace. What plays as luck on the screen is a fully readable mechanism in the listing: contingency itself is programmed, and reading the routine shows exactly what the machine's chance is made of. Second, the Type 30 is a vector display rather than a raster screen. There is no frame buffer and no grid of pixels scanned line by line; the program steers the electron beam from point to point, and the image exists only as phosphor glow and constant redrawing. The picture is not a stored bitmap but something the code performs, over and over, in real time, which means the image and the program are unusually close: stop the code and the world literally fades. And because this program's output is an image, the reading must develop a visual register for critical code studies: moving between the outline compiler and the ship it draws, the star table and the sky it throws onto the phosphor, asking how procedures become pictures and what the pictures ask us to read back into the procedures. The running emulator is an instrument that can hold these two registers together, which is why it will be an important part of the work as tool and critical technical object.