David L. Craddock writes fiction, nonfiction, and grocery lists. He is the author of the Gairden Chronicles series of fantasy novels for young adults, as well as numerous nonfiction books documenting videogame development and culture, including the bestselling Stay Awhile and Listen series, Shovel Knight by Boss Fight Books, and Long Live Mortal Kombat, a trilogy delving into the bloody history of the world's most infamous fighting franchise. Follow him on Twitter @davidlcraddock.

Dungeon Hacks: Expanded Edition by David L. Craddock

In 1980, computers were instruments of science and mathematics, military secrets and academia. Hackers around the world seized control of monolithic mainframes and early PCs to create roguelikes, a new type of roleplaying game drawn from text-based symbols instead of state-of-the-art graphics. Dungeon Hacks tells the stories of how some of these earliest roguelikes were created, based on extensive research and interviews with their creators.

Revised and updated, Dungeon Hacks: Expanded Edition collects the original 2015 book, plus more interviews and stories about developers and games inspired by formative roguelike RPGs.

Expanded Edition Includes:

•New Introduction
•3 Additional Books: One-Week Dungeons: Diary of a Seven-Day Roguelike Challenge, Anything But Sports: The Making of FTL: Faster Than Light (with bonus content), and Red to Black: The Making of Rogue Legacy
•Transcript from the author's panel with Rogue co-creators Michael Toy, Glenn Wichman, and Ken Arnold at the 2016 Roguelike Celebration Conference
•Photos, Interviews, Behind-the-Scenes Info, and More


People can't get enough of roguelikes, a genre that dates back to mainframes and teletype. Luckily for me, they can't get enough of Dungeon Hacks, my seminal book about the creation of foundation roguelike RPGs, either. I decided to revise and expand the book to include a new introduction, interview, and bonus books to satisfy players who can't get enough procedural generation. – David L. Craddock, curator, StoryBundle



  • "Classic roguelike games may seem like yesterday's news, but they inspire game designers the world over to this day. Dungeon Hacks tells their story in compelling fashion and explains what they still have to teach us."

    – Warren Spector, director of Deus Ex and Disney's Epic Mickey
  • "Not only is David telling interesting stories, and illuminating the history of an enduring genre of games, but he's performing an invaluable service in capturing the human element behind the games—the particulars of the people, the context, and the time period. Dungeon Hacks is great stuff, and we're lucky to have someone with such an eye for detail and the nuts and bolts of development to put it down on paper for us while there's still time."

    – Travis Baldree, co-designer of Rebel Galaxy and Torchlight 1-2, lead designer of Fate



Ken C. R. C. Arnold grew up in a household where science and technology were as commonplace as dishware. During the early 1970s, his father worked as a programmer and scientist in charge of writing computer simulations. Arnold took an interest in his father's work and peppered him with questions. One day, Arnold's father stanched his son's tide of inquiries by handing him a book on FORTRAN, a programming language designed to solve scientific computations quickly and efficiently.

Excited to dig in, Arnold studied the first lesson. The objective was to write a program that generated a Fibonacci sequence, a string of numbers where each successive number is the sum of the previous two numbers: {0, 1, 1, 2, 3, 5, 8, 13}. Generating a Fibonacci sequence had long been considered an arduous trial for burgeoning programmers, one meant to test their grasp of logic more than their command over language syntax. Most programmers needed three variables—containers for data such as numbers and text—to generate a Fibonacci sequence: two variables to hold one term apiece, and a third to hold their sum. The program then entered a loop, calculating sums and constructing a long sequence of Fibonacci terms by passing terms and sums between the three variables until it reached a designated stopping point or the user terminated the program.

To his father's amazement, Arnold solved the problem in record time—using only two variables. "I thought memory was precious," Arnold explained in our interview. "So I told my dad, and he said, 'You can't do that with two variables.' I said, 'Yes, you can. Look.' He looked at it and said, 'You're right.' And I thought, My god. I might be better at this than he is. For any teenager, that is a great temptation."

Arnold's quick learning pushed him to seek out new challenges in computing. He spent most of his time at school sharpening his programming skills and playing the same Star Trek game that had captured Michael Toy's imagination. When he and other students exhausted the school's supply of games, they wrote their own. Still in high school, he learned that his community's chapter of Eagle Scouts routinely met at a company that allowed access to their computers. Arnold suddenly became very interested in earning merit badges.

