Inside Spacewar!
Part 10: Spacewar 4.4 — A Twofold Stand
World's First Attempt at a (Planar) Multiplayer First-Person Shooter Game
(Introduction · The Listing · The Code · Intensification; The Dark Side of Spacewar! · Ptolemy Fixed · Fixing Spacewar! 4.4 · Planar First-Person (Multiplayer) Shooter Games? [Media Theory])
Preliminary Remarks / Update
Some years after writing this, Monty Preonas, the main author of this very special version of Spacewar, provided further insight into this program and how it came to be. Notably, Monty Preonas here refers to the game as "version 4.3", while the assorted listings, this reconstruction is based on, contains an intermediate version dubbed "4.3", which optionally displays a single ship at a subjective, central perspective at the a single screen, and a more elaborate version "4.4", as the game is here referred to in this context. Anyway, here's Monty Preonas' description:
Version 4.3 was developed when for about a period of 3 or 4 months a new oscilloscope compatible with the PDP-1 was available in the computer lab. At first, we used this scope as the second pilots console so combatants weren't bumping into each other even though they had separate hand-held consoles. Then I decided to start Version 4.3 to provide a pilots view from each cockpit. This was accomplished by having every other frame go to the opposing console so that both the "thin" and "fat" pilot"s ships were stationary in the center of the frame. It worked very well, except we wound up with a double "twin" star because of the every other frame issue. We ran out of time and had too much fun learning how to play this more difficult version to correct the twin-star problem before we no longer had access to the oscilloscope.
(Monty Preonas, personal email message.)
The annotated listing of this game was eventually donated to the New Mexico Museum of Natural History & Science in Albuquerque and nothing more is known about this. But it is important to note that this was, apart from the rather cosmetic "twin star" problem (see below), a fully functional game.
Therefore, the listing referred to here reflects rather a work in progress, which also sadly lacks any of the aforementioned annotations. Having said that, here's the unaltered article, as of when the reconstruction of that game had been attempted.
*****
There is still one listing of Spacewar! left that we haven't explored so far, and there's some reason for this as it is also the most enigmatic and arcane of all Spacewar!-code. But, provided with the knowledge gained from our previous excursions, we're now ready to risk a closer look. And this closer inspection will be rewarded in quite an unexpected manner, since Spacewar! 4.4 proves to be the first attempt at a multiplayer first person shooter game, predating any other example of the genere by a full decade.
But, before we may want to celebrate the discovery, we'll have to state that the term first-person schooter (FPS) applies to Spacewar! 4.4 only with some restrictions: What we'll discover, is not a pseudo-3D view, like the scene would be perceived while viewing it through the windshield of a spaceship's cockpit, it's still an abstract God's eye view, providing individual Ptolemaic perspectives that are mapping any objcets relative to a player's position. It conveys the scene as it would be seen on an onboard radar scope inside a player's spaceship. And, as the circular tubes of the DEC displays were originally designed for the use with PPI (plan position indicator) scan radar displays, it won't become more realistic than that.
We may argue that this kind of vision is consistent with the planar, toroidal 2D-universe of Spacewar!, where any true first-person projection would be just in 1D, like in Edwin A. Abbott's Flatland, and it is thus as close as we can get in regard to a first-person view in a symbolic, map-like representation. I am suggesting the term "Planar FPS" for this, an alternative, but more unwieldy term would be "Ptolemaic multiplayer shooter game".
Being aware of this being potentially controversial, we will discuss the applicability of the term "FPS" in greater detail at the end of this article.
Spacewar! 4.4, first multiplayer game to feature subjective views, May 1963.
Montage and screen-shot mockups: Norbert Landsteiner, 2015;
Reconstructed control boxes by Tom Tilley, 2015; PDP-1 images via CHM.
The Listing
In Spacewar! 4.4, we finally meet a point in Spacewar's history, where the "hackers" truely "took over" (compare a widely used shorthand for Steven Levy's account of the origins of Spacewar! in "Hackers — Heroes of the Computer Revolution; New York 1984), since this is no more the Spacewar! as it was originally conceived by Steve Russell et al, but clearly transcends the original vision by adding a substantially new quality to it. The hackers in question being Monty Preonas ("ddp") and Joe Morris.
The code of Spacewar! 4.4 is included in a PDF-formatted bundle of assorted listings that goes by the name "spacewar_Ver4.X" or "stars by prs" (after the first of its pages), to be found at bitsavers.org, at the Computer History Museum's web site, or at archive.org. The listing is dated and signed "5/17/63 ddp" (part 1) and "5/21/63 ddp" (part 2) and has probably been edited by Joe Morris, as we're informed by the following note, which is apparently describing these assorted listings:
Late-breaking news: I found the listing binder in my office. The
versions I've got are:
4.0, dated 2/2/63
4.2, dated 5/11/63 (with a torn scrap of greenbar where I
scribbled notes about which buttons set which bits on
the taper pin block (for the IOT instruction) from the
drone controller someone bought from Eli's to run
Spacewar on the PDP-1 on the first floor of building 20)
4.3, dated 5/17/63
4.4, dated 5/17/63 which still shows Monte's[sic] initials (ddp) but
which vague memory says wasn't his update. It may have
been my hack, but I hadn't yet learned the tao of marking
changed lines in programs 8-(
(Joe Morris, alt.sys.pdp10, Jannuary 6, 2005)
With the date of the first part of the listing being the same as that of version 4.3 on which Spacewar! 4.4 evolves and the date of the second part being just 4 days later, but both parts iterated to version number 4.4, it's hard to ascribe any lines of code ditinctively to Monty Preonas or Joe Morris. But we may assume that most, if not all, of the changes applied to first part may have been by Joe Morris, because Monty Preonas would have probably adjusted the date, as we see it in part 2.
However, version 4.4 builds on the erratic "Twin Star Mode" of Spacewar! 4.3 which we've already discussed in Part 9. It not only asserts all our previously made assumptions of this being meant as a special Ptolemaic view relative to the first of the spaceships, it takes this a radical step further by not only providing this view for both of the ships, but by making what had just been an experimental option now the only mode of the game.
As a preliminary note, we've to state that Spacewar! 4.4 is not a perfectly working game. While it fixes most of the issues that we observed with the "Twin Star Mode" of version 4.3, it also introduces a few of its own. But there are still 3 consecutive versions of Spacewar!, namely 4.5, 4.6, and 4.7, which are unknown or lost. While we may never definitely know, there might have been a perfectly working version eventually. (One of the missing versions was probably of the dfw-strain and featuring dual speed controls, as may be infered from a left-over comment in version 4.8, but this still leaves two possible candidates for a perfect version). However, the intentions of the code are out of question and the two or three issues are easily fixed, allowing us to experience the game as intended.
BTW: ▶ You can play Spacewar! 4.4 here (both fixed and original) running in an emulation.
As another preliminary note, we may observe that version 4.4 reverts the code for reading the control input from the use of the enigmaticly scrambled mode of the "iot 111" instruction (probably related to Bomarc joystick used for input) to the common practice of reading the inputs by the "iot 11" command. But, it does so by introducing an additional shift to the right, as it is later seen in version 4.8, too, thus indicating another change to the way the control boxes were wired up to the PDP-1. While we will ignore any changes related to this in the further discussion, here is the setup used for the control input:
mg1, dap mg3 // deposit return address (currently in AC) cli // clear IO register iot 11 // read input from taper pin block into IO rir 4s // additional rotion of IO by 4 bits to the right mg3, jmp . // return
Which accounts for the following scheme of connections:
bits (IO): 0 1 2' 3 4 5' 6 7 8' 9 10 11'12 13 14'15 16 17 usage: -PLAYER 2- -PLAYER 1- semantics: L R T F L R T F | | | | HYPERSPACE HYPERSPACE L: Left (counter-clockwise turn), R: Right (clockwise turn), T: Thrust, F: Fire.
That said, we want to rewind and have a fresh look at the code as unprejudiced as possible.
The Code
Deviating from our usual praxis, we're presenting the code rather in a diff than as consecutive lines of codes. This seems a bit more suitable here, since Spacewar 4.4 is a variant of Spacewar 4.3 which is in turn a variation of Spacewar 4.2. Therefor we are rather presenting the changes applied to the code the respective program is based on in order to provide some of this context.
We're ignoring any changes applied to the reading of the control input using the "iot 111" instructions in Spacewar! 4.3 which were probably related to the use of the joystick from the Bomarc missile control console panel (related to as drone controller by Joe Morris in the note reproduced above) and were revoked in version 4.4.
A single dash (-) indicates that there is no instruction in the respective version, while there had been an instruction in the previous version. Where there are just empty lines in the previous version, new instructions have been introduced in the later version. Where there are instructions both in a previous version and in the respective later version, instructions have been substituted for new code. Three dots (...) denote an ellipsis and are not part of the code.
Here are the incremental differences between version 4.2 (classic Spacewar!), version 4.3 (optional Twin Star Mode with sense switch 2 — intended as a subjective Needle's View), and Spacewar! 4.4:
Spacewar! 4.2 Spacewar! 4.3 Spacewar! 4.4 (diff to 4.2) (diff to 4.2 and 4.3) define dispt A,Y,B repeat 6, B=B+B lio Y szs 20 - jda kcb jda kcb dpy-A+B xct db1 term /outline compiler /puts in swap ocs, dap ocz ocs, dap ocz dio i oc dio i oc idx oc idx oc dio i oc - idx oc - ocz, jmp . ... och, cla rcl 3s dio \oci lio (rcl 9s lio (swp swp=opr 60 dispatch ... oce, dac i oc idx oc jsp ocs plinst (ioh lac (dpy-4000 lac (xct db2 /display gravitational star define starp add \bx swap add \by swap ioh dpy-4000 xct db2 terminate bpt, dap bpx random sar 9s sar 6s spa cma sal 3s add (bds dap bjm cla cli clf 6-opr-opr clf 6 bjl, cla cli-opr szf i 20 szf 4 jmp bjm-1 jmp bjq sub ny1 sub ny1 1 swap swp sub nx1 sub nx1 1 jmp bjm-1 bjq, sub ny1 swp sub nx1 dpy-4000 xct db2 bjm, jmp . bds, repeat 10, starp szf 6 bpx, jmp . stf 6 stf 6 cma lac \bx swap cma cma lac \by // illegible swap cma // illegible jmp bjm dac \by // illegible jmp bjl /background display define dislis J, Q ... fyn, lio /lio Y szs 20 - jda kcb jda kcb dpy-i xct db1 ... terminate // (start of frame, just after initialization of the objects table and pointers) 4 szf 4 jmp . 4 law dj6 stf 4 jmp . 3 law dj5 clf 4 dap . 1 lac . dac db1 idx .-2 xct .-3 dac db2 // (continued following to the code at label mdn) db1, 0 db2, 0 dj5, dpy-i dpy-4000 dj6, dpy-i 400 dpy-4000 400 / explosion ... mi1, hlt add i my1 swap add i mx1 szs 20 - jda kcb jda kcb dpy-i 300 xct db1 count \mxc, mz1 count i ma1, mb1 dzm i ml1 jmp mb1 /relocate for center display kcb, 0 kcb, 0 dap kc1 dap kc1 swap lac kcb sub ny1 szf 4 swap jmp . 6 lac kcb sub nx1 1 sub nx1 swap kc1, jmp . sub ny1 1 jmp kc1 sub nx1 swap sub ny1 swap kc1, jmp . / spaceship calc / switch 2 for light star ... ... undosft undosft scr 9s scr 9s scr 6s scr 8s szs i 20 - scr 2s - sza sza jmp bsg jmp bsg ... ... ... scale \sn, 5s, \ssn scale \cs, 5s, \scn lac i mx1 szs 20 szf 4 sub nx1 sub nx1 szf i 4 sub nx1 1 sub \ssn dac \sx1 sub \ssn dac \stx lac i my1 szs 20 szf 4 sub ny1 sub ny1 szf i 4 sub ny1 1 add \scn dac \sy1 add \scn dac \sty ... cla cli-opr szs 20 - jda kcb jda kcb dpy-4000 xct db2 ... st2, yincr \sx1, \sy1, sub dispt i, \sy1 lio \sy1 xct db1 ... / set up torpedo calc sr2, lac (tcr dac i sr1 law nob add sr1 dap ss3 lio \stx swp szf 4 add nx1 szf i 4 add nx1 1 swp ss3, dio . add (nob dap ss4 lio \sty swp szf 4 add ny1 szf i 4 add ny1 1 swp ... / score display routine fds, szf 3 /display spaceship law not szf i 3 law not 1 dap fug idx t5 ral 9s cli dpy-4000+700 xct db2 isp t3 ... fub, ... cli iot 11 dio \t1 law 21 xor \t1 sza i jmp fik law 42 xor \t1 sza jmp fis jmp fkg law a4+1 law a4+1 dap fiu jmp fwt-1 jmp fwt - fik, law 4 dap fiu fwt, add . dac \t1 isp \t1 jmp .-1 fiu, jmp . fkg, szf 3 jmp fis szf 4 jmp . 4 law dj6 stf 4 jmp . 3 law dj5 clf 4 dap . 1 lac . dac db1 idx .-2 xct .-3 dac db2 jmp fis
(For the basics of PDP-1 instructions and Macro assembler code, please refer to Part 1 or bring up the instruction list available at the tab at the bottom of the page. As usual, any comments starting with double slashes are mine and not in the original code.)
Intensification — The Dark Side of Spacewar!
Or, Yet a Discovery
The very heart of Spacewar! 4.4 is the new block of code added just after the inizialisation of the various pointers to the properties of the first object (spaceship 1) at label "ml0", the very piece of code that is visted at the beginning of each frame of Spacewar!:
spacewar 4.4 5/21/63 ddp ; pt 2 /main control routine for spaceships nob=30 /total number of colliding objects ml0, setup \mtc, 5000 /delay for loop init ml1, mtb /loc of calc routines add (nob dap mx1 / x nx1=mtb nob add (nob dap my1 / y ny1=nx1 nob ... nnn=nh4 2 // new code starts here 4 szf 4 // flag 4 zero? jmp . 4 // no, skip next 4 instructions law dj6 // flag 4 zero, load address of label dj6 ("dpy-i 400") stf 4 // set flag 4 jmp . 3 // skip next 3 law dj5 // flag 4 set, load address of label dj5 ("dpy-i") clf 4 // clear flag 4 dap . 1 // set up loaded address in db1 lac . dac db1 // contents of db1 is either "dpy-i 400" or "dpy-i" idx .-2 // set up address of next instruction in db2 xct .-3 dac db2 // contents of db2 is either "dpy-4000 400" or "dpy-4000" // after code at label mdn db1, 0 db2, 0 dj5, dpy-i dpy-4000 dj6, dpy-i 400 dpy-4000 400
At label 4, visted at the beginning of each frame, the state of program flag 4 is toggled (previously unused, because it is also set by the system to indicate that a key of the console writer was pressed), and, depending on its state, either the two instructions "dpy-i" and "dpy-4000" will be set up in locations db1 and db2 or the instructions "dpy-i 400" and "dpy-4000 400" respectively. Subsequently anwhere in the code where there had been a display instruction dpy, these are replaced by an xct instruction that will either execute the instrcution set up at label db1 for all display commands that do not request a completion pulse from the display or the one at label db2 for those display commands that do so.
We me note that the only difference between these two display modes is the addition of the value 400, accounting for the display intensity (brightness) encoded in bits 9..11 (MSBF-order). Therefor, there will be alternating frames with either flag 4 unset an displaying at the default intensity of zero and frames where flag 4 is set and any dots are displayed at intensity 4.
First, we may ask, if this wouldn't slow down the game exessively, since this remote execution is adding another 5 microseconds to any display command. But there is a compensation for this, namely the change applied to the outline compiler, where the two "rcl 9s" instructions (rotate AC and IO as a combined 36-bit register by 9 bit positions to the left) executing in 10 microseconds and used to swap the contents of AC and IO prior to any display command are substituted by the single instruction swp (instruction code 760060) that was a newly upgraded option and accomplished the same in just 5 microseconds.
Before we address the second, more pressing question regarding the ends of this alternating display modes, let's have a look at the second notable update. This is concerning the routine that was translating any positions relative to the first spaceship in version 4.3 and which is now augmented to do this for both of the ships depending on the state of flag 4.
The routine is to be called by a jda instruction, thus the contents of AC will be placed in the location labeled kcb and we will enter the routine at kcb+1 with the return address in AC:
kcb, 0 /relocate for center display dap kc1 // deposit return address lac kcb // restore AC szf 4 // flag 4 zero? jmp . 6 // no, skip next 6 sub nx1 1 // flag 4 zero, subtract x-coor of spaceship 2 from AC swap sub ny1 1 // and the y-coor from IO swap // swap AC and IO to initial order jmp kc1 // jump to return sub nx1 // subtract x-coor of spaceship 1 from AC swap sub ny1 // and the y-coor from IO swap // swap AC and IO to initial order kc1, jmp . // return
With the y-position in IO and the x-position in AC, this subroutine is called anywhere in the code where a pair of display coordinates is set up. In any frames, where flag 4 is unset, the coordinates will be translated relative to spaceship 2 by subtracting it's current coordinates, and in each frame, where flag 4 happens to be set, the translation is done relative to the position of spaceship 1.
While this positional translation was only a conditional option in version 4.3, applied only when sense switch 2 was deployed, the routine is now executed unconditionally as any of the checks for sense switch 2 are consequently stripped from the code.
So, there will be frames displayed at the default intensity with a view relative to spaceship 2 (the Wedge) and frames displayed at intensity 4 with spaceship 1 (the Needle) in the center. And, as we see the scheme completed by the addition of the code at label 4 at the end of the scorer loop, too, we may finally question the ends of these modifications.
Was this meant as some kind of flickering superposition of two alternate, subjective realities, as some kind of psychedelic exercise in augmented perception? We may refer to Stewart Brand, describing his impressions when seeing Spacewar! being played at Stanford in fall 1962:
What I saw was an interaction around computers that was as intense as anything I saw around drugs or anything else that I knew. People were absolutely out of their bodies playing. It seemed that computers were doing everything that drugs had promised. Drugs were much more self-limiting than computers: the hackers had found something better than drugs, but theirs was the same bohemian frame of reference.
(Brand, Stewart, quoted in Brown, Andrew, "Whole Earth Visionary"; The Guardian, August 4, 2001)
And in another description of the same event:
"They were absolutely out of their bodies, like they were in another world," he [Stewart Brand; N.L.] recalled. "Once you experienced this, nothing else would do. This was beyond psychedelics. It impressed the heck out of me."
(Markoff, John, "A Long Time Ago, in a Lab Far Away …"; The New York Times, February 28, 2002)
Was this dealing another twitch to the "Spacewar! junkies"? — And, if so, what would the alternation of the display intensities add to this?
Returning to the straight world of DEC documentation, we may want to consult the manuals on the usage of display intesities and, especially, the meaning of display intensity 4. The display instruction dpy translated to the instruction code 72cb07, where c whould encode the origin and the 3 bits of b the brightness or intensity. Thus, there were 8 intensities in the range of 3, 2, 1, 0, 7, 6, 5, 4 ordered from the brightest one to the lowest, with a default intensity of zero. Read as 1's complement 3-bit values (compare DEC, F-15(30E), 2-5-12/63, p. 3-12), this translated to the more comprehensive series +3, +2, +1, 0, -0, -1, -2, -3.
Now, intensity 4 (or -3) is described as invisible to the human eye and visible to photomultipliers only, rendering the whole endeavor even more questionable, as every second screen would just be rendered invisibly on an else dark display. Not so useful, we may say. Was this really worth the effort?
But the display instruction dpy at an intensity of 4 also enjoyed another use: Besides the Type 30 CRT, the deticated visual display for the PDP-1, there was also the Type 31 Ultra-Precision CRT Display, a high density display for photographic recording that was rendering at a relatively small area of 3 x 3 inches square at 4096 x 4096 plotting positions (1024 raster locations discernable along each axis). If this display was hooked up to the PDP-1, a display command at intensity 4 (instruction code 720407) became the dpp instruction that would address this second display. We may also asume that this would have worked with any other compatible display (like another Type 30), as long as this was a full display unit returning a completion pulse and not just an auxiliary slave display mirroring the image of the main display.
The DEC Type 31 Ultra-Precision CRT Display.
Image (remastered): DEC, PDP-1 Handbook, F-15D 1963; p. 37.
We may observe that using the dpp instruction with the Type 31 display and its resolution of 4096 by 4096 addressable locations, there were now the highest 12 bits in AC and IO significant for any display coordinates, instead of the 10 bits used for the Type 30 display. But, as for Spacewar!, this wouldn't have posed a problem, since all properties and calculations related to positions are rather in fixed point with a fractional reserve of precision than simple integer values. Moreover, we may note that there was no way to specify intensities with the dpp instruction and any dots were by definition displayed at the default intensity, regardless if this was a Type 31 display or any possibly other compatible solution. (As for the propability of there actually having been a second display unit, we may note that at least the PDP-1 installation at the Lawrence Livermore National Laboratory had a secondary Type 31 CRT at this time, compare the description of the hardware used in "Computers and Computer Systems / The PDP-1" by George Michael.)
Now we can see Spacewar! 4.4 in a different light: It displays the game on two separate scopes in alternating frames, each of the scopes dedicated to one of the players, drawing individual views relative to a player's spaceship. The main display unit would render the view of the second player with the Wedge put in the center, while the first player piloting the Needle would be placed at the secondary display. (We may note that due to this setup playing the game by means of the test word controls wasn't an option anymore, control boxes were a requirement.) While the refresh rate of any of the displays would drop by 50%, this wouldn't have been as much as an issue as with modern displays, thanks to the long sustain of the P7 phosphor stabilizing the image.
Since the DEC tubes were actually plan position indicator (PPI) radar displays (and apperently the hackers and users were aware of this [1]), the situation of the disembodied Spacewar!-players in the darkened room behined their displays would perfectly mirror that of the hypothetical pilots fixed to the gloom of their onboard scan radar screens, else surrounded by the void darkness of space outside of their ships.
Et voià — what we're facing, is world's first attempt at a first-person multiplayer game, ten years earlier than any other known example of the genre (compare Maze for the Imlac PDS-1, 1973)!
But, before we discuss the applicability of the term First-Person Shooter (FPS) in this context, let's have another look at the code first.
[1] Compare: "In the old days we spent many hours staring at this contraption, into what appeared to be a surplus radar scope dueling across the void of space with simulations of heavily armed spaceships.", James A. Mahaffey in Jamie Parker Pearson (ed.), "Digital at Work: Snapshots from the First Tirty-Five Years."; Burlington, MA, Digital Press 1992; p. 20.
Ptolemy Fixed
As we've pointed out before, the relative or subjective view isn't totally new in Spacewar! 4.4, as it had also been attempted for a single ship in version 4.3. But this Ptolemaic view with the Needle fixed to the center and any stars orbiting around it and the Wedge oribiting in epicycles did have some issues. Namely
- the gravitational star was split and placed at an odd, constant offset to the center origin,
- the exhaust flames were drawn at a displaced position — while it was drawn from a position that had been translated relative to the first spaceship before, the offset had been applied in the drawing routine a second time,
- any torpedoes were displaced likewise, even more, they were actually mapped to displaced coordinates in the internal representation of the game.
While building on the code of Spacewar 4.3, version 4.4 addresses each of these issues. Let's start with the most prominent features, the split twin-stars of Spacewar! 4.3.
We may recall how the gravitational star is drawn and why it was split and displaced in the "Twin Star mode" of version 4.3. Normally, the star is drawn in two passes, first inside-out from the center origin, then the display coordinates are complemented (mirrored by the center) and the scond part is drawn outside-in from this mirrored position, using the same slope as display positions are advanced. While the code was subtracting a relative offset from the start position, it didn't account for the out-of-center location, thus causing the star to be split in two parts when the display coordinates are inverted.
Drawing algorithm for the heavy star, normal and Twin-Star mode of Spacewar! 4.3.
Further, while actually attempting to subtract the coordinates of the spaceship from the center origin to obtain the starting position of the drawing, a constant offset of 64 display locations to both sides and a zero-offset on the y-axis was applied instead. We found the reason for this in the way the symbols used are actually defined in the Macro-assembler code:
spacewar 4.3 5/17/63 ddp ; pt 1 / interesting and often changed constants ... hur, 30, 40000 / hyperspatial uncertancy ... 40/ cwr, jmp mg1 / normally iot 11 control . 20/ / space ... /display gravitational star ... bpt, dap bpx random sar 9s sar 6s spa cma sal 3s add (bds dap bjm cla cli clf 6-opr-opr szf i 20 jmp bjm-1 sub ny1 // subtract y-coor of spacship 1 swap sub nx1 // subtract x-coor of spacship 1 dpy-4000 bjm, jmp . bds, repeat 10, starp szf 6 bpx, jmp . stf 6 cma swap cma swap jmp bjm ... /spacewar 4.3 5/17/63 ddp ; pt 2 /main control routine for spaceships nob=30 /total number of colliding objects ... nx1=mtb nob ... ny1=nx1 nob ... mtb, / table of objects and their properties /start 4 (end of file)
As we may observe, symbol mtb is defined just at the end of the code, marking the start of free space to be used for the objects table. Symbols nx1 and ny1 are defined relatively to mtb with an offset of 308 (symbol nob) applied iteratively. Thus, nx1 equals mtb+30 and symbol ny1 equals mtb+60. Since symbol mtb isn't defined as this code is interpreted in pass 1 of the assembler, the value -0 will be used by definition, thus temporarily making nx1 synonymous to a value of 30 and ny1 to a value of 60. This isn't of any relevance in normal Spacewar, since these symbols are only used in code following to this: In pass 2, when the object code is generated, mtb is a known quantity and the intended values will be assigned to to nx1 and ny1 respectively. But here, in the star-code of Spacewar! 4.3, the two symbols are used before the assignement is visted a second time and the object code will be generated using values as of the end of pass 1. Therefor, address 308 will be used for nx1 and address 60 will be used for ny18. Location 30 happens to be one of the constant definitions at the start of the program, accounting for the constant horizontal offset, and location 60 happens to be at the end of a block of empty space, thus effecting in no vertical offset bein applied at all.
Spacewar! 4.4 succefully addresses the case of the split gravitational star:
bpt, dap bpx random // set up random length (jump vector at bjm) sar 9s sar 6s // shift 15 bits right to get a 3-bit random number spa // make it absolute cma sal 3s // ×8 (an instance of starp has 8 instructions) add (bds // add base address and store as target address dap bjm clf 6 // changes start here, clear flag 6 (first pass) bjl, cla cli-opr // clear AC and IO (origin at 0/0) szf 4 // flag 4 zero? jmp bjq // no, jump to bjq sub ny1 1 // flag 4 zero, subtract position of spaceship 2 swp sub nx1 1 jmp bjm-1 // continue at "xct db2" bjq, sub ny1 // flag 4 set, subtract position of spaceship 1 swp sub nx1 xct db2 // initial plot, request completion pulse bjm, jmp . // jump vector for drawing (see above), skips some dots bds, repeat 10, starp // draw the star (inserts code for 8 dots) szf 6 // flag 6 zero (first pass)? bpx, jmp . // no, return stf 6 // set flag 6 lac \bx // invert \bx and \by (slope) cma dac \bx lac \by /// (illegible / missing in the listing) cma /// (missing) dac \by /// (illegible / missing) jmp bjl // start over at bjl for second run
(The three instructions at the end of this section happen to be printed across a page break, but are easily inferred from the context and residual traces.)
We may observe that the split star is fixed in a different way than the one we sugested in Part 9, but it does the job. It does so by rather inverting the incremental offsets that are used for plotting the individual dots of the heavy star (variables \bx and \by) at the end of the first pass than inverting the current coordinates as we've seen it in normal Spacewar-code. Then, the drawing location is repositioned again to point to the center of the star by either subtracting the respective coordinates of spaceship 2 (nx1+1 and ny1+1) or those of the spaceship 1 (nx1 and ny1) according to the state of program flag 4.
While the star will now be drawn as a continuous, single line, the values actually used for symbols nx1 and ny1 are still an issue. In the case of the first spaceship, the same values are used as in version 4.3 (octal 30 and 60), thus placing the star at a constant distance to the left of the ship. But things are even worse for spaceship 2, where addresses 31 and 61 are used to calculate the offset: While address 61 happens to contain the instruction tyi with instruction code 720004 placing the star at a constant offset of decimal 95 display locations above the origin, address 31 happens to contain the current value of the random generator, causing the star to tumble horizontally accross the screen.
As, for the exhaust trails and the torpedoes, we've to start at the setup of the very coordinates, the outline compiler will use to start its drawing. This enjoyed an update, too, now subracting either the positional coordinates of the first spaceship or those of the second one:
scale \sn, 5s, \ssn // scaled sine in \ssn scale \cs, 5s, \scn // scaled cosine in \scn lac i mx1 // load x-position of current object szf 4 // flag 4 zero? sub nx1 // no, subtract x of spaceship 1 szf i 4 // flag 4 not zero? sub nx1 1 // no, subtract x of spaceship 2 sub \ssn // subtract scaled sine (stern of the ship) dac \sx1 // store it in \sx1 for outline compiler sub \ssn // subtract scaled sine again dac \stx // store it as position for any new torpedo lac i my1 // same for y-position szf 4 sub ny1 szf i 4 sub ny1 1 add \scn dac \sy1 add \scn dac \sty
The code is setting up two positions: one at \sx1 | \sy1, one scaled unit vector in front of the center of the ship, to become the stern of the ship as the outline compiler will start here. The second one at \stx | \sty, placed two scaled unit vectors in front of the center, where any newly triggered torpedoes will come to life.
As the outline compiler finishes, the last drawing position, at the aft of the ship, is stored in coordinate \sx1 | \sy1, therefor already enjoying the translation relative to ship. Rather than applying a second translation to this position, as in version 4.3, the code now just issues a plain display command by executing "xct db1".
st2, yincr \sx1, \sy1, sub
lio \sy1
xct db1 // was "dispt i, \sy1" (incl. translation) in version 4.3
count \src,sq7
As for the torpedoes, things are bit more complicated. The position \stx | \sty in front of the ship used for any torpedo is already a translated position as it is derived from the pair \sx1 | \sy1. But, while we would actually want to display any torpedoes at this location, we won't want to map them at this displaced location in our internal representation. (Otherwise, we won't be able to detect any colissions as expected, rendering the whole purpose of torpedoes quite questionable.) Since the translation was done by subtracting the coordinates of the ship, we'll have to add them again in order to arrive at the right location:
sr2, lac (tcr / set up torpedo calc dac i sr1 law nob add sr1 dap ss3 lio \stx // load \stx (x-coor) into IO swp // changes start here, swap into AC szf 4 // flag 4 zero? add nx1 // no, add x of spaceship 1 again szf i 4 // else add nx1 1 // add x of spaceship 2 again swp // swap again, put it back in IO ss3, dio . add (nob dap ss4 lio \sty // same for y coordinate swp szf 4 add ny1 szf i 4 add ny1 1 swp
With the internal position now set up correctly and the translation still applied in the display code of any torpedoes, we may mark the issue as perfectly fixed.
But, while addressing successfully the issues of the Spacewar! 4.3 code, Spacewar! 4.4 also introduces some issues of its own:
- Due to the arcane issue regarding the assignement of assembler symbols by pseudo instructions the heavy star is still rendered at a displaced location and it's even worse in case of the second spaceship.
- While the Expensive Planetarium (EP), which renders the background starfield, is modified in order to serve the two displays alternatingly in consecutiv frames (by the use of the instruction "
xct db1" instead of a simpledpycommand), the main loop of the EP remains unchanged and doesn't display all the stars at every frame. Therefor, only the few stars of the first and second magnitude are shown at the secondary display. - Thanks to an erroneous jump-offset in the relocation routine at label
kcb, torpedoes, explosions and the stars of the EP will be displayed at erratic positions.
Thus, while unequivocally outlining the intentions, Spacewar! 4.4 as-is is not a perfect program and renders like this:
Spacewar 4.4 as-is — Mind the torpedoes rendered as stray particles on the right
screen and the missing stars of the third on the fourth magnitudes on this display.
The heavy star is rendered at a fixed offset on the secondary display unit (right)
while tumbling horizontally across the screen of the main display unit at the left.
Last — and least — there's a piece of code that isn't a bug, but rather a bit, let's call it luxurious, namely the updated definition of the macro dispt:
define dispt A,Y,B repeat 6, B=B+B lio Y jda kcb xct db1 term
The "luxurious" part being the third parameter B that is maintained while completely unused. But the 6 additions to B that are an equivalent to a shift to the left by 6 bit positions to prepare it for use as the brightness attribute, happen to be performed in the assembler only and do not propagate to the resulting object code. Therefore, it's quite a neglectable feature of the code and it spared the programmers from updating each of the insertions of this macro.
Fixing Spacewar! 4.4
Once the issues are identified, they are easily fixed.
As for the displaced heavy star, we could add a symbol definition synonymous to nx1 and ny1 after symbol mtb has been defined or equally just befor it is used in the star routine. (Alternatively we could even move the star routine or the assignment to nx1 and ny1, but we prefer to preserve the existing code mostly as is.) For this purpose, we define two new symbols that will be assigned the proper values and replace any occurrences of nx1 and ny1 by these synonyms:
// define two new symbols to fix an assembler issue // (symbol 'mtb' isn't defined before the end of at pass 1) // N.L. 2015 ox1=mtb+nob // same as nx1, but properly available here oy1=ox1+nob // same as ny1, but properly available here bpt, dap bpx random sar 9s sar 6s spa cma sal 3s add (bds dap bjm clf 6 bjl, cla cli-opr szf 4 jmp bjq sub oy1 1 // replaces "sub ny1 1" swp sub ox1 1 // replaces "sub nx1 1" jmp bjm-1 bjq, sub oy1 // replaces "sub ny1" swp sub ox1 // replaces "sub nx1" xct db2 bjm, jmp . bds, repeat 10, starp szf 6 bpx, jmp . stf 6 lac \bx cma dac \bx lac \by cma dac \by jmp bjl
As for the missing stars of the EP on the secondary display, we just strip any code related to counter bcc and display all of the stars at each frame.
(Alternatively, we could change this to display the two lesser magnitudes only at every third and fourth frames to produce some distinction, but this would result in some extensive flicker. Therefore, we'll display all of them at the default intensity, consistently with the other display commands in version 4.4, and render the stars of the first magnitude twice.)
/background display // fixed to show all stars at both displays (N.L. 2015) bck, dap bcx szs 40 jmp bcx // no display with sense switch 4, return jsp 1m jsp 2m /idx bcc// counter bcc unused, show all magnitudes each frame /and (1/szajsp 3m /bc1,law 3// see above (label "bc1" is unused, too) /and bcc/sza ijsp 4m bc3, isp bkc // increment bkc and advance the view-port, if zero or positive jmp bcy law i 10 // reset to -8 (dec.) dac bkc law i 1 // decrement right margin add fpr spa add (20000 // reset to max x-value of data domain on underflow dac fpr bcy, jsp 1m // first magnitude still rendered twice bcx, jmp . 1m, dislis 1j,1q // displays 1st magnitude 2m, dislis 2j,2q // displays 2nd magnitude 3m, dislis 3j,3q // displays 3rd magnitude 4m, dislis 4j,4q // displays 4th magnitude /bcc,0// frame counter for magnitudes, now unused bkc, 0 // frame counter for horizontal movement fpr, 10000 // right margin, initialized to center-x of data domain
Leaving us with just a single task remaining, namely fixing the relocation routine at label kcb.
An attentive reader might have already noticed the issue with the code, namely the offset to the jump at "jmp . 6", right after the first check of program flag 4. This offset is counting any of the inclusions of the macro "swap" as a single instruction, while the macro actually inserts two instructions "rcl 9s" in place. Thus, the assembler output of this piece of code looks like this:
ln-no addr. instr. source code comments 1086 02060 000000 kcb, 0 /relocate for center display 1087 02061 262102 dap kc1 1088 02062 202060 lac kcb 1089 02063 640004 szf 4 1090 02064 602072 jmp . 6 // the erroneous jump 1091 02065 423453 sub nx1 1 1092 swap 02066 663777 // rcl 9s 02067 663777 // rcl 9s 1093 02070 423503 sub ny1 1 1094 swap 02071 663777 // rcl 9s 02072 663777 // rcl 9s, actual jump target 1095 02073 602102 jmp kc1 1096 02074 423452 sub nx1 // intended jump target 1097 swap 02075 663777 02076 663777 1098 02077 423502 sub ny1 1099 swap 02100 663777 02101 663777 1100 02102 602102 kc1, jmp .
This is easily fixed, either by updating the offset from 6 to 108, or by using — as probably intended — the single instruction swp for runtime's sake. Here, we go with this second option:
kcb, 0 /relocate for center display dap kc1 lac kcb szf 4 jmp . 6 sub nx1 1 swp // use "swp" (opr+60) instead of macro "swap" sub ny1 1 swp // use "swp" instead of macro "swap" jmp kc1 sub nx1 swp // use "swp" instead of macro "swap" sub ny1 swp // use "swp" instead of macro "swap" kc1, jmp .
This is even a somwhat debatable a bug: Notably the macro "swap" is defined externally and is not part of the listing and this definition could have been updated to insert the single instruction swp just the same. But there are a few opposing arguments: First, we see the op-code for the instruction defined in the source itself, as in "swp=opr 60" (760060) and this would have caused an assembler error, if this symbol had been defined previously. Now, we could argue that an update to the definition of the macro wouldn't necessarily have to define the symbol "swp", but could have inserted just the bare op-code or some synonymous construct. But we may observe that the code added in Spacewar! 4.4 is using both the macro "swap" and the instruction "swp", a distinction that wouldn't have made much sense, if those had been resulting in the same object code. Last, but not least, we know what the external definition looked like at the time, namely as of June 1963:
macro fio-dec system – june 1963 ... define swap rcl 9s rcl 9s term ...
However, we might never know for sure what was actually inserted for the macro "swap".
Finally, while we are at it, we may reactivate the check for the currently unused sense switch 2 as a trigger for the low gravity option. It's just two instructions and the originally authors would probably have done so, too, when they were through with debugging.
With everything fixed, we may actually enjoy a game of Spacewar! 4.4 and see what it looks like:
Spacewar! 4.4 (fixed) in emulation.
Main display at the left, secondary at the right.
A (narrow) "CBS-Opening" in Spacewar! 4.4 (fixed).
Another screenshot of Spacewar! 4.4 (fixed) in emulation
with the Wedge just swerving around the gravitational star.
Links:
- Play/experience Spacewar! 4.4 in emulation (both as-is and fixed).
- Compare it to Classic Spacewar! (in-browser emulation).
- Source of Spacewar! 4.4 as-is: spacewar4_4.txt (5/21/1963)
- Source of Spacewar! 4.4 fixed: spacewar4_4f.txt (5/12/2015)
Now that we know what the game is all about and it what it looks like, we may finally address the more theoretical question whether or not the term FPS may apply to Spacewar! 4.4.
(The following is related to media theory. As for technical interests, the article propably ends here.)
Planar First-Person (Multiplayer) Shooter Games?
In German there is the pseudo-anglicism Ego Shooter that would suit Spacewar! 4.4 perfectly, since the concept doesn't necessarily include the notion of perspective. It rather centers on the scene being constructed from the very position of the player than on any pseudo-realistic or rather abstract quality of the projection. Opposed to this, the common English term First-Person Shooter (FPS) is apparently including the concept of perspective and a pseudo-3D projection onto an image plane that represents the virtual position of the player's eye in the game's universe. Chances are that there is no suitable concept to describe the destinctive qualities of Spacewar! 4.4.
We will address the question of the applicability of the term First-Person Shooter for Spacewar! 4.4 and if it would be possible to apply the term at least with some restrictions in a twofold manner. First, we will explore what the term first-person could mean in the universe of Spacewar! and if there would be any equivalent at all. In a second approach we will try a somewhat phenomenological approach to the meaning of space in video games and visual computer games with respect to the term FPS. Thus prepared, we may finally settle on the subject — or at least express a personal preference.
First-Person in a Planar World
Spacewar! is commonly described as taking place on a toroidal 2D surface plane. We may argue that the notion of a toroidal surface is quite a hyperbolic pretext to a phenomenon that is just consistent with the representation of values in a discrete numerical computer, namely the overflow from the largest representable value to the smallest one and vice versa. (Notably, we find the same sort of consistency with a common notion of the machine as beheld by the user in the rise of text adventure games in the age of the command line interface and timesharing.) We may take this transgression across the upper and lower bounds of any representation for granted, like it was probably the case for any users that were directly manipulating the machines of the time. Thus, we may describe the universe of Spacewar! essentially as planar 2D, with an emphasis on the absence of any notion of elevation or whatsoever.
This universe is represented by an abstract or symbolic view that is planar like the universe itself: The objects are layed out on the screen in a map-like representation that we may call best a cartographic view. Moreover, there isn't any notion of realism other than in the spatial relations of the objects. While Steve Russell once referred to cartoons when describing the outlines of the spaceships (compare Kent, Steven L. The Ultimate History of Video Games. Roseville, CA: Prima Publishing, 2001), this kind of view is oftenly referred to as a radar view when used as a supplementary view to a more complex representation. Most important, there isn't any kind of perspective involved, there isn't even an idea of anything alike.
Notably, there isn't any other mediating instance or agency in Spacewar!, like a scrolling action of a view-port, since the representation is already exhibiting its universe to the full extent. Therefor, anything relating to the terms of objectivity or subjectivity can only be represented by either motion or by the means of spatial translation.
When exploring the introduction of any kind of subjectivity into this type of representation, we may want to start with the view as produced by Spacewar! 4.4. As described and depicted above, the representation of the player's ship is fixed to center of what is still an abstract 2D plane, mapping any other objects and motions relatively to this very position:
Exploring subjectivity in Spacewar!, left: Spacewar! 4.4, right: introducing perspective.
By looking down at the scene at an oblique angle from some sort of elevated view-point we not only introduce the very prerequisite for any pseudo-3D projection, we also make this essentially a 3rd person perspective. Further, we may want to align the vertical image plane of this projection with the imaginary windshield of the spaceship, but this is still a 3rd person view on the scene, as the view-point is still outside of the ship. When we align the elevation of the view-point vertically with the plane of the game's universe to produce a true 1st person perspective, the view eventually collapses to a 1D representation. While this may serve as a productive metaphor for a novel like Edwin A. Abbott's Flatland — A Romance of Many Dimensions (London, 1884) it wouldn't suit the purpose of a game which's mechanics may be (easily) mastered, for just the same reasons that made it a rich metaphor in satirical fiction. Thus we may conclude that there isn't such a thing like a working first-person perspective in a planar universe.
(We may observe that while there may have been some notion of a second background plane with the stars of the Expensive Planetarium in classic Spacewar!, this changed in Spacewar! 4.4 as the stars became subject to the full extent of relative motion. By ignoring any kind of parallax, the stars are placed on the single plane of the 2D universe and serve as an essential indicator for the motions of the central spaceship.)
Seeing us forced to reject the very idea of perspective and view-point, we see us also forced to adopt some sort of planar representation that is consistent with the planar universe of the game. But we may try to improve on this by not only fixing the position of a players ship and mapping any objects relatively to it, we may also want to fix the heading of the ship and maybe also move it to the bottom of the screen with any visual content placed in front of it. (For the purpose of the thought experiment, we may ignore that we're beyond the feasibility using the machines of the time, as we would have to multiply any of the coordinates by the unit vector representing the rotation of the central ship.)
By fixing the heading of the ship, we're essentially breaking the cartographic metaphor of the representation (and, along with it, also, how in the Ptolemaic tradition objects in space are mapped relatively to an observer's position). By moving the representation of the observer out of the center origin of the screen, we're breaking the radar-metaphor, as well.
As for the latter, we must not forget that this is the very essence of the realism of the game, since the radar-like appearance isn't just some kind of pseudo-projection, some kind of skeuomorphic rendering of a texture, or a superficial likeness, the realism is grounded on the CRT tubes being the real thing. Even more so, as PPI scan radar is also consistent with Spacewar's universe in the absence of any notion of elevation. We may also consider the then contemporary tradition of computer mediated radar displays, as used with the SAGE system (Semi Automatic Ground Environment) and its relation to the very first computer displays, like the Cape Cod System and the Charatron display. Remarkably, it is also the very tradition the cartographic rendition of Spacewar! is founded on. (An other, related tradition would be the cartoon-like rendering of the mouse and cheese in Mouse in the Maze on the TX-0, which is yet an abstract mapping of a real-world electro-mechanical contraption presented previously by Bell Labs.) Further, with the concept of a toroidal space and an absolute view that exhibits the whole universe of the game at once, moving the ship to the bottom of the display's plane would mean the aft of the ship and the space behind it to appear at the top of the screen, which wouldn't actually add realism to the scene.
With the heading fixed (e.g., the stern of the ship always pointing north), all properties of motion and turn are only to be conveyed by the motion of outside objects. In a game, where all objects but the heavy star are subject to motion at any time, this wouldn't actually help with the game mechanics, but rather result in another kind of collapse of the view, this time related to the dimensionality of the information encoded in the representation. (This is also, why we see supplementary representations, like radar views and constant landmarks added to games that feature a true first-person pseudo-3D perspective, in order to allow the decoding of the combined properties of motion and turn. We may also observe restrictions in the implemented model of game mechanics, like a viscosity of inertia or a limitation of turn rates and acceleration.)
Thus, we wouldn't only be breaking some of the fundamental metaphors of the game, we were also to introduce some fundamental changes to the game itself in order to apply this kind of views, like dismissing the moving stars of the Expensive Planetarium in favor of a static background that provides the appropriate consistency for navigation, or like introducing a framed aspect that wouldn't show more than a limited extent of the space at a given time. Introducing any of the kind would mean to dismiss some of the very fundamentals the realism of the game as a simulation is based on, rather than adding to them. Most importantly, these options were simply not available with the computational means of the day. On the other hand, the solution found in Spacewar! 4.4 is in line both with the principles of the game and the physical properties of the display technology. (As a final note on the subject of inherent realism, we may also consider that — based on the code analysis — the idea of a subjective view was developed in version 4.3, when the Bomarc / drone control joystick panels were attached to the PDP-1, conveying the very impression of directly controlling a real craft.)
We may conclude that we are not able to come up with a representation that improves both on subjectivity and realism while remaining still consistent with a planar universe. The individual views as conveyed by Spacewar! 4.4 are not only congruent with the kind of view that is conveyed by a PPI display, namely a polar coordinate view of a planar surrounding relative to the position of the observer, but also with the Ptolemaic model as the very model of a subjective perception of space from an observer's position. We will discuss any implications of this, like identificational properties, below, but we may already observe that these are making a difference to the game. While we may have to reject any idea of a person-related view, like a 3rd person view or a 1st person view, for a non-scrolling planar game like Spacewar! at all, simply, because there is no camera-metaphor involved in this type of abstract totality of its representation, it's still the closest related to a subjective vision we could think of.
Towards a Phenomenology of Spaces in Video Games and Visual Computer Games
If we would want to approach a spatial theory of video games (including interactive visual real-time computer games), a phenomenological approach recommends itself, especially, if we do so in order to address any implications of subjectivity in the representation. We will borrow some from the rich inventory of film theory, which may apply because of the obvious similarities and relationship in disposition, like the engaged subject placed in a fixed view-point in front of a projected moving image and a radical dissolution in the perception of the surrounding environment involved.
While sketching the outlines of a phenomenology of space in video games, we may consider (at least) the following categories:
- A diagetic space, i.e., the imaginary space in which the narrative of a game takes place, including any external references,
- the space of the internal representation, i.e., the kind of computational representation and its dimensionality by which the entities and/or objects of game are mapped internally,
- the space as conveyed to the player by the specific projection,
- the mode of this projection.
(Note: We may miss in this enumeration the mental model established by the player, but, in terms of methodology, we are not allowed to build on what is an essential part of making meaning in the context of video games, when addressing the question, how this meaning is established at all. Therefor we'll address this rather as an a posteriori than a fundamental category in the following, while it may be found figuring as a major category in some psychological and/or process-oriented descriptions of spatial meaning and immersive qualities in video games.)
In order to illustrate these spatial categories, let's list a few games according to their dimensional properties:
- Maze (Steve Colley, Howard Palmer, and Greg Thompson, 1973 ca.), commonly recognized as the earliest known multiplayer first-person shooter game,
also known as Maze War (Jim Guyton, Bruce Malasky, et al, 1975/76) on the Xerox Alto,
(Note: Following a common practice we will refer to this game by the better known name of the latter implementation as "Maze War".) - Red Baron (Atari, Inc, 1980), a vectorized first-person game with informational text overlays,
- Elite (David Braben and Ian Bell, 1984), presenting a compound view of a pseudo-3D out-of-the-window view, a supplementary 2D-radar display in a skewed pseudo-3D representation and some auxiliary controls and artwork rendered in 2D,
- Classic Spacewar! (Steve Russell et al, 1961-1962),
- Spacewar! 4.4 (Monty Preonas and Joe Morris, 1963),
- and, for the fun of it, a real-world rendition of Pac-Man using robots (compare Takashi Yamazaki / Namco at IREX-2005).
Left to right: Maze on the Imlac PDS-1 and Maze War on the Alto, Red Baron (arcade), Elite on the BBC Micro, robotic Pac-Man.
(Images: Maze and Maze War – DigiBarn, Red Baron – RetroGT, Elite – Wikipedia, Robot Pac-Man by Akihabara News, 2005).
We may describe the modes of spatiality in these games as follows:
| Maze War (main) |
Red Baron | Elite | Spacewar! | Spacewar! 4.4 | Robot Pac-Man | |
| diagetic space | 3D | 3D | 3D | 2D, toroidal | 2D, toroidal | 2D, raster |
| internal rep. | 2D | 3D | 3D | 2D, overflowing | 2D, overflowing | 2D |
| conveyed view (main; supple- mentary views) |
3D | 3D; abstract |
3D (main); pseudo-3D (radar); 2D (panel); abstract (overlay) |
2D, absolute | 2D, polar | 2D, continuous |
| projection | pseudo-3D | pseudo-3D; absolute 2D |
pseudo-3D; 2D of pseudo-3D; 2D; absolute 2D |
2D, view-portless | 2D plan-polar, view-portless |
3D / real-world |
We may observe that there is hardly such a thing as a strict consistency in the evocations of space involved, even in those examples that we would consider as strict examples of a 3D first-person view. We may also observe that the common property of what we recognize as a pseudo-3D first-person projection is a three-dimensional notion of space in the diagesis that allows an elevation of the view-point and the construction of a mediating view-port. (Generally we may observe that there have to be at least as many dimensions in the space of the diagesis as there are in the space conveyed by the projection in order to establish a meaningful perspective, while no such restrictions apply to the internal representation.) We will see, if this would be the only approach to a first-person view, or if there is also some sort of subjectivity involved that does not relate to the terms of a virtual perspective.
We may also observe that the notion of a first-person view isn't necessarily excluding the avatar-like presence of the player in the rendered view, as we may at least regognize some traces of it in the partial renditions of canopies and cockpits, instrument panels, body parts, weapons, static artwork, or partials views of a vehicle that are not subject to a spatial relativity. On the contrary, we often see a discernable difference in the plane of the projection on the plate of the display and the virtual image plane of the rendered pseudo-perspective involved in order to provide for such graphical elements.
The spatial modes we were describing above are of importance as they are crucial to the construction of the gaming experience. Here, we may distinguish:
- The player as an entertained subject who participates in the diagesis of the game, but not necessarily to the full extent. (E.g., while playing a clone of Space Invaders, we may ignore or even reject some of its pretext, like, if we're defending a base on Earth, Moon, or Mars, if we're fighting against aliens, robot drones, or some kind of crafts, or, whether the player sprite represents a tank or would be just an abstract representation of the player's position.)
The player refers to this diagetic universe of the game necessarily by means of the scene as conveyed by the projection. - The player as a user is involved in the reconstruction of the internal representation in order to master the game mechanics. (We may note an anology to film, where the viewing subject is trying to reconstruct the pre-filmic-space in order to establish meaning.)
Here the player refers to the rendition on the screen in terms of clues and hints to the spatial qualities and the regulating principles, properties, and mechanics of the internally hidden model of the game.
These modes of the player-subject are distinguished by the kind of semiosis involved: In the first case, we're dealing with an imaginary signified by an imaginary signifier (compare Christian Metz [2] and the formation of theory building on the reception, commonly referred to as subject theory or apparatus theory, also known as neo-structuralist film semiotics). This also includes any notions of the aesthetical qualities and textures of the rendition or its temporal qualities as far as they are part of the experience of the game. It also provides the basis for any further understanding and enjoyment of the narrative, like narrative interventions, plot strategies and any other higher level analysis of the diagetic universe as it is presented in and by the narrative and its economy.
[2] Metz, Christian, Le Signifiant imaginaire. Psychoanalyse et cinéma; Paris: Albatros, 1977; Engl.: The Imaginary Signifier. Pyschoanalysis and the Cinema; partly pub. 1977-1982; London and Basingstoke: Macmillan, 1982; and Bloomington: Indiana University Press, 1982.
In the second case we're dealing with the reconstruction of a hidden spatial and temproral arrangement by the means of another, exhibited spatial arrangement. This space hidden by another space poses the essential riddles and puzzles that are to be met and overcome as a challenge by building skills (especially in the domain of eye-hand-coordination) in order to attain mastery over the gameplay. (In terms of semiotics, we're dealing here with a representamen the indexical qualities of which, as related to the internal representation — this internal representation likewise being denoted by the entirety of these —, must be abduced in another act of higher semiosis.)
Film semiotics propose a twofold structure of identification for the spectator: A primary identification, where the spectator identifies with the very process of looking as a perceiving subject, implying an illusion of coherence and mastery related to Lacan's analogy of the mirror stage, and layers of secondary identification arising from the identification with the characters on the screen. This identification is crucially a product of a spatial diposition: The immovable spectator-subject which is viewing the scene from an ideal view-point (which the very term subject is derived from) identifying with the camera and its movements that are typically bound to the main characters, at least in narrative cinema, regulated by the means of continuity and invisible editing. "What moves in film, finally, is the spectator, immobile in front of the screen. Film is the regulation of that movement, the individual as subject held in a shifting and placing of desire, energy, contradiction, in a perceptual retotalization of the imaginary (the set scene of image and subject). This is the investment of film in narrativization; (...) the spectator is the point of the film's spatial relations." (Heath, Stephen, Questions of Cinema, Bloomington: Indiana University Press, 1981).
While most, if not all, of this also applies to video games, there is even more to it than the enoncé of film semiotics, this dreamlike, fantasmatic in-between of outside vision and internal imagination, where a presentation of serial images and plot structures is activated by an essentially passive subject. In contrast to the spectator-subject of film theory, the video gamer is an active subject, as well. Any notion of mastery and illusionary coherence, arising from the mere act of viewing, would be instantly wracked to the pieces of a fundamental frustration, if solely based on passive, motorically deprived perception. Extending on the traditional theory, we may note that some of the secondary identification in cinema is a product of the psychological investments made by the subject in decoding and reconstructing space in order to make meaning, a space that is typically presented and revealed by the movements of the main characters on the screen, thus binding these investments to the main characters as the camera is bound to the acting of the players. In video games, this kind of investments are specifically made in a domain of purpose in order to address and master the riddles posed by the essentially hidden realm of game mechanics as encoded in the internal representation of the game. What unlatches and localizes identification on the first hand, are the "pivots" of interaction, any locations on the screen that allow access to the internal mechanics. The riddles posed by the game mechanics and the controls and hints provided to the player as means to address them contribute an integral part to the aesthetics of the game as much as to its narrative and textual qualities. (And it's also in this domain that we meet again the rhythm of shifting, contradiction, and retotalization, the placing of desire and energy as described by Stephen Heath above, e.g., in the raising complexity and redefined riddles emerging from alternating levels.) Importantly, this domain is not bound to a specific projection other than by the riddle it poses to the player.
This is also, why we see specific projections in video games that are typically not found in narrative film: The absolute view of the totality without any mediation of a view-port that would coincide with the view of a camera, or, of more interest here, subjective views. In narrative film a first-person perspective typically collapses in terms of identification, when maintained over a longer period of time, for the lack of a crystallizing main character or any means to actively explore what is else an essentially void scene. (There are only a few examples that are usually considered as not that successful experiments, like Lady in the Lake, 1947, and Dark Passage, 1949.) In video games, the subjective presentation is not only augmenting the riddle of the game mechanics by adding a translation of the coordinate systems involved, it also allows for a construction of space from and by the very pivot of interaction, thus mending the diagetic universe and the realms of interaction in a quality that isn't accessible to film.
We may observe that these qualities of a subjective presentation are not exclusively reserved to a projection that is rendering the view in some sort of pseudo-perspective. The addition of virtual perspective may add to the effect in the terms of a closure of the diagetic universe and the tactical realms of interaction, especially as the narrative of the game approches higher levels of complexity. Quite the same, it doesn't matter, whether the internal representation and the view as conveyed by the projection are of the same dimensionality: Subjectivity and its implications still apply to Maze War, even if it's internally merely a 2D game. Still, there's a difference, especially on the level of game mechanics, if this kind of perspective is used, for example, in a true 3D platform game, as this poses the augmented riddle of spatial translations, of the inherent instability of spatial relations and positions in space in yet another way. Finally, by directly binding the scrolling and/or paning of the view-port to the interaction, a true first-person view inherently introduces a framing effect that is also to be considered in terms of the identificatory processes that have been described by film theory extensively.
In conclusion we may propose the following as the essential qualities of a first-person perspective in video games:
- An increase in realism due to a dimensionsional congruency of the view conveyed by the projection and the position of the player in the diagetic universe,
- An augmentation of the riddle as posed by the game as a challenge, for an additional translation of coordinate systems of the projection and the internal representation,
- A difference in the mode of identification due to construction of space from the principal pivot of interaction,
- An inherent framing effect that adds both to identificatory processes and, as a spatial instability, to the riddle of the game mechanics as well.
Some of this isn't that exclusively true for a first-person perspective as we may wish in order to use it as a categorizing distinction: Due to the dual structures of identification in video games, what was said in regard with (spatial) structures of secondary identification in film remains of interest in this context. As soon as there is a mediating view-port involved in the visual presentation, we may apply any of the identificatory implications arising from the use of the camera in narrative film. We may observe that this isn't necessarily involving a true pseudo-3D third-person perspective, this is also true for any kind of rendition, where a scrolling view-port is loosely following the central player-character in a horiziontal and/or vertical scrolling action. The difference to what we've observed in the context of a first-person presentation is found in the mediating quality of the rendition. Typically, the vision as provided by the view-port and its framing is not directly bound to the movements of the player-character, but is allowing for some freedom of movement while still remaining fixed to the same aspect, with any scrolling or panning action triggering at some treshold. There're two implications of this: A presence of the machine as a mediating agency (as may be experessed in the contradicting discontent of a player with the camera mechanics) and a stabilizing quality of this mediated view that attempts to minimize the effects of an instable spatial representation that we found to be characteritic for any first-person view. By this, the agency of the machine becomes a guaranteeing factor, becomes the disembodied presence of the regulating principles, which aligns itself with the visual axis of the human-computer interaction. If it should fail, we typically encounter a moment of contradiction and disbelieve that is breaking the "magic" of the interaction. It aimes at minimizing any translational aspects of the representation as opposed to augmenting the riddle posed by it. Thus, the stabilizing quality of a third-person-type view may be regarded as its most prominent feature in regard with a catagorization by point-of-view.
Finally, we may observe a third type of spatial construction, the absolute view, where the visual representation maps the internal representation to the total extent in a stable view with no framing, scrolling, panning, or rotation applied in any way. In this type of presentation any structures of secondary identification rely solely on the movements of objects on the screen, some of them distinguished by a further focus and conveying the very pivots of interaction. We may note that in this regard the absolute view is more closely related to a first-person view than to a third-person view, while a first-person view distinguishes itself by the features we outlined above. (In terms of film, we may compare this to Andy Warhol's Empire, 1964, depicting the Empire State Building from the 41st floor of the Time-Life Building in a fixed frame for more than 8 hours runtime. In the absence of any pivots of interaction as they are provided by video games, the film was generally characterized as unviewable by critics.) Remarkably, the destinctive features are still maintained, if a game like this is rendered in a 3D real-world environment that allows to oversee the whole scene at a glance (compare the robotic Pac-Man installation at IREX-2005).
To illustrate the importance of these identificatory implications of spatial construction in video games, we may point out that the identificatory trajectories as layed out above are still accessible to an else uninvolved observer, who may still identify with a player-subject who's actions are solely disclosed by the representation. The growing industry of e-sports and gaming streams illustrate quite well that perspectives and views that are commonly regarded as not being suitable for narrative film are still of value for an inactive observer of video games, who is essentally deprived from any means of interactive participation.
Notably, we were able to sketch a theory of spatial representation that is not related to an optical perspective conveyed to the player-subject, but rather categorizes on the inherent implications of the representation. We may infer that the notion of pseudo-perspective is not as essential to categorizing video games by type of view as may have been previously assumed.
(Notes: A recent neurological study — Greg L. West, Brandi Lee Drisdelle, Kyoko Konishi, Jonathan Jackson, Pierre Jolicoeur, Veronique D. Bohbot. "Habitual action video game playing is associated with caudate nucleus-dependent navigational strategies." Proceedings of the Royal Society B, May 2015 — suggests an increased involvement of the caudate nucleus of the striatum, related to the reward system responding to trial-and-error strategies, to be associated with navigational strategies of players of first-person video games as compared to a more prominent reliance on spational memory, commonly associated with the hippocampus, as observed in the test group. While the study centers on response learning strategies in the context of habitualization due to long-term exposure to video games, this may also suggest that the propositions made here might be available to tests using neurological fMRI-type imaging or similar. However, the perception of visual images is a remarkable complex process involving both parallel and temporally interleaved activities in wide areas of the brain, compare the study by Bartels A., Zeki S., Functional brain mapping during free viewing of natural scenes, Feb 2004. Even such basic elements of perception as the mapping and transport of information related to color and contrast by the visual cortex do not lend themselves easily to neurological description or obervation, compare this study or the popular article found here. Therefor we may still want to restrict ourselves to a theory based in the humanities.
Addressing any oppositions that may arise in regard with any block of theory with references to psychoanalysis, which we didn't stress to much in this context, we may note that both the theories by Freud and by Lacan are still essentially aimed at describing a neurological apparatus, while addressing it in different terms. As a historical footnote we may further note that the theoretical application to film and spatial analysis, while commonly associated with the work of Christan Metz and its reception, arises as early as in the 1960's in the work of Raymond Bellour.)
Application — Spacewar! 4.4
Maybe the most prominent aesthetical feature of classic Spacewar! is the pulsing rendition of the gravitational star, the sole immoveable object in its universe, put in the very center origin of the display as the embodiment of the presence of the machine and of its agency, thus adding to the pull of gravity in the diagetical universe an equal visual pull in the rendition. Let's explore in the context of the approach lined out above the implications of Spacewar! 4.4 putting the player's spaceship in this very place and making it the sole stable object on the screen.
Realism
As already mentioned above, the tubes of the DEC displays were original designed for the use with scan radar scopes. Moreover, the viewing situation in a dimly lit or darkened room resembles closely the situation this screen would be seen in a hypothetical spaceship, with the scene rendered in the gloom of the instruments and the dark voids of space outside. In terms of realism, we probably can't advance any further. (We may want to also fix the heading of the spaceship indicator and rather rotate the universe as well, but this was simply beyond the computational resources available. Also, as discussed above, this wouldn't have helped in rendering a perfectly decodable representation of the game mechanics.)
Subjectivity
Any objects other than the player's spaceship are rendered relatively to the position of the player in the diagetical universe. Space as conveyed by the projection is constructed from and by the player's position. This also adds a toroidal framing effect, while there is still no view-port or perspective involved.
The view is essentially similar to the presentation of the Ptolemaic model, with the observer put in the center and any other objects orbiting either directly around it or orbiting in epicycles (namely the respective other spaceship). While the Ptolemaic model essentially represented an absolute, map-like view of the universe, aimed at explaining the rather erratic movements of the celestial bodys as observed from a true first-person observer's position along the ecliptical plane, considering it after the Copernican revolution, this view rather translates to the epitome of a subjective, observer-related notion of a total scene. We may observe the similarities of the map-like projection used in depictions of the Ptolemaic model and the scene as rendered by Spacewar! in this context.
We may conclude that Spacewar! 4.4 renders the scene in a fundamentally subjective way, while still presenting a decodable presentation of a planar universe. By this it conforms to the rendition of a scene as it would be conveyed by an onboard radar screen. In the identity of the primal pivot of interaction, the origin of the space conveyed by the scene, the position of the player character in the diagetical universe, and in the relativity to this position of all other objects as presented by the projection, we may recognice the fundamental principles of a first-person view in the context of identificatiory structures involved in video games.
(In)Stability
By fixing the player's representation to the center origin of the screen the major positional properties like location and movement are solely projected by the movements of "outside" objects. Moreover, since all objects in Spacwar!, but the gravitational star, are in constant movement themselves, even the background stars that were meant to perform as positional markers in the original form of the game, the motions of the player as represented both by the rendition and in the diagetical universe mix with the motions of the outside objects. This adds, together with the inherent (toroidal) framing effect of this kind of rendition, to a fundamental instability of the view that is opposed to the inert, absolute view found in classic Spacewar!.
Augmented Riddle
The translation of the internal representation to a coordinate system relative to the player's position adds another riddle to the task of mastering the game mechanics. As any objects are mapped relatively, any motion as conveyed by the projection has to be assigned to the true motion-related properties in the internal representation prior to any meaningful interaction. E.g., the opponent's spaceship is orbiting in epicycles and thus may arbritrary accelerate or decelerate, or even reverse its apparent direction of movement. Or, as the player orbits closely around the gravitational star, any torpedoes seem to swerve on bend trajectories, while still moving in straight lines in the internal representation of the game. Thus, the polar view conveyed by the projection has to be translated to an absolute, inert coordinate system in order to establish a type of meaning that promises mastery over the game. The only means of doing so are the exploration of motion and its effects as rendered on the screen and accumulating some sort of experience that allows for intuitive interaction.
Mode of Projection
As already mentioned, the projection translates a planar 2D diagatecial universe, internally represented in a carthesian coordiante system, to a 2D plan-polar view. Since both of the spaceships are in constant orbital motion and one of the ships is fixed to center in the projection, the second ship is rendered by an irregular Fourier transformation of the combined movements of the ships. As also already mentioned, this coincides with the major properties of a PPI radar scope, the same type of technical apparatus used for displaying the game. While maintaining the descriptive properties of space, like extent and dimensionality, it conveys a substantially subjective view that is distinctive for each of the players. The view may be thought of as the view of an onboard radar screen, as also suggested by the dual P7 phosphor of the screens and the marks and traces of moving objects fading slowly in the gloom of the long sustain phosphor layer. The rendition is, as in classic Spacewar!, an absolute and immediate one, with no traces of any intervening or mediating agency. The plane, this view is projected on, is simply the flat plane at the front of the scope. In terms of the projection, the scope is the scope. There is no necessary distinction of the view the player would have access to in the diagetical universe and the view that is accessible to the player in the real world, nor is there a distinction in material or texture.
We may note that this is no more the abstract space conveyed by classic Spacewar! as the symbolic rendition of a simulation, for this newly introduced identity of the scope in the diagesis and the view conveyed by it and the scope looked at in the real world. Actually, we may regard it as being rather in the in-between, like the enoncé in film semiotics, because it allows for both positions, the symbolic view of a simulation and the imersive position related to the diagesis. While in the latter we encounter Spacewar! as-is with a twist, it's in the former that the alleged position and point-of-view in the diagetical universe coincides with the player's point-of-view on the rendition of the screen. But the contradiction in these two modes of perception couldn't be less: The difference being in essence just a difference in the imaginary position of the player, but not in the mode of the space projected.
Mode of Interaction
The overall mode of interaction with Spacewar! 4.4 is quite different to what may be observed with classic Spacewar!. This underlines the effects that we already described on a theoretical level. It's a mix of both a more indirect interaction, owed to the translation of the coordinate system, and a more immediate perception of the rendition, owed to an augmented realism of the scene as conveyed by the projection. We may observe that this is quite similar to the mode of interaction typically found in true first-person games. There are actually no fundamental differences in the mode of interaction in both types of games. However, there may still be some differences in terms of intensity, or in the level of identificatory implications involved. On the other hand we may observe that the modifications applied in Spacewar! 4.4 were clearly aimed at an increased immersion regarding the gaming experience by adding subjectivity.
Conclusions
As could be shown, Spacewar! 4.4 shares the major properties and implications of what may be regarded as being essential to a true first-person perspective in video games. Notably, there is no true perspective or any kind of true, view-port-based framing involved in Spacewar! 4.4 as the projection still renders an absolute, planar view of the scene. We may either regard this as an essential defect in terms of anything related to the class of first-person shooter games, or we may come to the conclusion that by conforming to the major implications of this type of game, it also may be considered a valid member of this class.
So, we may either want to consider a new class for this game, like "Ptolemaic multiplayer shooter game", comprehending just this single member, or look for the closest class already established that may apply, even if we might have to restrict the term somewhat in order to make it fit.
When considering the second option, we may note that the category of FPS-games already isn't as monolythic as may be wished for. Owed to the very tradition that established the class, we're both finding members like Maze War that are rendering an internal 2D universe in pseudo-3D and those that are exhibiting a dimensional identity of the view conveyed by the projection and the internal representation. Therefor there are already subdivisions of this categories, as found in the subcategory 3D-FPS. Had the tradition been built in a different way, we may have wanted to reject Maze War, the very founding item in this class, for quite similar reasons, we may want to bring as an opposing argument in regard to Spacewar! 4.4. We may even consider Spacewar! 4.4's separation from the known tradition as the main problem in categorizing it properly, as it predates any other known example by an entire decade.
Considering both options, I would opt for adding Spacewar! 4.4 to the category of FPS-games, but doing so only by introducing the restricting term "planar", as in "planar FPS". This way, we may refer to the very essence and intentions of this game in terms of interaction and gaming experience, while still maintaining the notion of the game not involving any kind of perspective in its rendition. Also, the term "planar" refers to both the diagetical universe of the game as to its projection, and to the identity of them and the implied realism thereof, as well. By this, the term "planar FPS" both conveys meaning in the context of related entities and offers descriptive qualities regarding its essential 2D-properties.
Moreover, the term describes perfectly the kind of revolution that is applied to Spacewar! as a multiplayer game by adding subjective renditions for each of the players on separate displays. We may not ignore the implications of this which are, at least intentionwise, similar to that found in Maze War and similar games. Denying Spacewar! 4.4 a classification that is related to this context would essentially mean to deprive it of its destinctive qualities. Putting it aside in a category of its own with just this single member would mean to deny it its place in history, just to keep things simple. If we are aiming at a systematic classification of video games that isn't just listing by apparent qualities (like gray animals), we've to adjust for the existence of the game. Otherwise, we'll miss the broader context.
Let's celebrate Spacewar! 4.4 as the first planar first-person multiplayer shooter game and pay credit to its authors, who were the firsts to attempt a subjective revolution in the presentation of the virtual realms of video games.
Vienna, May 2015
www.masswerk.at
In case you would have found any errors or inconsistencies, or would have additional information,
please contact me.
*****
◀ Previous: Intermission: Yet Another Patch — Spacewar! 2b SA 5 and the Secrets of PDP-1 Loaders
▶ Next: Part 11: The Spacewar 2B Preservation Project
▲ Back to the index.