David Crane Interview: Pitfall!, Activision, and Programming the Atari 2600

David Crane put his name on a game box because he was willing to stake his reputation on what was inside. Players have since told him they would buy one of his games knowing who made it, much as a reader reaches for a favorite author’s next book. That connection was something he and his fellow Activision founders deliberately built. The programmer, artist, and designer behind a cartridge deserved a credit, and the person buying it deserved a game polished enough to justify their trust.

His career began with the close relationship between electronics and programming that made the Atari 2600 such an unusual machine to work with. A new display technique could suggest an entire game. When David found a way to make a larger, multicolored object, he wondered whether it could become a convincing race car. That experiment led toward Grand Prix. When he developed a display of six high-resolution characters, he recalls TIA chip designer Jay Miner standing behind his development station and admitting he had not known his own chip could do it.

Leaving Atari to help create Activision gave David and his colleagues the freedom to publish games their own way. They shared techniques, showed off discoveries, and worked to make their cartridges look and play better than the competition. Pitfall! became David’s best-known creation, but the same period also produced work as different as Dragster, Freeway, and Grand Prix. He is frank here about those games, including the ones he now finds repetitive, and about how much effort went into the final adjustments a player might never consciously notice.

The range grew as he moved to other machines and other kinds of play. Ghostbusters let him build within a film’s universe, with freedom from the studio to work out what the game should be. For Little Computer People, he spent a year giving an initially passive concept behavior and interaction. A Boy and His Blob grew from another practical question: how could an adventurer use different tools without repeatedly leaving the action for an inventory screen? The answer became a companion, a backpack of jellybeans, and some wonderfully strange transformations.

Across Atari, Activision, Absolute Entertainment, and his later work, David kept returning to the pleasure of making small games with small teams. By his count, his career has taken him through around 100 published games, more than 20 systems, and more than 20 programming languages. It also reached players through their web browsers. He and Garry Kitchen created the Candystand and Nabisco World sites, and David speaks fondly of what they accomplished with Shockwave in Candystand Billiards. He also points out the frustrating part of that history: when the servers disappeared, many of those games became unavailable.

Today, David is making Atari 2600 cartridges again with Garry and Dan Kitchen through Audacity Games. That means designing the games and recreating the complete package, from cartridge shells to color boxes and manuals. The old programming knowledge came back immediately, while larger ROMs have opened possibilities he could not afford in the early 1980s. His description of generating QR codes on the console, complete with error correction, is a particularly good reminder that he is still finding demanding new things to make this hardware do.

We are honored to welcome David to Retro Replay for this 45-question conversation about a career spent designing, programming, building hardware, and putting finished games into players’ hands. He shares the discoveries, compromises, collaborations, and painstaking polish behind the work, with plenty of stories from well beyond the jungle.

Interview by David Becker for Retro Replay. Answers have been lightly formatted, with obvious typos corrected at David’s invitation.

For the story behind Harry’s first two adventures, read The History of Pitfall!: Building a Jungle in 4K, from the running-man animation and mathematical jungle to the extra hardware inside Pitfall II.

Still making games for the Atari 2600

Retro Replay: Before I drag you back to Atari in the 1970s, what are you actually working on or interested in these days? Are you still actively designing or programming for original hardware?

David Crane: With Garry Kitchen and his brother Dan I am still actively designing games for our favorite system, the Atari 2600. Yes, it is the hardest game console for making great games, but it is so challenging that there is no higher sense of achievement when we actually do so. With the renewed interest in retro gaming, we created Audacity Games to recapture the magic of opening Pitfall! On Christmas morning 1982, with the same quality complete in-box games (cartridge, color box, color manual, color cartridge label, etc.)

Retro Replay: Your background was in electronics and hardware as much as software. Do you think understanding what was happening electrically inside a machine gave you a fundamentally different approach to game programming than someone coming purely from software?

David Crane: For me, having an understanding of the hardware gave me a leg up when making the hardware do things that the chip designers never imagined. Other game designers came from purely computer science backgrounds, but I was always happy to have my hardware expertise to rely upon.

Hardware tricks, six digits, and a single machine cycle

Retro Replay: You have described Atari 2600 design as almost the reverse of modern development: rather than inventing a game and then implementing it, you first figured out what the hardware could possibly do and then tried to turn that into something fun. Was discovering a new hardware trick sometimes the actual beginning of a game idea?

