This chapter was originally slotted between chapters 11 and 12 of the final
book. My editor suggested I take it out because it didn't add much to the story.
I agreed, and wound up summarizing it in the first four pages of chapter 11.
Still, I think it is an interesting read, especially for those nostalgic for the
old days of BASIC programs painstakingly typed in by hand. The chapter was
titled "Bigger Geek Than You."
At a book sale in 1995, a book called Basic Computer Games caught my eye. I was in the library in Mount Royal, the suburb of Montreal where I grew up, and the book was jammed in among titles like Approved Practices in Beef Cattle Production. It had been published in 1978 by Creative Computing, a magazine founded in 1974 as the first to cater to home computing. On the cover of the book was a drawing of a man with his arm around a computer-but one of those old computers drawn to look anthropomorphic, with tape reels for eyes and blinking lights for a mouth. There was no CD or floppy included; the games in the book were listed in source code form, as a series of instructions in the computer programming language BASIC. People who wished to play the games would need to type in the code, letter-perfect, to be able to enjoy such games as "Change" (which computed the correct change for any amount up to $100), "Dice" (which repeatedly rolled a pair of dice and reported the number of times each total came up), and "Letter" (in which you try to guess which letter of the alphabet the computer has chosen).
But this book fascinated me. It made me think back to a time when computers were vastly simpler than they are now, when games like "Rock, Scissors, Paper" (played against the computer) were considered worth including in a book, when a book like Basic Computer Games would get dog-eared from use.
Who played these games? Probably a lot of people who went on to become programmers at companies like Microsoft. Often the user playing the game would not be sitting at the actual computer that was running it, but rather at what was known as a terminal, which was connected to the real computer by a cable, or perhaps by a modem connection over a phone line. A terminal might look something like a modern computer, with a display and a keyboard, or it might be a "line terminal." A line terminal was like a typewriter that in addition to printing out whatever the user typed could also print out characters sent to it by the computer. Line terminals used fanfold paper (the paper in which every sheet is attached via a perforation, and there are twin sets of holes running down the sides), so the result of all this would cascade out and collect on the floor. The terminals with video displays were not conceptually more powerful than the line terminals; they did not display any graphics, but displayed lines of text in a similar manner to a line terminal, the output quietly scrolling off the top of the screen instead of being immortalized on paper.
The key thing about either kind of terminal is that they were under the control of the remote computer. The computer was in one of two modes, either sending a message to the terminal to be printed, or waiting for the user to type something. The terminal generally did not send the user's input to the computer until the user hit the "Enter" key. So while the computer was sending data to the terminal, it wasn't listening to anything the user typed; and while it was waiting for input from the user, it wasn't able to print anything else.
This is a bit of a simplification, but from the point of view of someone writing a game, this was the interface you had to deal with. The only way you could communicate information to the user was by printing out text; the only way you could get information from them was to print a message asking them to enter some text, and then wait for it. There was a strict "taking turns" between the computer and the player.
What was missing was interactivity. Interactivity is what almost all computer games now have: the notion that while the player is thinking about what to do next, the situation he is confronting may be changing. It's the way the monsters close in on Pac-Man even if it isn't moving, the way that the spaceships in "Missile Command" move even as you try to target them in the crosshairs, the way your football quarterback is going to get sacked if you stand there after the ball is snapped. In a sense a terminal acts the way a web browser did when the web first appeared: the logic is on the web server, and the browser simply displays text and then waits for the user to click on a link or type in a new URL.
One of the games in the book was called
"Bowling", which was about 100 lines of BASIC. Bowling, after some
introductory messages, prints out
THE INSTRUCTIONS (Y/N)
then waits for the player to type Y or N and enter. If the user types Y, the program prints out 6 lines of instructions. The reason for asking the question first was that printing out 6 lines of instructions might take a significant amount of time - 10 seconds or more - that the player might want to avoid.
After the instructions, the program asks how many
players are playing. It then takes turns letting each player bowl a frame. But
to bowl, all the user does is type "ROLL" when prompted. The computer
then decides what happened with the roll, and prints out the result, something
like this (+ means a pin is still standing, and O means it was knocked down):
O + O +
O O +
Then the computer asks the user to enter "ROLL" again to roll his or her second ball. After each frame, the computer prints out helpful analysis (the number of exclamation points is reproduced verbatim): "STRIKE!!!!!" or "SPARE!!!!" or "ERROR!!!" (meaning some pins were left after the second ball). If no pins were struck, it prints out "GUTTER!!" Then on to the next player, through ten frames. At the end, scores are printed for all players.
People playing the game don't know what logic the computer uses to decide which balls go down on any given roll. They may assume that it randomly decides an initial trajectory, speed and spin for the ball, and then uses some mathematics to model the path of the ball and determine what pins fall as a result, taking into account pins falling into other pins and so on.
In fact, if you read the source code in the book, you discover that the game randomly decides if each individual pin falls, independent of the other pins. This leads to formations like the one shown above (which was taken from an actual test run of the game printed in the book), in which the headpin has fallen, the two pins behind it have not, but some pins behind them have-an unlikely outcome in real bowling.
Given that the players provide the exact same input on each roll of the ball (they always type "ROLL"), the game doesn't need to ask the user for any input at all. It could simulate all the rolls as it does, but without pausing for input between each one, then print out the results of the game. Yet somehow the irrelevant (from the point of view of how the game turns out) detail of prompting the user to type "ROLL" each time creates a real impression that the user is "playing" the game, and makes it a compelling experience.
A more sophisticated game is "Football", which simulates a game of football between the player and the computer. This is a longer game, almost 300 lines of BASIC.
Football is also more interesting in that it gives the player more choice, and is more honest, in a sense, in that it responds reasonably to the player's choices. When the player's team has the ball, the game prints out a message prompting for the next play. The plays are numbered: 1 is a simple run, 2 is a tricky run, 3 is a short pass, 4 is a long pass, 5 is a punt, 6 is a quick kick, 7 is a place kick (field goal attempt). The user types in a number from 1 to 7 and then enter, the computer determines the result of that play and prints it out, the user enters the next play, and so on. When the computer's team has the ball, it picks plays from the same seven choices.
If you read the source, you can see exactly how the computer models the game. For example, kickoffs will go between 30 and 80 yards, but the calculation is set up so that about half the time it will be between 52 and 58 yards. If the kickoff does not reach the end zone, the other team will run it back-the runback will be between 0 to 50 yards, but about half the time will be 13 yards or less.
The computer generates all this randomly; the user has no ability to control the kickoff. But it is significant that the computer does try to do some reasonable modeling of the kickoff, curving the results so that really long or really short kicks are possible but average kicks are more common, and simulating a runback. One alternative would have been to simply generate a number between 0 and 50 and then print "after the kickoff the ball wound up on that yard line." The user might not have been able to tell the difference, but seeing the extra effort in the source code makes the game seem better.
When the player is running a play from scrimmage, the choice of play has an effect on the outcome. For example, a short run will cover between 0 to 6 yards, with a 5% chance of a fumble, while a tricky run will cover between 5 and 15 yards, but with a 10% chance of a fumble. So it goes for the rest of the game. On any given play, there is a 10% chance of a penalty on one team, which is always a 5 yards offside penalty that can be accepted or refused. After a touchdown, the extra point misses 20% of the time.
The computer has two roles in this game. Unlike Bowling, where the player is only playing against inanimate pins, the computer is also providing an opponent for the player. So in addition to simulating the result of plays that are called, the computer also devises a strategy for play selection (and penalty acceptance) when the computer's team has the ball. For example, on first down the computer will pick a simple run two-thirds of the time and a short pass one-third of the time. Other strategies depend on the down, where the ball is on the field, and how much yardage is needed for a first down.
I doubt this was all generated by an exhaustive analysis of how many yards are gained on various plays in a real football game, and what the optimal strategy is for each situation. Nonetheless the resulting game is quite entertaining and feels "right." There is strategy involved in whether to run or pass, whether to try a field goal on fourth down, and so on. The player feels they are playing an opponent with some intelligence, who doesn't try to kick field goals on first down or try a short run on third down and 25 yards to go.
In fact the source code reveals that some extra effort was made to make the game "fun" for the player. When the computer runs a play, the distance is adjusted slightly so that it will only go 96% of the distance that the player's team would have gone. This advantage makes it slightly more likely that the player will win. On a similar note, penalties will not occur if the ball is inside either team's 10-yard line-this must have been viewed as too harsh (or perhaps the programmer did not want to deal with a 5 yard penalty called when the ball was on the 3 yard line).
One thing the game does not have is a running clock. This is because the game was designed for terminals-when the user is being prompted to select their play, the computer isn't doing anything, and so it can't be counting down a clock. What it could do is try to estimate how much time each play takes, and list the current time remaining after each play. But in this particular game, all it does is count the number of plays run. After 50 plays, there is a 20% chance that the game will end after any given play. For amusement, after 30 plays, there is a one-third chance that the program will print out "GAME DELAYED. DOG ON FIELD" before continuing. (There is a comment before this little bit of code that says "Jean's special." The book notes that John Kemeny, a Dartmouth professor and later president who co-invented the language BASIC in 1964, wrote the game. His wife was named Jean, and I assume she came up with the dog on the field idea, which was then immortalized in the source code).
The game could certainly be improved (for example, to let the player do something when the computer had the ball-the only interaction possible at that point is to accept or refuse penalties, otherwise the play calls and results just scroll by). But this is a clever game, and except for a level of interactivity that was impossible back then, it has all the basic elements of a 3-D football game from the present. There are no graphics, the play calling is simplistic, there is no clock, the computer's intelligence is very limited, but there is no doubt that you are playing football against the computer, and you can make good or bad decisions that affect the outcome of the game. The author of the book claims, "I have seen some people elect to play computerized football in preference to watching a bowl game on television."
Back then games like this had to be provided as source code; although there was some distribution of software on paper tape, loading the tape would require access to the central computer itself, whereas most people only had access via a terminal. The fact that the games were provided as source code listings in BASIC meant each reader of the book had to type in the program themselves, and fix any mistakes they made while typing. But once this was done, having the source code had many advantages.
The first was that it allowed people to adapt the games as needed to get them running on their own systems. The language BASIC was not completely standardized, so there were small variations in the version available on each computer system. The listings in the book were for Microsoft 8080 BASIC running on a MITS Altair 8800, which happens to be a later version of the very first piece of software that Microsoft ever sold. There is a brief section at the front of the book with explanations on how to convert the games into Radio Shack BASIC, Apple II BASIC, DEC BASIC PLUS, HP BASIC, SWTPC 6800 BASIC, MSI Disk BASIC, TDL ZAPPLE 8K and 12K BASIC, Sol BASIC (Extended and 5K), PET BASIC, Cromemco 16K Extended BASIC, Ohio Scientific BASIC, IMSAI 8K BASIC, North Star Disk BASIC, PolyMorphic 11K BASIC, and BASIC-E. Rather than provide the games in all these formats, the authors could count on the individual users of these systems to modify them as needed for their computer. If a new system appeared with a slightly different version of BASIC, users of that system could figure out how to convert them. I could take these programs today and get them working on any version of BASIC out there, running on hardware that did not even exist when the book was published.
The second advantage of having the source code available was that it served as an example for others who wanted to write their own software. Someone wishing to write his or her own computer bowling game might be intimidated by the task of starting from scratch. But he or she could take the existing game and start to improve it bit by bit, perhaps first changing the way the pins fell, then maybe giving the user some input on each roll, then adding a running score, etc. At each stage there would still be a working bowling game. At the end there might not be a single line of code left from the original game, and yet the original game would have been indispensable in the creation of the new one. If a novice programmer wanted to tackle a smaller program, they could start out with "Name" (described as "a silly little ice-breaker to get a relationship going between a computer and a shy human"), which is 25 lines long and merely prompts the user for their name, then proceeds to print it out backwards, then with the letters alphabetized.
The final advantage of having the source available
was that each person could modify the game as they saw fit. For example, the
source code listed in the book specified that when the player attempted a short
pass, it would be intercepted intercepted 5% of the time, cause a sack 10% of
the time, be incomplete 40% of the time, and be complete 45% of the time. The
following lines of code controlled this:
1280 IF R<.05 THEN 1330
1290 IF R<.15 THEN 1390
1300 IF R<.55 THEN 1420
It would be quite easy to modify that code to change
the chance of each result occurring. Similarly, a completed long pass would
generate a gain of between 10 and 50 yards, which was calculated by the line
1490 LET Y=INT(160*(R1-.5)^3+30)
It's a little esoteric, but if you took the time to understand it you could easily change the range of yardage, and also how the yardage was curved (the calculation shown gives about a 50% chance that the pass will go exactly 30 yards).
With a little more work, you could change the clock to estimate elapsed time on each play, or give the player some input in choosing plays on defense.
In the mid-1970s the mathematics department at McGill University in Montreal, where my father taught, acquired a minicomputer made by Wang. This computer would certainly be recognizable to today's microcomputer users; it had a big system unit, display, and keyboard all in one case. The keyboard was a big clanky thing, and the display did not show colors or graphics, only green letters. The machine had three 8-inch floppy drives-meaning that the floppies themselves were 8 inches in diameter, or roughly the size and stiffness of a mouse pad today. (The Wang had no mouse. The whole concept of the mouse for a computer was then still mostly confined to the Xerox research lab where it had been invented.) Each floppy held about 25K. The computer cost $20,000 for the basic unit with 4K of memory; the department had spent another $5000 to bring it up to a whopping 20K. In addition, they paid $2,000 a year for a maintenance contract.
My father rarely went in to work on weekends, but occasionally he would, and sometimes as a treat he would bring me in to play games on the Wang (computers were rare enough that you could refer to the machine as "the Wang"-it was the only one in the department). The machine had no hard drive, so to use it you would insert an 8-inch floppy in the machine and turn it on. And once you turned it on, you could play games on it!
The Wang had a built-in BASIC interpreter, just like the home microcomputers of the day from Apple, Radio Shack, and Commodore. The games, which were all written in BASIC, including a bowling simulation. For all I know, the roots of that version of bowling could be traced back to the game in the Basic Computer Games book. If so, the program had been substantially modified to take advantage of the specifics of the Wang. In particular, the Wang could display characters anywhere on the screen, although it could not show any graphics. Therefore, for each frame the computer could display all the pins arranged on the screen. That was merely a small advance over the program from the book, which printed them out on paper. However, the way you bowled was significantly improved. A little vertical line would move across the bottom of the screen. When you thought that the line was in the right spot, you would press a key. The computer would then "bowl" the ball from that spot straight up, by moving a dot up the screen towards the pins. It would calculate the effect that the ball had had on the pins, and display which ones had been knocked down (it did this instantly, there was no attempt to simulate the pins falling over).
There are some key differences from the version of bowling in the book. One is that the user has some control over the results-bowling the ball from different spots generated different results. Another is that the game made some attempt to simulate the physics of bowling. I don't know how detailed the model was (I don't have the source code to the game), but certainly if you hit the headpin straight on you would often wind up with a 7-10 split, and to pick up a single pin for a spare you had to make the ball bowl from in front of it. The scoring had also been improved so that a running score card was displayed near the bottom of the screen.
The most significant difference is that the game was interactive to a small degree. The little vertical line moved across the screen at a constant speed-which means the code had to be specific to the speed of that particular machine. When the line was moving, you had to be alert and hit it at the right time-if you did nothing it would bowl from the far right side and the ball would wind up in the gutter. This is a key difference from all the games in Basic Computer Games.
Football was also available on the Wang. In retrospect this game was obviously based on the game in the book. It had also been jazzed up to take advantage of the Wang-it displayed a crude representation of the football field, drawn with vertical lines, dashes, plus signs, and numbers at the 10-yeard lines. Play selection was similar, and I'm sure the calculation of results was also. The reason I am almost certain that the two versions were related is that the Wang one also had the "dog on the field" gimmick, except that it had been souped up to display the actual word "DOG" moving around the field briefly. It also had a halftime, during which the word "BAND" moved around the field in the same way.
Although this game looked spiffier than the version in the book, in terms of gameplay it was the same. It had not made the fundamental leap into interactivity that the bowling game had.
The final game that I remember playing on the Wang was "Star Trek," an absolute classic of the genre. There was a version in the Basic Computer Games book; at over 400 lines of BASIC it was the longest one in the book. Star Trek divided the galaxy into 64 quadrants in an eight-by-eight grid, and each quadrant into 64 sectors, also in an eight-by-eight grid. Each sector could contain your ship, a star, a Klingon (bad) or a starbase (good). You navigated around the galaxy, avoiding stars, firing at klingons, and docking at starbases. The Klingons would also fire at you, and if you destroyed every Klingon before they got you, you won. It was still not an interactive game; you typed commands to navigate or fire torpedoes, then waited while the computer showed the result of that command.
These games were incredibly crude in a way, but they were also extremely compelling. Even today, with games that feature incredible 3-D graphics, it is generally considered that gameplay-how you can control your man/ship/whatever, and how the opponents are controlled-is much more important to enjoying a game than the graphic display. There are certain thresholds of graphics that can vastly improve gameplay-for example when you can display objects so they can be perceived visually, rather than have to indicate a dog with the letters D-O-G. As you allow the user more control (such as using a joystick instead of typing in numerical commands), you increase the amount of control they have over their own fate and decrease the amount of randomness you need to inject to keep the game interesting (the bowling game as written in the book, in which the user had no actual effect on what happened, was at the opposite end of this spectrum). As the user can do more, this requires you to have more sophisticated intelligence in the computer so it can mimic what the imaginary opponent would be capable of if they had their own joystick.
When you go to see a baseball game, at some point during the game they often have what are called "dot races", where 3 or 4 or 5 objects race around some course on the scoreboard while the fans try to guess which one will finish first. They are called "dot races" because they used to be just that-little dots moving around. Now, with fancier computer-controlled scoreboards, the objects are much more detailed-at Seattle Mariners games they are 3-dimentional-looking hydroplanes. But the actual gameplay is identical to when there were just 3 dots moving around.
The Football and Star Trek games were missing interactivity - the games wouldn't do anything unless you told them to. The computer would prompt you for your next action, you would select it, a result would occur, you would then be prompted for your next action, and so on until the game was over. In the Star Trek game, every turn you took with a Klingon in your quadrant might cause him to fire on you, but it was only once per turn, because while the computer was waiting for you to select your next move, the game wasn't doing anything else. If you went away to get lunch, when you got back it would still be sitting there, and no Klingons would have destroyed you in the interim.
But if you look at the Bowling game, it was similar, in some basic way, to the fanciest computer bowling game available today. The games today have much more control over the bowling, and they probably model the pins much more accurately, and they show the ball rolling and the pins falling in real-time. But the underlying idea is the same as it was back then. And none of this would have been possible without the source code being available to whoever customized the game to work on the Wang.
David Ahl, the publisher of Creative Computing and the person who assembled the games for Basic Computer Games, discusses this phenomenon in the book's introduction, after talking about how fanatical some people have been about playing computer games:
What happens to a fanatical cult when you open the temple doors and let everyone take its source into their own homes? Obviously, we don't know since the temple hasn't been open that long, but it seems obvious that this same generation of kids that can't do manual math or use a slide rule because of the pocket calculator may learn that a TV set [which virtually all home computers used as a display back then] can throw some actively challenging things their way instead of just passive images.
This software was distributed as source code out of necessity, but also with an eye to the advantages of that model. It wasn't called "open source" back then. Few people worried about who owned the copyright on any modifications made - games like this were not viewed as worth protecting. But the same principles and advantages that guide the open source movement today were alive and well, back in 1978.
(c) Copyright 1998-2001 Adam Barr. All rights reserved.
Back to main page.