Digital Video Game Firsts — Michigan Pool (1954)

On the origin of digital video games and the complexity of classification.

When it comes to the first known digital video game (i.e. an interactive game implemented on a digital computer communicating its state by some kind of graphical display), it’s always also about a question of definition. Personally, I’d opt for a requirement of a digital computer running a simulation in real-time and providing means of interactive manipulation of said simulation by some kind of user input (without any interruption to the flow of the program). By this, we define a distinctive problem class for this, namely interactive, visual real-time computing. So a turn based game, like OXO, wouldn’t be a member of this class, while, say, Spacewar! would happily fit the definition.

Therefore, we may come up with a list of requirements, as in

• Digital real-time computing running some kind of simulation,
• A visual display to communicate the state of the game (preferably a CRT as in “video”),
• Means of user input for uninterrupted real-time interaction.
• Further, the simulation and its on-screen rendition should be updated at a pace, which conveys the impression of a seamless interaction (i.e., about a minimum of 10-12 steps per second).

While this serves the purpose of a robust definition, there are still edge cases left. Notably, this excludes turn based games by definition, while some of them may still display substantial real-time capabilities worth considering.

So I’d like to divert your esteemed attention to a certain, lesser known edge case, “Pool”, implemented by William George Brown and Ted Lewis in 1954 on the one-of-a-kind MIDSAC computer.

MIDSAC

MIDSAC was one of a pair of machines developed at the University of Michigan during 1951 and 1953 under a $500,000 sponsorship of the United States Air Force, the general purpose MIDAC (the Michigan Automatic Computer) and MIDSAC (Michigan Digital Special Automatic Computer), designed for real-time operations, particularly for guidance problems. Both machines were designed to share principal building blocks and circuits developed by the National Bureau of Standards (NBS) for use in the SEAC (1951) were selected as a basis for this.

The circuit design was by J. Kaufman, assisted by R. Hooks and B. Smith, under the supervision of J. E. Turk. While a description of the circuitry is found in “Basic circuitry of the MIDAC and MIDSAC” (De Turk, J. E.; Garner, Harvey Louis; Kaufman, J.; Bethel, H. W.; Hock, R. E.; Michigan Engineering, 1954 — PDF download), few is known about the capabilities of the MIDSAC. What we do know, however, is that it performed 25,000 calculations a second by the means of 18,000 solid state gates (“germanium dials”) and about 1,200 vacuum tubes, and featured Williams tubes for memory (with backup units in place for the still unreliable memory) as well as magnetic drums. A 13 inch X-Y point plotting CRT display, which was sourced from the lab, was hooked up to two anlog outputs of the computer for the sole purpose of displaying the Pool simulation. (Compare the court proceedings, Magnavox Company, et al. vs Chicago Dynamic Industries and Seeburg Corp. [AKA Magnavox vs. Bally]; January 1976, Consolidated case number 74 C 1030; pp. 1437, 1447.)

Sadly, there’s no entry for MIDSAC in the BRL Report (1961) listing most of the machines of the time as in use by the US government. However, the machine was said to be “the world’s fastest known computing device.” (William G. Brown quoted in the Chicago Tribune.)

While MIDAC and MIDSAC were situated in the Willow Run Research Center, an off-site, restricted area of the University of Michigan dedicated to defense research and not accessible to mortal students, the center held a semi-public demonstration in June 1954 for the benefit of an ACM deligation, for which “Pool” had been purposely deviced (court proceedings, p. 1446). Both MIDAC and MIDSAC were shown and “[v]isitors took turns playing dice on the MIDAC and billiards on the MIDSAC.” (The History of Information Technology at U-M, IT Timeline.)

A Game of Pool

Neither the game by William George Brown and Ted Lewis, nor MIDSAC, the computer it ran on, have been preserved, but we still do know some about it. There are a few photos and a contemporary article by Roy Gibbons in the Chicago Tribune (Chicago Tribune, Sun, Jun 27, 1954; frontpage; available in facsimile at Utimate history of Video games, at archive.is, or here as a local copy) and there’s a transcript of William George Brown’s testimony in the Magnavox Company et al. versus Chicago Dynamic Industries and Seeburg Corp. case (1976, AKA Magnavox vs. Bally, compare the addendum below).