David Crane: More often than not, I started a game project looking for new ways to manipulate the hardware. When I found something, it usually took me in the direction of a type of game that was made possible by the technique. But the game design came pretty quickly, such as with Grand Prix. “Using this technique I can make a game object four times larger than the normal sprite, and every line of the object can be a different color. I wonder if I can make a good-looking Indy-style car?” After that, it is a matter of 1000+ hours of art and program design.

Retro Replay: Did Atari programmers openly exchange those tricks with one another, or was there some competitive instinct where programmers wanted to keep their newest techniques to themselves?

David Crane: Within the same company we would proudly show off each new trick among the programmers. As a result, the state of the art expanded, with each game designer having the new trick as a tool for future games. Once there were multiple competitors in the business we would keep the tricks to ourselves, although once a game was public a good programmer could immediately see what was done. 99% of invention is believing something can be done, and once it was demonstrated others figured it out.

While working at Activision I once ran into a group of Imagic designers at a local Sunnyvale mall food court. They complimented me on the technique used to make Dragster. They then admitted that they didn’t exactly know how it worked, but that they disassembled the code from my ROM and were using it in their games.

Retro Replay: Was there a particular 2600 trick you discovered where you remember thinking, “The people who designed this machine never expected anybody to do this”?

David Crane: While at Atari I had figured out something of a Holy Grail – the ability to create a display with six high-resolution characters. This technique was later used throughout the industry to put a six digit game score on the screen. (Before this every game had two digits of score on the left for player one, and two digits of score for player two on the right, all digits formed from low-resolution blocks. See Combat, Air-Sea Battle, etc.). This technique is commonly referred to as the “six-digit score kernel” and can be found in almost every game published after 1978.

As I was developing this technique, and finally had it on the screen at my design station, I felt someone behind me. I looked back to see Jay Miner (the lead designer of the 2600 TIA chip) shaking his head. He told me “I had no idea my chip could do that.”

Retro Replay: The 2600 famously gives the programmer enormous responsibility for generating the display essentially line by line. Did writing for it eventually become almost instinctive, where you could mentally visualize how many processor cycles an idea was going to cost?

David Crane: Every good 2600 programmer has a mental 2600 emulator and can envision what the 2600 can do. And yes, we all know the number of machine cycles used by every 6502 instruction. But you still have to write out the program flow and count the total cycles for each loop. The hardest situation is when you branch into separate code to handle different conditions, and are sometimes required to make each loop take the exact same number of cycles before returning to the main loop. Failure to account for even a single machine cycle can completely destroy the game screen.

Retro Replay: Did you ever find yourself counting cycles or solving programming problems away from work, lying in bed, driving, eating dinner, because there simply wasn’t enough processing time to waste?

David Crane: It was very common to go to sleep working on a problem and wake up with the solution. There have been countless times where I have ‘slept on a problem’ only to come up with some convoluted way to save one machine cycle. Of course, it might take two days to implement that solution before knowing if it really helped.

Retro Replay: You have said that programmers in that era had to possess both technical and creative skills because the design and implementation were inseparable. Do you think something valuable was lost when game development became specialized enough that designers no longer necessarily understood the hardware beneath their ideas?

David Crane: Games have become so complex that no one person can make a game for modern game consoles. The best Retro games happened because the entire game concept and flow came out of one mind, so that every part of the game was consistent with every other part. With a large team, in my opinion the lead designer should drive all creative decisions. Even then, a level designer, for example, might create a game level or layout that follows different rules. That would be bad and hopefully caught and reverted. So yes, something valuable was lost, but that was unavoidable based on the increasing complexity of games.

Activision, the name on the box, and the work behind it

Retro Replay: When you left Atari to help create Activision, you were not merely starting another game company. You were challenging the idea that the console manufacturer should control who could publish games for its machine. Did you realize at the time how important third-party publishing would eventually become to the entire industry?

David Crane: We were well aware that the corporate expertise to create a game console was unlikely to include the expertise to make games for the console. Nobody needed to know how to make a record player in order to compose a song. The third-party publishing industry came about largely due to Activision’s success, although if it wasn’t us it would have been somebody else. In the hopes of repeating Activision’s success, a myriad of third-party publishers sprang up. It was only natural that this would become the entire industry.

