Procedural Dungeons of Doom: The Making of Rogue – Chapter 3

Following his departure from UC Santa Cruz, Michael Toy befriends a hacker interested in helping him carry Rogue’s torch.

Procedural Dungeons of Doom: The Making of Rogue

Chapter 3: Arbiters

Author’s Note: This story has been adapted from chapters of Dungeon Hacks: How NetHack, Angband, and Other Roguelikes Changed the Course of Video Games, written by the authorIt can be purchased in paperback and electronically from Amazon.

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 held 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.”

Ken Arnold1

 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 50 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 presented 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 that worked on any cursor-addressable terminal. He called his library curses.


Keepers of the Code

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 dungeon topography every time the screen refreshed was inefficient. Such movements cost anywhere between two and twenty characters depending on how far the cursor needed to jump around and how many characters needed to be redrawn. As a result, refreshing the screen over the 300-baud modems could be a painfully slow process.

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 a treasure or monster in the passage. Arnold modified the interface further, cutting down on the 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.”


Widespread Distribution

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.”

Bill Joy.

Bill Joy.

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.


If you enjoy Episodic Content, please consider showing your support by becoming a patron or via a one-time donation through PayPal.




1. Rogue made the cut: “History and Timeline.”


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s