Following graduation, Arnold decided to take a year off between high school and college. He got a job at Lawrence Berkeley National Laboratory located near UC Berkeley's campus. When he was not working alongside his colleague, Art Rosenfeld, who designed programs that calculated how much energy a building would consume in a diverse range of climates, he trawled UC Berkeley's computer lab. Arnold was eager to jump on the lab's PDP-11/70 minicomputers, and tutored students in exchange for an account at the lab. Up to forty students could connect to a single 11/70 via a modem, and were allotted fifty kilobytes of disk space, enough capacity for Arnold to write some interesting programs in C.

While 50K of disk space was considered plentiful for the late 1970s, UC Berkeley's computers came up short in other ways. Every user connected to the PDP-11/70 worked at a dumb terminal, and each screen displayed information in the same way: as new text appeared on the screen, old text got pushed up and out of view. Once it was gone, it was gone for good. The cursor operated similarly: it sat at the position where the next keyboard character would appear, unable to be maneuvered around the screen so users could correct typos or expand on previous paragraphs.

The arrival of cursor-addressable terminals at UC Berkeley was a game changer. Unlike ordinary dumb terminals, cursor-addressable terminals divided the screen into a grid of rows and columns, and tracked where each character on the grid was stored in memory. In other words, savvy programmers could move the cursor to any square in the grid and modify or add text there.

Such a radical leap forward in display technology gave rise to all sorts of programming possibilities. In 1976, Bill Joy, the hacker who would lead development of BSD UNIX, wrote a text editor called vi, short for "visual," that allowed users to move their cursor and edit text anywhere on the screen.

Other, non-academic programs took advantage of cursor-addressable terminals. In 1963, the American Standards Association created the American Standard Code for Information Interchange, or ASCII. ASCII is a collection of text characters such as letters, numbers, and symbols commonly found on keyboards. Arnold and other students realized they could use ASCII characters to create graphics. "My friends and I would write these little programs that would use the cursor library to do something visually interesting. A guy drew a little ASCII picture of a car, and you could watch it drive across the screen. I ended up writing a little impersonation of a fly that buzzed around the screen." Animating flies and automobiles consisted of grouping individual ASCII characters together so they resembled images, then erasing the screen and re-plotting the characters to new locations over and over, simulating movement.

Cursor-addressable terminals came with one downside. Each terminal stored characters differently, so programmers had to rewrite cursor-addressable code on every type of cursor-addressable terminal they used. Tired of revising code every time a new terminal appeared in the lab, Arnold wrote a platform-agnostic library of cursor functions. He called his library curses.

WHEN BILL JOY corralled worthy programs and packaged them in BSD UNIX in 1978, curses received a place of honor. By 1980, Rogue had spread from its home on UC Santa Cruz's computers to other UC campuses, including UC Berkeley. Arnold took to the game right away. "People often believe that curses was written for Rogue because most people saw them at the same time. We were playing Rogue, and somebody came up to me at one point and said, 'You know, Rogue is really, really smart. When you move on the screen, it only redraws the characters it has to redraw.' I said, 'Oh, they must be using curses.'"

Arnold enjoyed Rogue but grew frustrated with its interface. For as smart as other users believed the game was, it used resource-heavy methods of cleaning up the screen. The modems that connected dumb terminals to the lab's minicomputers were 300 bauds, which meant the minicomputers could only send thirty characters to the screen per second. Rogue's usage of curses to reposition the cursor and redraw the dungeon every time the screen refreshed was painfully slow.

As much as Arnold wanted to tighten up the game, his hands were tied. Rogue's creators, two students from UCSC named Michael Toy and Glenn Wichman, had opted not to make their code freely available. Then, in 1982, a new employee joined UC Berkeley's lab and started asking around after Arnold. "Mike Toy transferred to Berkeley, which I didn't know about until he came and looked me up," Arnold explained. Toy, he found out, was aware that Arnold had written curses, and had sought him out to learn more about how the library worked. "We started exchanging ideas. Over time, we got to know each other well enough that he trusted me with the code," Arnold said.