Retro Replay: Atari’s management famously did not initially treat individual game designers as particularly important to product sales. How much of Activision’s decision to put designers’ names and photographs prominently on packaging was a deliberate response to that attitude?

David Crane: It was a founding principle of Activision to credit the game designer in the same way the book or record publishing industries would do so. The fact that Atari didn’t do so seemed absurd to us, so when we started a competing publisher we did what we thought was right. When you start your own company you can do things the way you think they should be done. It was more about the right way than the non-Atari way.

Retro Replay: Once players actually began recognizing names like David Crane, Alan Miller, Larry Kaplan and Bob Whitehead, did that change your relationship with the audience? Did it feel strange becoming recognizable for writing software?

David Crane: It is a common misconception that we were treated as ‘rock stars’ and mobbed by fans. (I liked to joke that even if that was to happen, the mob would consist of 10-year-old boys rather than the mobs of girls that one associates with male rock stars.) We attended industry trade shows twice per year, and at a targeted event like that as many as 100,000 people might have known my name, but outside specific video game related events nobody had any idea who we were.

That said, by putting my name on the box I was letting players know that I felt the game was that good – good enough for me to risk my reputation. There have been many times that game fans have told me that they would always buy my games, confident in the quality. In a similar way I will often buy a book from one of my favorite authors. Whether using the written word or writing software we both create entertainment, and we put a lot of ourselves into the work.

Retro Replay: Activision’s early games also had a distinctive visual identity and level of polish. Was there an internal culture of programmers trying to impress one another technically?

David Crane: As the upstart company in the game business we strove to make our games look and play better than the competition. After all, we had to get noticed. So we were careful to use the best color schemes in our imagery. And unlike Atari, we had no arcade game hits to rely on, which meant we had to create new game concepts from scratch. We were all avid gamers, so we simply made games that as players we found great fun to play. Some of us specialized in coming up with new technological ways of using each game console, and yes, doing something that impressed the rest was very rewarding.

An eight-pixel runner and a jungle in 4K

Retro Replay: Before Pitfall!, you created the running-man animation that would eventually become Pitfall Harry. What interested you about making a human character move convincingly at a time when so many game characters were still little more than blocks or symbols?

David Crane: Creating the little running man (that became Pitfall Harry) began as a technical and artistic challenge. How can I make a recognizable human figure using 8 pixels? Once created it was only natural for that character to become the player’s avatar in a game. Like almost every innovation in the history of gaming, it was a simple evolution from inanimate main characters to human-like avatars, particularly as the console capabilities improved.

Retro Replay: When you finally found the game that belonged around that running character, did the idea for Pitfall! really arrive rapidly, or had years of smaller technical ideas quietly accumulated until everything suddenly connected?

David Crane: Once I had a running man that I liked, the game flow came together in 10 minutes. I sketched him on a path through the jungle with obstacles, enemies, pickups, etc. The rest was just hard work making a compelling game on the limited Atari 2600 system with only 4K bytes for every line of game logic, every sound effect, world layout, and every pixel of art.

Retro Replay: One of the most extraordinary things about Pitfall! is that an apparently enormous 254-screen world could exist inside a 4K cartridge. When you developed the mathematical system that generated that world, did you think of it as compression, procedural generation, or simply the only practical way the game could exist?

David Crane: It was all of the above. It was a method of procedural generation of the world, massively compressing the world layout, and the only practical way to have more than a few screens of jungle for game play. The 4K byte ROM was a hard limit in 1982 due to cost, and if I spent even 16 bytes per screen there would be no ROM left for game logic, sound effects and art.

Retro Replay: You have spoken about repeatedly rewriting Pitfall! to get the finished game down into the available ROM space. When you are fighting for individual bytes, how do you decide whether to simplify the code, remove a feature, or find a completely different mathematical solution?

David Crane: By far the best strategy is to figure out simple changes to the code to use fewer bytes to do the same thing. By the time we were trying to get the game down to fit in the ROM there had been months of play testing – both during development and by other players. Introducing new bugs in the code when reducing its size was a major concern. The first tactic was to use the microprocessor registers more efficiently. If you notice that a register has a known state at the completion of the previous routine, you could rely on that value at the beginning of the next routine (skipping the initialization of the register). This is a TERRIBLE programming method – even if you comment it thoroughly – but it was absolutely necessary when trying to reduce the size of the code without changing the operation. We almost never removed a feature, agonizing over multiple rewrites to do the same thing with fewer bytes of code.

