Using Focus
Chapter 6: Interview: Ed Logg
Overview
Asteroids, Centipede, and Gauntlet. If there was ever an impressive track record for a game designer, that is it. Throw in some lesser-known classics such as Super Breakout, Millipede, Gauntlet II, and Xybots, and you have a truly unequaled career. Ed Logg
designed and developed all of those titles at Atari back in the heyday of the arcades.
Before the collapse of the coin-op market, Logg had already switched to working in home game development, adapting popular Atari arcade games such as the San Francisco Rush series to consoles. Subsequently, Logg took on an original home game for the first time, serving as lead programmer on the unique platformer Dr. Muto. Today Logg has returned to his roots, working on games for mobile phones. To look at them, the classic arcade games seem quite simple, but it is that simplicity which forced their designers to refine them to the point of perfection. Logg’s classic coin-op games remain some of the best computer games ever made, and the insight designers can gain from studying them is enormous.
What was it like working at Atari in the late ’70s and early ’80s?
We were young and energetic. I imagine it is very similar to the atmosphere at most Internet start-ups these days. We were a relatively small group in the Coin Operated Games Division. This allowed everyone to know everyone else. Ideas and pranks flowed freely. Since we were working on a new medium we could do anything and it would be
“new.” Even games like Lunar Lander, done by Rich Moore, which had been done originally years before, were new to our audience.
Where did most of the ideas for the games come from?
The ideas came from many sources. For example, Owen Rubin, another engineer at Atari, told me Nolan Bushnell had suggested to him an extension of Breakout. I took his idea and added many of my own to create Super Breakout, my first commercial success. The idea for Asteroids came from Lyle Rains, who was in charge of engineering at the time. He got the idea from a previous coin-op game. Xybots came from a challenge by Doug Snyder, a hardware engineer at Atari. We wanted to do a multi-player Castle Wolfenstein-like game but we had no “bit-map” hardware. So I created an algorithm based on 8 by 8 stamps and
he did the hardware. Centipede came from a list of brainstorming ideas. Atari would go off- site each year to think up new ideas. One of those ideas was “Bug Shooter,” which was used as a starting point for Centipede.
Management had reviews where they would come in and play the game and give feedback.
Sometimes the consensus was negative and a game could be killed. Most often it would continue until it could be “field tested.” This meant it was left to the players to determine how much and for how long the game earned. However, sometimes good suggestions came from these reviews. The most important one of all was a suggestion made by Dan Van Elderen, who was in charge of engineering. He asked me why we could not shoot the mushrooms in Centipede. Yes, the mushrooms were originally static. It was his suggestion that led to the breakthrough that made this game fun.
Were you excited to get into game development at Atari?
Actually, I had been doing games for many years on the side, while in high school, at Berkeley in the ’60s, and also at my first job at Control Data Corp. I ported Star Trek and the original Dungeon game between Stanford’s and CDC’s computers.
I had built a home computer a year or two before joining Atari, just to create and play games. I had been to a Pizza Time Theater and played Pong and Breakout, so I was well aware of the coin-op business. I had also played games and was very inspired by a
prototype of the Atari VCS (2600) at a Christmas party in 1977. So the change in
employment seemed natural for me. At the time I thought it was great for them to pay me to create and play games.
Asteroids
Dirt Bike was your first game for Atari, but I understand it didn’t make it into production. What sort of game was it?
This game was started by Dennis Koble who went on to do many consumer titles. It was a game similar to Sprint except you drove a dirt bike and the control was a set of handlebars
that could be used to steer the bike instead of a steering wheel.
We field tested the game and it earned enough money to make it good enough not to kill outright but not good enough to make it into production. However, I had made Super
Breakout at the same time I was working on Dirt Bike. No one at Atari had ever worked on two games at once before. Super Breakout had earned a large amount of money, and this probably led to the decision not to build Dirt Bike. I was not disappointed considering the success of Super Breakout.
What was the genesis of Super Breakout?
The original idea included six variations on Breakout. I envisioned three released games with two variations in each game. However, in actual play there was one overall favorite:
Progressive Breakout. In the end we put three variations in one game: Progressive, Double, and Cavity Breakout. The variations that did not make it were more vertically oriented and I had to agree they were not as fun.
Were you given a lot of creative freedom on Super Breakout, or were you constrained since it was a sequel to a previous hit?
To me, Super Breakout was not a sequel. Remember, the original game was not done in software. The code had to be created from scratch and the gameplay was completely different from the original even though we used the same controls.
I was given freedom because I was doing the title without any official sanction. It was not the last time I would do that, either. Games could be done in a short time in those days, which meant you could make something fun before anyone even noticed you were doing anything different.
Maybe I should explain how we were developinggames in those days. We had one main Digital computer which had the cross assembler for our 6502 based games. We had
several gals who would enter our handwritten pages into our programs and give us back a computer printout and a paper tape. Yes, you heard that right. We would then feed the paper tape through our development system into the RAM replacing the game ROM on the PCB. We would debug this using primitive tools and a hardware analyzer and write our changes on the paper printout. Since this process left time between the debug session and the next version, I used this time to develop a second game. I would just swap the graphics PROM (yes, we created the graphics by hand ourselves), and load the new paper tape.
Super Breakout
That’s really astonishing that you ever developed a game using such primitive methods. How did you manage to fine-tune your game with such a long time between versions?
Well, actually, I was very good at just patching RAM with new instructions, so it was easy to see what small changes did to the game. We also had an HP analyzer that we could use to trap on many conditions, which allowed us to find many bugs that many development systems cannot even do today. Actually it was possible to do some new coding while you were waiting for your last changes to be made, so less time was lost than you think.
But you would certainly agree that modern development tools have made game development easier?
There are several issues here. First, back then we often knew everything about the target hardware, which made it easier to see what was going wrong. Today, the target hardware is often hidden from us and there are several layers of software, which can make
debugging or doing what we really want to do difficult. So in this sense it is much harder now. Also, these modern software or hardware layers are often not documented,
documented incorrectly, or just getting in our way. Second, the hardware has gotten very complex with interactions between the many bytes causing all sorts of problems. Third, the processors have become very complex, causing all sorts of debugging nightmares,
especially in dealing with the caches. Fourth, today there are many programmers working on a game and it is easy to mess up one of your coworkers.
Surprisingly, the development environment has not gotten any faster over the past few years despite the great increases in the computing power and RAM. As an example, some of my files on my 25 MHz Mac IIci with 6 MB of RAM compile and link in the same time or faster than files on a 550 MHz PC under NT with 512 MB of RAM. Even the same project on my 150 MHz Indy builds faster than my 550 MHz PC. I firmly believe that every tool developer should be given the slowest possible system to use to develop their software!
Otherwise, we are doomed to continue to run no faster with each new upgrade.
The modern tools are so much better than the old method, it is hard to imagine how I could have done so well, but you mustn’t forget how much time is spent learning each new
software tool, processor, and operating system these days. In addition, the amount of time wasted chasing after bugs on new systems because I did not understand some other
hardware or software is quite large. But I would not want to go back to the old tools unless the processors, hardware, software, game concepts, and team sizes were much simpler.
I’ve never seen your next game, Video Pinball. How did it play?
It simulated pinball by using a half-silvered mirror with a monitor below the mirror and the graphics for the play-field above the mirror. The monitor would show the flippers and ball, which gave the impression the white ball was on the play-field. The play-field actually had LEDs controlled by the program which simulated lit targets. In addition, the control panel was hinged, which allowed the player to “nudge” the cabinet to give the ball some English. I did not think this game up. I believe it was Dave Stubben’s idea.
How did you hope to convince players to play Video Pinball instead of the real thing?
I did not believe Video Pinball would be successful and I was asking that exact question.
However, there were places video games could go that a large pinball game could not. In the end, the game earned more than I had expected and it was a commercial success. I must say I was wrong on my first impressions, and that does not happen often.
Was it hard to work on a project that you did not think would be any fun? Did the final game turn out to be entertaining?
The gameplay was fun but no comparison to a real pinball game. I was surprised that it sold as well as it did. Yes, it was hard to work on an idea that I did not think would work well. But I was young and motivated… What else can I say?
Where did the idea for Asteroids come from?
Lyle Rains had suggested to me the idea of a game where the player could shoot asteroids because there had been an earlier coin-op game with an indestructible asteroid that the players kept shooting instead of pursuing the intended goal. I told Lyle we would need a saucer to force the player to shoot the asteroids instead of wasting time. I also suggested breaking the rocks up into pieces to give the players some strategy instead of just shooting the larger rocks first.
Lyle gave me the idea. People often attribute the success to one or the other of us. I would probably not have come up with the idea on my own, and if someone else had done the game it would most likely have been totally different. So in truth, we should both be given credit for this idea. Come to think of it, without the vector hardware, Asteroids would not have been a success either. So there are many people and events that led to its success. I
am very glad to have been there at that time and place.
The game changed very little in development from the original idea. I did make two saucers, one dumb and one smart. I made one fundamental change near the end of the project that had far-reaching implications. Originally, the saucer would shoot as soon as the player entered the screen. Players complained — and I agreed — this seemed unfair. Often the saucer was not visible just off the edge, and if it started next to your ship you had no defense. So I added a delay before his first shot. This, of course, led to the “lurking”
strategy. While testing, I had actually tried to lurk at one point and decided it was not going to work, which shows you how well the game designer can play his own game.
Asteroids
Were you surprised by Asteroids’ success?
I was not surprised by its success. It sounded like a fun game when I played it in my mind.
Even after the first few weeks, people would come by and ask when they could play. That was a sign your game was fun!
Even when we field tested the game for the very first time, I saw a player start a game and die three times within 20 seconds. He proceeded to put another quarter in. This tells me the player felt it was his fault he died and he was convinced he could do better. This is one of the primary goals a game designer tries to achieve and it was clear to me Asteroids had
“it.”
Back there you mentioned that you played the game out “in your mind.” Do you find that to be an effective technique for predicting whether a game will be fun or not?
It is a skill which I find works well for me. I also play devil’s advocate with my ideas. I ask myself, “What can go wrong?” or “Will players be confused by what I am presenting?” I find that some designers often are so married to their ideas that they will not accept the
concept that maybe it just won’t work. I cannot tell you the number of great ideas I have had that I “played out” in my mind that turned out to be bad ideas.
I am one of the few designers I have ever met that has actually killed many of his own games. I think this is a good trait. Why waste another year to two if the gameplay does not play like you expected?
Did you work on the sequel, Asteroids Deluxe?
I did not do Asteroids Deluxe. It was done by Dave Shepperd. I was promoted around that time into a supervisor role. I believe I was also leading the four-player Football project. So I was busy. I have no problem doing sequels if that is the best course of action. I had some new ideas, so I wanted to do Millipede. Gauntlet II was a logical choice since Bob
Flanagan, my co-programmer, and I knew the code and this was the best game concept we came up with.
Asteroids
After Asteroids you didn’t make another vector-based game. Did you not like working with the hardware?
Actually, I loved vector hardware for the reason it allowed me to put up high-resolution 1024 by 768 graphics. However, the industry was just moving over to color monitors at the time.
Dave Theurer did do Tempest as a color vector game, but the color mask on color monitors did not permit high resolution. Besides, you could not fill the screen with color on vector- based games, so that medium died with the advance of color games.
Wasn’t Asteroids the first Atari game to have a high-score table?
Actually, Asteroids was not the first game; there was another game that used it just prior. I thought the idea was a great way to preserve your score and identity for the world to see.
So I added it to Asteroids. I see it as filling the role of graffiti. Now it is standard, of course, and the industry has added battery-backed RAM or EEROM to save it permanently.
Around this time you created the Othello cartridge for the Atari 2600. I understand you studied AI while at Stanford. Did the Othello project grow out of your interest in
AI?
No, actually Asteroids showed more influence from my Stanford experience. While I was at the Stanford AI Lab, I had played Space War on their PDP machines. I had also played a coin-op version of this in the Student Forum coffee shop. In my mind, this was the first video game. Pong certainly was the first commercial video game. Anyway, the spaceship design in Asteroids was a copy of the original Space War ship.
I had played Othello as a board game and I was intrigued by possible strategies. So I worked on this game at home and developed an idea that the game could be played by pattern matching without any AI. In other words, the computer does not look ahead at your replies to any of its moves, which was the standard AI approach at the time. So really the Othello game I did had no AI. It was good enough for the beginner and average player. It was not an advanced game by any means. Besides, the 2600 had only 128 bytes of RAM so there was not much space to look ahead.
In fact, Carol Shaw had done the hard part by providing me the kernel which drew the pieces on a checkerboard. The 2600 was extremely difficult to do anything complex on. It was intended to do Pong-style games. You spent all of active video counting cycles to draw the screen. This left Vblank to do any thinking or other work. There was limited RAM so nothing complex could be saved in RAM. Othello was 2,048 bytes. Most of this was the kernel. So I often spent time trying to eliminate a few bytes to add something new.
Was Centipede your next game?
No, as I mentioned I was a supervisor at the time. I was project leader on four-player Football and a kit to upgrade the plays on the original Football game.
On Centipede, I thought up the idea of the centipede segments and the way the legs
moved. I do not believe it was mentioned in the original “Bug Shooter” brainstorming idea. In fact, no one has ever stepped forward to claim “Bug Shooter” as their idea.
Maybe it was due to the finished product being so much different from the original idea. I had assigned a new programmer, Donna Bailey, to do the programming on Centipede.
Partway through the project, I quit being a supervisor (I didn’t like the job and it took me away from doing games) and spent time working on Centipede.
So Bailey was pretty important to the game’s development?
I would guess she did about half the programming. The game design was left to me because she was working on her first project.
It seems that Centipede appeals to women more than most arcade games. Do you think Bailey had something to do with that?
I wish I knew the answer to that question. Someone could point out that no other game I