For Arnold, the first order of business was popping Rogue's hood and optimizing the code. "What it used to do every time you [opened the] inventory was clear the screen, draw the inventory, then clear the screen [when you closed the inventory] and redraw the map. One of the first things I did was display the inventory in the upper-right corner of the screen as far to the right as I could. That meant that the least amount of screen area had to be erased. I would clear out that area, draw the inventory, and when you were done, I'd only have to redraw that area [of the map]."

Arnold and Toy put their heads together and made dozens of other improvements. Long, winding corridors connected Rogue's tic-tac-toe arrangement of rooms, but were tedious to navigate. Players had to hold down a movement key in one direction, wait until they hit a wall, then move in another direction, and so on until they finally came to a room. Arnold rewrote the code so the "@" avatar raced through hallways automatically, halting only if it encountered an object that required the player's attention, such as a monster or a treasure in the passage. Arnold modified the interface further, cutting down on verbs used to describe battles. When he finished, the game output "You hit" or "Monster hit," where monster was a specific creature such as a kobold or zombie. Although the output was less interesting, Arnold reasoned that players wanted to spend less time reading text outputs to find relevant data and more time exploring the Dungeons of Doom.

Level generation, while inexpensive in terms of hardware resources, received an overhaul. "When you went up [the stairs], you appeared in a different level. You didn't return to the same place," Arnold explained. Adding a dose of realism, he modified the code so that going back up staircases returned players to dungeons they had cleared. Other new content proved more substantial. The code Toy had carried to UC Berkeley included thirty possible names for scrolls. Arnold added syllables that the game selected randomly for even greater variety. The two friends also added rings and amulets that could be worn to add beneficial effects—provided they weren't cursed—as well as magical staffs for players who preferred spells over steel.

As the game's content base grew richer, Arnold and Toy knew that prestige for conquering the dungeons would swell in turn. "There was a score file, so we tried really hard to make it that if you didn't at least have root [administrative] privileges, you couldn't cheat the score file," Arnold explained. "I didn't mind if you cheated, but you can't record that score and have other people play against it. That was my attitude about it."

WHEN BILL JOY and the other members of the BSD UNIX committee gathered programs for the release of version 4.2 of their operating system, they rounded out the package by asking others what programs they would like to see included. Besides the usual assortment of productivity tools, BSD UNIX shipped with a games folder that contained the likes of chess and a few quizzes. Rogue made the cut, and was distributed as part of 4.2BSD in 1984. 1

As the number of computers tethered to ARPANET and other networks grew, BSD UNIX became ubiquitous, finding a home in computer labs all over the world. Arnold and Toy occasionally received letters from professionals and students who were enjoying Rogue's addictive and danger-laden levels. Every so often, fans contacted them from the most unlikely of places. "There was somebody who worked at a nuclear bomb laboratory in Nevada, and you think, Shouldn't they be doing something besides playing games when nuclear weapons are at stake?" Arnold remembered. "To a certain extent, it also felt like, if Rogue was interfering with weapon development, maybe that's a good thing. Maybe it's good that we were slowing all that down."

As pleasantly bewildering as it was to hear from technicians at nuclear labs, Toy and Arnold were utterly bowled over when they learned that their computing heroes enjoyed Rogue. Ken Thompson, a computer scientist at Bell Labs who co-created UNIX alongside Dennis Ritchie, apparently played the game so much that he had taken time out of his schedule to hack the encryption scheme Arnold had written. "When it really hit me was, somebody who worked in Bell Labs said, 'Ken Thompson does the following thing to cheat,'" Arnold remembered. "I was like, 'Oh. I had no idea Ken Thompson enjoyed the game. This is a really big thing.'"

In 1984, Arnold graduated from UC Berkeley and took a job at UC San Francisco as a developer. He and Toy, who had already landed a job at Italian typewriter manufacturer Olivetti, took Rogue's source code with them. They envisioned turning the game into a commercial product. Looking back, Arnold regrets their attitude. "Unfortunately, since we took the source with us, other people weren't able to take it and do something with it."

Time passed, and Arnold and Toy lost track of Rogue's code. The dream of converting Rogue into a commercial product was lost.

GameDev Stories: Volume 2 – More Interviews About Game Development and Culture