Retro Replay: Were there features cut from Pitfall! that you still remember because you simply could not find enough bytes or processor time to keep them?

David Crane: Every game is a tradeoff between ROM, RAM, and time. The game was not released until it had what seemed to be the best mix of features possible given the constraints. I put what I considered to be the best features in the game. I don’t remember any rejected features that I wish I had swapped in for any others.

The players who went the other way

Retro Replay: Pitfall!’s world loops around on itself in a mathematically consistent way. Did players discovering maps and optimal routes surprise you, or did you expect people would eventually treat the jungle almost like something to be charted?

David Crane: I have often joked that I have held the world record in every game I made – at least until the game was released. After that some player found a way to play my game that was different from what I expected. With a million kids playing, that was inevitable. The best-known example is that I designed Pitfall to run from left to right. But the game was easier right to left since if you died on an obstacle your new ‘Harry’ dropped on the left side of the screen PAST the obstacle that killed you. We worked hard to make sure there were no holes in our games, such as a place you could hide and shoot everything at no risk, scoring a million points. But it was inevitable that subtle differences in how you play a game would affect the scoring.

Retro Replay: The underground passages also act as shortcuts through the world. Were you deliberately giving experienced players a way to master the geography rather than simply survive individual screens?

David Crane: I set the game’s time limit so that you couldn’t reach all of the treasures in the allotted time if you stayed on the surface. The underground passages were shortcuts to make it possible to complete the game, but they were not free. The scorpions were intentionally the hardest enemy to jump over. You had to brave the scorpions to complete the quest.

Retro Replay: When Pitfall! became such an enormous success, what surprised you more: the sales themselves or the degree to which players connected with Pitfall Harry as an actual character?

David Crane: Pitfall was widely considered to be the prototypical platform game. Early in development I could see that the multi-screen platform-style adventure game was going to be hugely popular. It allowed players to use their imaginations, wondering what was on the next screen. Pitfall’s success was in part due to this feeling of discovery, and its well-tweaked game play delivered on the promise.

Pitfall II and the hardware inside the cartridge

Retro Replay: Pitfall II is especially fascinating because rather than simply accepting the limits of the Atari 2600, you designed additional hardware for the cartridge itself. At what point did you decide, essentially, “If the console cannot do what I need, I’ll change the cartridge”?

David Crane: We loved the Atari 2600, despite (or perhaps because of) the difficulty of making games for such a limited console. New consoles were on the market with more capability, and the lowly 2600 was looking long in the tooth. I created the DPC chip, which was arguably one of the first GPUs designed for a game console, to try to extend the life of the 2600. Due to the added cost, and the looming crash in the video game market, the DPC was only used for Pitfall II, and the 2600’s fate was sealed as the NES took over the world.

Retro Replay: Did designing the Display Processor Chip feel like returning to your earlier hardware-engineering roots?

David Crane: I trained as an electronic engineer, and frankly when considering a job at Atari I was not sure I wanted to exclusively do software. I solved that quandary by dabbling in hardware every chance I got. I ended up creating hardware systems to aid in game development, EPROM programming, and other places where I could improve the game making process. Designing the circuit that became the DPC was a natural extension of my hardware dabbling.

Retro Replay: How much did that additional hardware change what you could do in Pitfall II compared with what would have been possible using an ordinary cartridge?

David Crane: Creating a game display on the 2600 was limited by how much data you could fetch and store to the TIA display chip during a single TV scan line. The DPC provided auto-incrementing data fetchers specifically tailored to the task. While I was at it I added a music generator with 3 part polyphony (4 part if you used the second 2600 sound channel as a snare drum). Even ignoring the ability to have actual music on the 2600, the ability to push more data to the TIA made more detailed images possible.

Retro Replay: Do you think cartridge enhancement hardware is one of the most overlooked parts of early console history? The machine sitting under the television remained the same, but increasingly clever cartridges could effectively extend what that machine was capable of.

David Crane: As you say, once a game console was sold and taken home it cannot change. But when you plugged in a new game cartridge you were replacing the game-specific half of the system, even if only with a new program. If you think of the game cartridge as a console upgrade, it was only natural to add capability to the game cartridge so that the console upgrade included more than just a new program ROM. I’m not sure this was particularly overlooked any more than the fact that most game players have no idea what is going on inside the game console. They just love that they can play ever improving games.