According to this, the game displayed a 2-inch rendition of the pool cue (compare the photo below) for the players to line up their shots and ran a simulation of the colliding and ricocheting balls in real-time, implementing a full game of a cue ball and 15 frame balls for two players. Graphics were drawn in real-time on a monochrome 13" point plotting X-Y display, the screen being updated by the program 40 times a second (that is, in a normal in-game situations with 2 to 4 balls moving at once). However, for time constraints, the table and its pockets weren’t drawn by the computer graphics, but were rather drawn manually onto the display using a grease pencil.

Similarly, during the initial break, involving movement of each of the 16 balls, there was a substantial slow-down by a factor of 5 or 6 : 1 with the game rendering at just 10 frames per second as it took MIDSAC 105 microseconds to calculate the next update (court proceedings, p. 1477). While not realistic, this was rather perceived as “interesting” as it showed the movement of the balls in a detail, which couldn’t be observed on a real table (court proceedings, p. 1456).

The controls of the game may have been of note, as well, especially for the use of a joystick for user input. While Roy Gibbons describes this as “a series of electronic relay switches“, the Magnavox vs. Bally court proceedings provide a more detailed description, reminding more of a “twin-shooter” arrangement: An analog joystick was used to move the cue stick around the table in order to position it behind the cue ball and a rotational knob controlled the directional angle of the shot, which was then triggered by the press of a button. However, the positioning of the cue stick by the joystick was for display purpose only and the knob provided the only relevant computational input for the program.

Additional controls allowed to reset the game for a fresh frame or to replace a “scratched” cue ball that had vanished in one of the invsible pockets.

According to Brown’s court testimony, the game was done for the sole purpose of the single demonstration in June 1954 and the pool simulation was chosen for its similarities to the guidance problems, which were MIDSAC’s true but classified purpose (court proceedings, p. 1437). Ted Lewis started programming in fall of 1954 (or even earlier), but didn’t arrive at a fully functional program. Brown then joined the effort in April 1954, partly rewriting Lewis’ machine language code (court proceedings, p. 1484). Brown estimated the total effort at six to eight man months (court proceedings, p. 1485).

Here are the relevant passages from Roy Gibbon’s Chicago Tribune article describing the game (mind the mention of craps, a dice game, and Tick Tack Toe, both turn-based games on MIDAC):

Meet Midac and Midsac: Dice, Pool Shooting Fools

BY ROY GIBBONS

Ann Arbor, Mich., June 26
— Secrecy wraps were removed today from new electronic brain machines which play pool, shoot craps, and curse human opponents who attempt to cheat the mechanical marvels at games of tick tack toe.

(…)

Midac’s electronic brother, which plays pool is named Midsac, for Michigan digital special automatic computer. It racks up balls for the game on a 13 inch fluorescent screen and permits observers to try for pockets with a 2 inch long “cue,” also shown on the screen and tripped into action by a series of electronic relay switches.

Midsac thinks in terms of millionths of a second with its 18,000 germanium metal dials and more than 12,000 vacuum tubes. William G. Brown, a research associate at the center, said it is the world’s fastest known computing device.

A Fast Shooter

Each time the cue hits a ball on Misdac’s cathode ray pool table screen, Brown explained, it must make 25,000 calculations a second to determine the direction and speed every ball will travel in relation with 15 others and the cue ball.

It also determines the bounce of each ball from the pool table’s electronic cushion, and then moves the balls so fast on the screen that they seem to be in continuous motion instead of being shoved into 40 different positions a second for each 1 inch of travel.

(…)

(Chicago Sunday Tribune, June 27, 1954; p.1.)

A photo showing the rack arrangement and operations:

In the background of this image we may discernd a placard (apparently by Ted Lewis) for the benefit of the visitors, reading “SCHEMATIC DIAGRAM OF COMPUTER OPERATION IN POOL GAME SIMULATION”.