Author Bio

David L. Craddock writes fiction, nonfiction, and grocery lists. He is the author of the Gairden Chronicles series of fantasy novels for young adults, as well as numerous nonfiction books documenting videogame development and culture, including the bestselling Stay Awhile and Listen series, Shovel Knight by Boss Fight Books, and Point of Fate, the newest volume of the Gairden Chronicles series of epic fantasy novels for young adults. Follow him online at www.DavidLCraddock.com, and on Twitter @davidlcraddock.

Book Description

Programmer. Artist. Musician. Designer. Producer. Editor. Collector

Video games comprise a multibillion-dollar industry thanks to the people who make and play them. From designers and producers to artists and programmers and passionate communities, each plays a role in maintaining and advancing the medium of electronic entertainment.

Each has a story to tell.

Collected from the author's archives, GameDev Stories Volume 2: More Interviews About Game Development and Culture gathers even more conversations with individuals from all corners of the industry.

Review Blurbs

By giving bedroom hackers equal billing with company founders, Craddock successfully illustrates the tremendous breadth of voices behind the creation of video games. Taken as a whole, Craddock's interviews masterfully weave together the artistry, business, and humanity of game development into a work that explains what game development is far more successfully than any individual could ever hope to. -Frank Cifaldi, game developer, founder of The Video Game History Foundation

In GameDev Stories, Craddock opens closed doors to reveal how games are made in a collection of wide-ranging interviews. You'll hear from programmers and designers, but also from individuals in positions often overlooked such as marketers, user experience researchers, and community managers. A must-read for anyone curious about what goes on behind the scenes of the games industry. -John Keefer, managing editor, The Esports Observer

Social Links

www.DavidLCraddock.com and @davidlcraddock.


Readers know me best for Stay Awhile and Listen, my trilogy of books on the history of Blizzard Entertainment, Blizzard North, and their franchises, specifically Diablo. Stay Awhile and Listen: Book II – Heaven, Hell, and Secret Cow Levels will be published in the summer of 2019. I've been interviewing Blizzard developers and researching these companies and games for over ten years, and there's still work to be done.

For the first time, I've peeled off extracts from those interviews to publish them in their entirety. Chapters 3 and 4 of this book let you hear directly from Condor/Blizzard North co-founders David Brevik and Max and Erich Schaefer on their earliest experiences in the games biz.


Craddock: What were some of your earliest experiences playing games?

David Brevik: Probably Pong. I don't think that Pong was really the cat's meow for me, but by the time my friends and I were playing things like Space Invaders, Asteroids, Pac-Man and stuff like that. There was a sandwich shop, Blimpie, that had a couple arcade machines. There was a place across the street, a pizza place, that had a couple arcade machines as well. We'd go to those places and play. A few of my friends at that point had pinball machines, which I really enjoyed. That was part of my introduction [to video games], and at the same time we had an Atari 2600, and that's what really got me into gaming. Adventure was one of my favorites.

I loved Space Invaders, Pac-Man, and Adventure—those three are some of the first games I remember playing. But really, one of my first experiences with computers... I think it was in the fifth grade, maybe in 1979 or something like that. Somebody at the school had bought an Apple II+ and had it at school. I remember that being a big deal for me. That was really influential.

[Sierra On-Line adventure game, The Wizard and the Princess]. I played that game. There was only a monochrome monitor, so it didn't even have any color. It was all green, and there were pages in which there were a couple puzzles. You'd type in "Pick up rock", you know, typing in the sentence, and you could type "List" to get your inventory of six objects that you could hold. Also around that time was the movie Tron; that was really influential to me. The graphics that were in [Tron] were amazing for the time, things that only a supercomputer could make because of their resolutions. They could render these pictures, it would take maybe a whole day to render one of these images, but to see that in a movie, they could play it back rapidly. I always wanted to make graphics like that.

There were a lot of factors like that that were influential, but most of all it came down to Pac-Man, Asteroids, Adventure—all those games were really huge with me.

I was a big Dungeons & Dragons fan. My friends and I would stay up for many late nights. This is right around the time of Pac-Man, Asteroids, that stuff. We'd play those games or we'd play D&D—that's pretty much all we'd do. We'd sit down in my friend's basement and play D&D. I have fond memories of those times. We'd paint lead figures and stuff like that.