Making a game in the Ghostbusters universe

Retro Replay: Ghostbusters presented a very different challenge because you were adapting a major movie property rather than creating an entirely original game. How much freedom did you actually have to decide what a “Ghostbusters video game” should be?

David Crane: The studio left us completely alone, other than making sure that we followed established Ghostbusters imagery. After all, Activision had the best reputation for game quality. It was smart to leave the process of making a game to the experts.

Retro Replay: Was translating a movie into several different gameplay systems more difficult than beginning with a completely blank page?

David Crane: The best way to make a game about a movie was to make a great game and then place it in the movie universe. So it was exactly like beginning with a blank page. If anything it was a little easier since I didn’t have to also create a new universe.

Giving Little Computer People a life

Retro Replay: Little Computer People feels remarkably different from almost everything else being made at the time. Where did your interest in creating something that behaved less like a conventional game and more like a little autonomous inhabitant of the computer come from?

David Crane: The concept (including the initial images and character animations) for Little Computer People was brought to Activision as “Pet Person,” designed by a content creator in LA who envisioned a non-interactive fishbowl on the Commodore 64. As designed, it was basically a screen saver. I got excited at the prospect of adding AI and interaction to the product, really bringing the LCP to life. I tore the product down to its core and spent a year giving the characters interactivity and brains. We all knew that we were creating something new that would never be a conventional game. I was quite proud of how it came out.

Retro Replay: Looking at virtual pets, life simulations, and games where players observe characters with routines and personalities, do you see any descendants of ideas you were experimenting with in Little Computer People?

David Crane: In video games, as probably in any creative field, we are all inspired by work that has gone on before. Will Wright has said that in creating “The Sims” he had experienced my work in “Little Computer People,” but as I say that is entirely natural in the evolution of video games. Frankly, I would have loved to follow LCP up with bigger and greater projects, but it was not a direction Activision was going.

Jellybeans, a transforming companion, and bigger plans

Retro Replay: A Boy and His Blob is another unusually distinctive concept. Where did the central idea of feeding different jellybeans to Blob to transform him into useful objects actually come from?

David Crane: People often ask what drugs was I on when creating the concept behind “A Boy and His Blob.” (The answer is none.) How does one arrive at a shape-changing blob creature from the planet Blobolonia who changes shape based on the flavor of jellybeans? It is an iterative process. I set out to make a Pitfall-like adventure game, but one with the ability to use tools, similar to the way a sword and sorcery story with characters allowed the use of swords, knives, bows, etc. I didn’t like how in that game genre you had to leave the game to pull up an inventory screen to choose weapons. I used a shape-changing blob inspired by a 1960s cartoon to act as a companion, and created a mechanism where you could control the blob’s transformations without leaving the game screen. Why jellybeans? Who knows. But having a backpack containing a limited set of flavors allowed me to control the inventory. One thing led to another until the final storyline evolved into the final product.

Retro Replay: Do you think puzzle design becomes more interesting when the player has a small set of understandable rules, such as the jellybean transformations, but many possible ways to combine them?

David Crane: Maybe. A video game is an interaction between the player and objects in the game world. We give the player’s avatar ways to interact with the world, and tweak the difficulty until it is a fun mix of challenge and reward. It certainly makes for a more interesting game when each player can find different ways to accomplish the same goals.

Retro Replay: You have said that you once hoped A Boy and His Blob could become much larger than a single game, including toys and animation. Is that the project from your career where you most wish you had been given additional resources to pursue the larger idea?

David Crane: That would have been fun. To this day people tell me how much they enjoyed playing “A Boy and His Blob.” During development we considered blue-sky ideas of creating a feature film and a plush toy line. If we had been able to pull off those stratospheric ideas the Blob may have been as big as Pac Man. But I don’t spend a lot of time pondering what-ifs.

Small teams and a return to the 2600

Retro Replay: Across Atari, Activision, Absolute Entertainment and your later companies, you have experienced both the tiny-team era and increasingly large commercial game development. Was there a point where the industry became large enough that making games stopped being as enjoyable for you?

David Crane: I have always enjoyed small games and small teams. The main reason for this is that in my opinion the best games come when every element of the game is kept in one mind. How else can every element of the game be consistent with every other? That can only be done with small projects. Of course, one mind can still coordinate a large team, and I have done that, but for me the real enjoyment comes from actually creating the interaction that leads to fun game play.