Here in detail as seen in the background of another photo (aspect, enhanced for readability):

The diagram, a highly abstracted flow chart, shows two alternative main loops in parallel: on the left side the procedures for the “in-game” sequence tracking and animating balls in motion, on the right side a loop for idle state including procedures for positioning the cue stick, replacing the cue ball, or resetting the game.

A seen here in a redrawing (by me, N.L.):

And here’s the entire image showing the exhibit in action:

Finally, a closeup of the game controls specified on the control panel:

So, was this the first digital video game, we know of? This may be a difficult question. Certainly, it was running and rendering in real-time, but, on the other hand, sticking to our above definition, “Pool” is still a turn based game, missing (most of) the real-time interaction part. (Which is also a treat of the real game simulated by the program). The interactive part is really just about lining up the cue, which then triggers a real-time animation sequence without any interaction whatsoever, much like a sophisticated version of Bouncing Ball. However, there have been plenty of Pool games when video games were an established genre, and we certainly do regard them as one of them. It’s still missing part of the definition, but, once the full class had been established for real, we would happily accept it as a member of this class. But for this to happen, we still had to wait for Spacewar!…

An interesting case of the hen-egg problem applied to the realms of classifications and their objects.

Addendum — Court Proceedings Magnavox vs. Bally, Jannuary 1976

On Tuesday, January 4, 1976, William George Brown gave a testimony in the so-called “Magnavox vs. Bally” case, which is officially known as

The Magnavox Company, et al., Plaintiff,
vs.
Chicago Dynamic Industries and Seeburg Corp., Defendants.
Consolidated case number 74 C 1030.

The court proceedings of January 4^th can be retrieved from archive.org.

Hat tip to Ethan Johnson (The History of How We Play) for pointing this out to me!

Here are excerpts of relevant passages describing “Pool”:

Purpose

We gave a demonstration for a professional group [from the ACM — compare p. 1446; N. L.] that had a meeting in the Detroit area -- I guess it was detroit -- I believe in 1954, and we were called upon to demonstrate both of our computers at the Willow Run Researche Center. So we developed a demonstration for them.

(…)

Well, we wanted to demonstrate the nature of the computer, the type of computer that we had built, what it could do. And we came up with the idea of, rather than controlling airplanes, controlling pool balls. We decided to simulate a pool game on a television screen, on a cathode ray tube.

(p. 1437)

Ad-hoc Resources

We were able to obtain this cathode ray tube display [from the lab; N.L.], and we had get a few controls to be able to control such things as the cue stick that was displayed, and be able to control the -- well, there were a few things, like racking the balls and repositioning the cue ball when it scratched, and a few little things like this. We had a few knobs and controls we had to bring together.

(p. 1447)

Controls And Gameplay

Q:

Could you describe those controls and what their purpose was?

A:

Yes, there were several push buttons and knobs and a joy stick type of controls. To begin with, we displayed 16 balls as circles on a catode ray tube and approximately, I think, a 2 inch stick, if you like, which was the cue stick. The cue stick could be positioned anywhere on the screen simply by moving this joy stick because the joy stick gave how much over and how much up, the X and Y positioning, like at the center of it.

Then we had a knob that could point the stick, simply rotate it to give it a direction.

So those controls were used to position the stick behiond the cue ball as if you were taking aim and making a shot.

Then there was a push button you would push when you wanted to shoot the cue ball. The cue ball would then move in the direction that the stick was pointing.

So much for that.

Before doing all of that, if you are starting the game, there is another button you would push and that would give you the initial settings of all the balls. So it would show a recked position of 15 balls and the cue ball itself would be on the othjer end of the table. You would spot just by pushing a button.

Given that, we had set up a direction and positioned the cue stick behind the cue ball. Then we would push this button for starting. The cue ball would then move and presumably you would be pointing it towards the balls in the rack. You would on collision of the cue ball with any ball in the rack begin then to get the total motion of all of the balls as if a ball actually had hit 15 balls in a racked position.

They would move and they would bounce off the edges of the table and if any balls went in the vicinity of a so-called pocket, there being six pockets, it would disappear.