Craddock: Did you want to make games even then, or were you just a kid having fun?

DB: Making games was absolutely my intention. I think that shortly after discovering the Apple II+ in fifth grade, my dad was leasing computers, and because of that connection, he was able to get an Apple II+ and bring it home. I think that was probably around seventh grade, somewhere in there. That was really the catalyst for me developing as a programmer. I taught myself the Basic language. Around that time you could buy magazines like Apple Insider that published articles about how to make games. It would have the code for a complete game inside these magazines. So I would spend hours and hours typing code, and I didn't even know how to type, I was hunting and pecking. But I spent hours and hours typing in the code to run some stupid little game. You couldn't really do much, but I was crazy about these things. Through that process, I was slowly typing these things in—and I mean slowly—and learning what it is that's kind of going on.

Invariably, there were always print errors, bugs, in the code. The games, first off, were kind of throwaway little articles that people would write for these magazines, so they were always buggy. I'd want to modify it, so I had to learn how they worked in order to debug the code, because there was no such thing as a debugger at this time. Through this process of being able to start to learn Basic, start to learn how programming works, learning to debug without a debugger—which benefitted me throughout my career—and understand how things are processed... it was just great.

Then experimenting within that and stretching from learning Basic to learning Assembly. Because the magazines would sometimes have Assembly routines that they would use, like Peek and Poke and stuff like that. There were numbers I could convert, you know, there were decimal numbers I could concert into hexadecimal and I could look them up on a table and see what the instructions were. I could write out the code by hand and follow what they were trying to do. I was learning basically through magazines. They had ads from Bit Brothers or something like that. They were old-fashioned ads that had these guys with moustaches and there were these pieces of code that were maybe ten lines long that would do crazy things like make your computer beep in some kind of rhythm or make a bunch of lines crisscross on the screen.

Eventually I started understanding how all these things worked, and I wanted to do this [for a living]. I started high school in eighth grade. We had all sorts of ancient computers in the math lab in high school: a computer with no CRT; it was a printer, like a typewriter and computer combined into one with a scroll of paper. They called that "letter quality" back then. It would jam and the whole nine yards. They had a punch card machine; they had some really ancient computers there. I was able to learn a little PDP-11 assembly language at that time. My math teacher was helping me out. There were some games. I'd play Lunar Lander. You type in your thrust, and you had variables that told you where you were trying to get, and you had to put in the right numbers; as you put in the thrust you'd get fuel and you had to balance everything to successfully land on the surface of the moon. I'd sit there and try to guess how fast or slow I'd crash, or if I'd land safely.

I'd sit at home and play a lot of games. Things were readily available. I had a 300 baud modem, and I'd call up BBSs and download hacked versions of game and stuff. That was very common. My friends would have shoeboxes full of games on floppy disks and we'd swap them. I bought some games, too, but I couldn't afford everything. I remember one of my favorite games I bought early in that time was Wizardry. I bought Ultima I through IV.

By the time I was in ninth grade I could write my own games. When I was a freshman in high school, I spent a long time making a BMX bicycle game. It used the paddle available for Apple II. The bike would come across the screen, go down hills, go over jumps. You'd press the button to bunny hop, and you had to make jumps and stuff to get to the end. The game could scroll, too. I sent that off to be published in Apple Insider magazine. So I knew at the time that this was a passion: I wanted to make games and I wanted to put them out there. I was very serious about it even at a young age, as a freshman in high school.

Craddock: Were you studying games as you played them?

DB: I was sort of a designer, but that wasn't really my passion. It was programming. Trying to make fancy graphics, trying to make things run fast, look good, play well—those were always very critical to me. It wasn't necessarily about game design, it was about making things happen, and the revelation of colors coming into play. I mean, 16 colors—oh my god!

Craddock: Many fans know Diablo was influenced in large part by your love of roguelike games. How did you discover those games?

DB: I didn't play very many roguelike games until college. [Attended California State University.] The idea for Diablo came about when I was in high school. In fact, I named the game when I was in high school. I lived at the base of Mount Diablo. That's where I got the name from. I didn't know any Spanish when I came to the Bay Area. Then I came out here and took a Spanish class in high school, and one day I was like, "Diablo means devil. That's awesome!"