Retro Replay: Decades later, you returned to the Atari 2600 through Audacity Games and Circus Convoy. What was it like opening that mental toolbox again? Did 2600 programming immediately come back to you, or did you have to relearn tricks you once knew instinctively?

David Crane: In the intervening years I have published around 100 games on more than 20 different consoles and systems, and in more than 20 programming languages. And yet returning to making games for the Atari 2600 felt as if I never left it. I can still tell you the hex value of most of the 6502 opcodes and read 6502 code as well as my native English. I still have command of every programming trick I used back in the day, and get the same reward when making something cool show up on the screen. Who knew that such esoteric knowledge would never be lost?

Retro Replay: Modern development tools obviously make writing and debugging 2600 code easier, but does that remove any of the fun? Was part of the original experience precisely that everything was difficult?

David Crane: Modern tools do not make anything easier, just faster. And by that I do not mean that game development is faster, just that modern computers process thousands of times faster. There was a time in Activision’s first few months that assembling a 2K game took 30 minutes. Today a 128K program assembles before my finger leaves the ENTER key. You imply that we found the difficult tasks of yesteryear was fun or rewarding. That was never the case. If anything, overcoming difficulties gave the most reward. Programming for Atari 2600 is no different (or less difficult) than it was in 1977.

Retro Replay: When creating Circus Convoy, were there things you could do on the 2600 today that you never would have attempted in 1982 because modern assemblers, emulators, debugging tools, and decades of accumulated knowledge make experimentation easier?

David Crane: In most ways creating Circus Convoy was the same as every game I have ever developed. Making a game is an iterative process, adding features because I think it would be a fun thing to do in the game, and then trying it out and only keeping the features that really work. While developing Circus Convoy, Garry Kitchen and I kept adding features until it was the best game either of us had ever created. Modern emulators and debugging tools were a small part of the process.

Retro Replay: Has returning to the 2600 taught you anything new about the hardware itself, or do you feel that you and the other early Atari programmers had already pushed it about as far as it could reasonably go?

David Crane: When we created Audacity Games to publish complete-in-box games for the 50 year old Atari 2600 we had to recreate every aspect of the early Activision. That meant making a mold for injection-molded cartridge shells, color boxes, labels, manuals, etc. For inside the cartridge we needed a PC board with a ROM and other circuitry. In 1982 I made Pitfall in a 4K byte ROM. The smallest ROM I could buy for our new cartridge was 128K bytes.

I believe that those of us making games in the 1980s had pushed the 2600 hardware as far as we could using a 4K byte ROM. Today, with 32 times as much ROM there are definitely tricks that we can do that we never considered in 1982. Stay tuned to see how far we can take the 2600 without the severe ROM limitation.

Retro Replay: One thing I find fascinating about new games for original hardware is that the audience now understands the machine’s limitations. Does that change the relationship with the player? In 1980 you were trying to make people forget the limitations; today part of the fun is often knowing exactly how impossible something should be.

David Crane: The retro-gaming community generally has more knowledge of the limitations of the 2600 but that knowledge varies widely. What they DO know is what 1980s games looked and played like, and they can view the differences through that lens. Nearly everyone who looks at Audacity Games’ new products say “I’ve never seen a 2600 game look like that!” We still work to make sure that one’s enjoyment of the game is not affected by the limitations of the system.

QR codes, Candystand, and the games beyond Pitfall!

Retro Replay: Of all the technical achievements in your games, is there one piece of code, algorithm, hardware trick, or design solution that programmers would appreciate more than ordinary players ever could?

David Crane: All Audacity Games products include the use of QR codes for game registration, in-game guides, and high score submission. This is one of the more fun parts of our modern games, essentially attaching the Atari 2600 to the internet through your smart phone. Creating that QR code is the hardest bit of programming I have ever done on an 8-bit microprocessor. In addition to displaying a QR code on the 2600 screen, which is hard enough, a QR code includes a Reed-Solomon Error Correction algorithm that requires the computation of a 22 term polynomial (i.e. aX to the 22nd power, plus bX to the 21st power, plus cX to the 20th power, etc.) on an 8-bit microprocessor. Forget X to the 22nd power, the 6502 can’t even multiply. As simple as it may look to put up a QR code on a microprocessor-based system, if any programmer were to look into this algorithm it would blow their minds.