Then there are two things here. One is that when balls would hit rails, they would slow down. We would assume a friction, loss at that time, and also balls rolling would eventually slow down because there is a friction with the table.

So a given shot might take 5 seconds or so and all of the balls would come to a stop, in which case you would then go and with a joy stick maybe the other player then -- it might be his turn -- would then reposition the cue stick behind the cue ball in the direction he wanted it to move, push the button, and you would have your second shot. He would try to hit another and deflect it into a pocket.

Q:

Suppose the cue ball went into a pocket; what would happen?

A:

It would disappear, and in that case, you could do one of two things: rerack the whole set-up, as I explained before, or there was another button which would simply bring back the cue ball on its spot. You could bring back the cue ball from a scratch and then continue the game from there.

Q:

Did the positioning of the cue stick in the X and Y position have anything to do actually with the direction in which the cue ball went?

A:

No, that was simply a nicety for some that would play the game and get the feeling that the cue ball stick was behind the cue ball and would hit the cue ball. It had nothing actually to do with the control of the game by the computer.

Q:

Did the rotation of the stick by this other knob have anything to do with the direction in which the cue ball moved?

A:

That gave it its initial direction, to move. It had everything to do with it. That was an essential input.

Part of the input to the program was the two values obtained from the rotation of the cue stick.

Q:

Where these knobs controlling potentiometers or something like that?

A:

Yes, in both cases. The joystick controls potentiometers and the knob that gives direction controls potentiometers, producing component values. I call them X and Y displacements, so much over, so much up, analog values.

(pp. 1451–1454)

Realism

Q:

Was the game as displayed a realistic kind of game?

A:

This would be subjective, I suppose. I thought it was very realistic. I was very pleased with its appearance.

The motions of the balls and all were quite realistic, including the directions in collisionm, which is something we had to work at a little bit to get correct.

It was all as you would expect to see it, except for the fact that the speed of the game was goverened by how many balls were moving, which meant that at the break, when the cue ball hit the reack of balls, they actually broke in slow motion because in this case 16 balls were moving, which represented that the program had to process 16 moving balls, which took long enough so it couldn’t be done in what you might call real time.

So it became a slow motion break, which I thought was rather nice because you could follow the break. It was interesting to see where the balls really went. You play pool and you have a break and they go so fast that you can’t tell where they were going; but here you could follow them, but that wasn’t realistic.

As soon as the balls started to slow down and stop, as soon as they stopped, then the speed became what you might call normal. Any shot you might take after that was normal speed because typically there would be two, three or four balls moving. With those number of balls moving, they moved at normal speed.

(pp. 1454, 1455)

Interactivity And Screen Display

Q:

All right. How with respect to the demonstration that the particpants saw, as I understood your testimony, to start the demonstration in motion he just pressed a button and then he sat back and watched the balls move around on the screen; am I correct?

A:

Yes. That’s to begin the motion.

Q:

Right. And there was no way -- that in any demonstration that you did on the MIDSAC computer of any game, where you were moving player symbols around, of trying to, in an active relationship, intercept the balls or make the balls change their direction once the button was pressed, is this correct?

A:

Once the button was pressed, it was entirely under the control of the computer program, which had to sense various coincidences between balls and cushions, or edges of the table, yes.

Q:

Oncce the button was pushed it was under computer control; the player had absolutely no control over the motion of the balls or any other activity on the screen; is that true?

A:

That’s true.

Q:

Now, you referred to the sides of the table?

A:

Yes.

Q:

Were they a part of the visible display that the x-y CRT generated?

A:

No.

Q:

They were not part of the lighted display on the screen?

A:

That’s correct.

Q:

How were thex placed on the screen?

A:

I believe we used grease pencils to outline them and the pockets.

(pp. 1478, 1479)

Note: The article has been updated to reflect the insights provided by Brown’s court testimony.

Norbert Landsteiner,
Vienna, 2019-06-23;
Updated 2019-06-27/28.

Discussion/comments on Hacker News: news.ycombinator.com/item?id=20303219.