I'd write these design documents and I'd title them "Diablo". So I really started to get into design—numbers and balance and stuff—around my sophomore or junior year of high school. I started to not only be very interested in programming, but also in design. It wasn't really about critiquing other designs; it was about innovating and creating something very different. Then, of course, I would violate my own rule by playing games that had a massive influence on things that I would do.

I went to college and they had UNIX machines there. And the Internet! This was 1986, so the Internet was just a mess at this time. It was basically schools hooked up to military facilities—basically a fancy Blizzard South that was always connected. You could go to other school's pages and peruse their directories, and they'd have public areas where you could upload things and stuff like that. That's what gave me access to playing games like Rogue and Moria—games that had random levels, a town, things like that. They were an influence on me as a gamer and ultimately on Diablo. I enjoyed these games so much. I spent hours spent on these things.

These old UNIX systems didn't have arrow keys or anything like that. You moved around with HIJK, I think. Then casting spells used M for magic, B for book, and other keys to cast spells, then where you want to target. So you end up wiggling your fingers around typing, and it almost felt like you were casting spells, like "I'm moving around and doing these arcane gestures!" It was this visceral feel, and I always enjoyed that. It doesn't translate to a wide audience, but I always enjoyed that mechanic of typing in what spell you're casting and doing these sort of gestures for different spells. I never made it in any game I've ever done and I doubt I ever will, but I always found it very enjoyable.

So I think those games, ultimately, I knew they were extremely addictive. There were a bunch of people in the lab playing them over and over and over. I spent many hours, pretty much my entire college career, playing roguelike games. I knew before that, I mean, I knew in high school that I wanted to make games. I knew exactly what I wanted to do with my life. I didn't want to do anything else, and I wasn't really interested in anything else. In fact I was barely interested in reading or... I mean, almost anything else in my life wasn't as important as anything that had to do with games or computers. Which kind of hurt me in some ways and helped me in some ways. I became really good at computers and programming. I understood how it worked and could write many things.

In my senior year of high school I was teaching a programming class because I knew C and the teacher didn't. So there was this graduation of my abilities. So I'm not upset where I'm at, but sometimes I wish I had a larger vocabulary, or that I'd just been more well-rounded at that time. But I am who I am.

By the time I left college I knew that I wanted to make [Diablo], and I knew that that was... I had a few game ideas, and Diablo was one of them, and was probably the most fleshed out, the one I'd realized the most and spent the most time on. I knew that I would be given a chance to do this eventually, but I didn't have the money, knowledge, or contacts to do it quite yet. I had to get my feet wet. I went to college because... See, in high school I was working for Pacific Bell doing telecommunications software, doing modem coding and things like that. And I knew that I didn't actually have to go to college to do what I was already doing proficiently. I could skip college if I wanted and make games right out of high school, or even work for Pac Bell and do a variety of things that I wanted to do.

Unfortunately, or maybe fortunately, I had kind of a baby face syndrome. I looked like I was maybe ten years old by the time I was seventeen. I was skinny, I was baby-faced, I was just this very youthful-looking kid, and because of that people didn't take me seriously. So because of that, I was like, "I'm going to go to college, and I'm going to grow some facial hair, dammit!" And I'm glad that I did. I'm glad I went to school and took the time to do those things. In the end it was really what I needed to do and it helped me immensely, but I was pretty confident at the time that I didn't need it. I was positive I could make money without it. But I experienced things in college like roguelike games that really had a massive impact on where I ended up.

Craddock: What was your plan after finishing school?

DB: Right out of college, I wanted to make games. My parents weren't super-pleased with this decision, but they were fairly supportive. They were hoping I would work for IBM or someplace like that, especially because games weren't the most secure business in the world. This was the Genesis and SNES era. So I said to my parents, "Well, how about I try making games for a little bit? If it doesn't work out, I'll try making your boring-ass spreadsheet programs or something." Those things sounded so boring to me, but I did realize that I needed to pay the bills. I graduated in the spring, then that summer, I got married and had my first job. We were living with my wife's parents at the time. So I was living with her and her family in the San Jose area.