Retro Replay: Is there a game you designed that you think history has underrated because Pitfall! understandably dominates so much discussion of your career?

David Crane: I have published many games, and I am proud of all of them for one reason or another. I don’t mind being known as Mr. Pitfall. A few years back, one of the more admired game magazines published a list of the top 100 games of all time. Pitfall! was still hanging on to number 99 several decades (and hundreds of thousands of games) after it was first released. Sadly, many of my online games are no longer available to be played, such as games for the Lifesaver’s Candystand and Nabisco World (sites created by Garry and myself) because the servers are no longer on line. If you could play my Candystand Billiards game I think you would be impressed by what we were able to accomplish in Shockwave.

Retro Replay: Conversely, is there a famous game of yours where people have spent decades praising something you personally don’t consider particularly remarkable?

David Crane: If I am being honest, Laser Blast became too repetitive, although it went Platinum (selling over 1 million units). And I always like to point out that Freeway, while having great graphics and sounds, is really just Al Alcorn’s Space Race arcade game.

The last ten percent, and the history worth keeping

Retro Replay: You have now watched video games evolve from cartridges measured in kilobytes to productions involving hundreds of people and enormous budgets. Do you think extreme hardware limitations sometimes produced better creativity precisely because developers could not solve problems by simply throwing more resources at them?

David Crane: I personally prefer having limitations that lead me in a direction, rather than having a blank sheet of paper. Your readers should check out the book “Racing the Beam” that discusses how a console’s limitations affect the types of games that were made for each console.

Retro Replay: If you put a talented 25-year-old programmer who had only ever used modern engines in front of an Atari 2600 and gave them six months, what lesson do you think that machine would teach them that modern development probably never will?

David Crane: That depends a lot on the person. Making a game in the 2600 era required both left and right brain skills in order to squeeze creative work into a highly technical environment. Another thing that I would hope your hypothetical 25-year-old would learn is the importance of polish. At Activision we used to estimate that 90% of the time is spent on the last 10% of the game. The tweaking and polishing of a game can turn a mediocre game into a great one. I fear that so many wannabe game makers of today don’t have the perseverance to complete a game with all of the polish necessary to rise above the mediocre.

Retro Replay: Is there a commonly repeated story about Atari, Activision, Pitfall!, or your career that you wish people would stop repeating because it is wrong or missing important context?

David Crane: Other than the story of the Atari 2600 Donkey Kong that Garry Kitchen made for Coleco (possibly a topic for another article), I find that people are generally pretty knowledgeable and interested in correcting misinformation, or they are completely clueless and have no idea how things went down in those days. The latter group can’t be helped.

Retro Replay: If you could preserve one artifact from those early years for future game historians, source code, handwritten notes, development hardware, internal Activision material, prototypes, correspondence, what do you think would teach future generations the most about how games were actually made?

David Crane: No specific item comes to mind, but I hope that today’s game publishers continue to strive to do a better job of documenting history. If it wasn’t for the founders of the National Videogame Museum diving through dumpsters outside of Atari, that entire era would be lost. Be sure to visit the NVM in Frisco Texas to see a fraction of the hundreds of thousands of artifacts they have preserved.

Retro Replay: Finally, what should I direct readers toward today? Audacity Games, current projects, appearances, archives, or anything else you would particularly like people to know about?

David Crane: Certainly visit audacitygames.com to see our latest work. And keep an eye on social media for retro game conventions. We try to support retrogaming around the country and the world, and if you bring any of our older games to a show where we are speaking we will gladly autograph your personal copies.

Follow David’s work

Visit Audacity Games for David’s current work with Garry and Dan Kitchen. His personal website also collects material about his career. David recommends the National Videogame Museum in Frisco, Texas for readers interested in seeing artifacts from the industry’s early years.

Thank you, David

Our thanks to David for answering every question and sharing the practical details behind so many memorable games. We appreciate the time and care he put into explaining the work, from a single saved processor cycle to the finishing touches that make a game worth playing.

Image credits: David Crane portrait from his personal website, linked above; photographer not identified there. The featured collage uses a cropped adaptation of that portrait and gameplay imagery from Pitfall! and A Boy and His Blob. Game screenshots link to their exact Retro Replay platform entries in the captions.