There was an ad in San Francisco Chronicle for a job in San Francisco. Somebody was looking for a game programmer. I took the job at this clipart company called FM Waves. They had less than ten people. They'd focused originally on making clipart. That wasn't working out very well, and they knew the Tramiels, who owned Atari at the time. Through that family connection they were able to get a contract to create a game [Gordo 106] for the Atari Lynx handheld. It was about this lab monkey that escapes from an evil scientist. It eventually got released.

In a small world situation, there were two guys who worked at the clipart company, Max and Erich Schaefer. That's where we met. I was a programmer, they were artists. I left, but they stayed on to finish Gordo 106 and got the rights to do the Super Nintendo version of it. The producer for that company was a guy named Matt Householder who worked for us at Condor, Blizzard, Flagship, et cetera. So there was a connection between the four of us from the early, early 90s.

So I was the programmer on this Atari Lynx game, I'd been working at FM Waves maybe five months or so when my paychecks started bouncing. Definitely didn't want to tell Mom and Dad. It would have brought on the "I told you so" speech. So I knew it wasn't going to work out, and it was time to look for something else more secure, but I still wanted to do video games. I looked in the paper and there was an ad for a new company in Santa Clara. I was living in San Jose, so I was like, "Shorter commute, and my paychecks have a better chance of clearing—in theory."

Craddock: Between FM Waves and Condor, you worked at Iguana. How'd you land there?

DB: So it was another little startup. I was employee number one, I believe. All the other guys were founders—two programmers and two artists. I was the first non-owner. And that was Iguana. My first project there was to convert an arcade machine that Midway was making called Super High Impact Football to the Sega Genesis. I did that in three months. There was an artist doing the art but I was the only coder. We finished it and it was one of the first on-time, on-budget projects that Acclaim had had in years. They were very happy with our results. The people doing the Super Nintendo version couldn't get it done; it was a total disaster. We were eventually asked to help out with that. I don't remember if we helped out or not.

Because of that project, we opened the doors for other possibilities. The owner of the company was a guy named Jeff Spangenberg. We started to grow and moved out of our facility and began doing multiple projects. Did some Super Nintendo games. We developed our own dev kits and had our own development machine and our own compiler/assembler. All the games were written in Assembly language at the time. We wrote all the debuggers and everything. Nintendo and Sega didn't provide those things; you had to make your own. They'd give you the hardware specs and say, "Good luck!"

Iguana was going really well. I became the Technical Director there and we were doing all sorts of projects. In fact, Acclaim and Midway wanted us to do a project. Jeff Spangenberg came to me and said, "We did such a good job on Super High Impact, Midway want us to try converting another arcade machine. We're going to go down to the arcade and play the game, it's this new game that just came out. I want to see what you think of it and whether or not you want to do this project." So we went down to the Golfland in Sunnyvale, California, this world famous location to try out arcade games. We played the game, and I was like, "Oh my god, Jeff, this game kicks ass. This is going to be a huge monster hit. We've got to do this game. He said, "Eh, I don't know. I don't really like it that much. It's too weird. It's just this cheap knockoff of another game." I said "Okay, well, I really think it could be awesome." That game was Mortal Kombat.

So they came back to us with another arcade machine they wanted us to convert. We went to Golfland and played that one. Again I told Jeff, "This game kicks ass, we've got to do this one." This time he said, "Okay, okay!" That was NBA Jam.

Craddock: What caused you to leave Iguana and start Condor with Max and Erich?

DB: Around the time we started NBA Jam, we weren't very far along and Jeff got married. His wife was from Texas so he moved the company to Texas. I didn't want to go. So I left and called up Max and Erich and said, "So, uh, you guys doing anything? Want to start a company?"

"I've got a lot of contacts because I made this game [NBA Jam] for Acclaim. I know some guys there." And I knew people over at Sunsoft because we did some work for them such as Aero the Acrobat and a few other games. I've got contacts there, at Acclaim—I'm sure we can get something. So they said, "Sure, why not? But why don't you help us finish the Super Nintendo version of Gordo 106." I'm like, "Eh... not really interested. Call me back when you want to do something different." A couple months later, Max and Erich called me. They said, "Let's do this." We created our own company, and that was Condor.