Advent of Computing - Episode 22 - Going Rogue

Episode Date: January 26, 2020

Many video games today make use of randomized content, some more than others. It may seem like an obvious feature, but it turns out that procedural generation didn't really catch on in video games until the 1980 release of Rogue. The game itself never saw much commercial success, but was wildly popular among UNIX users. In this episode we look at Rogue, how it was created, and the legacy that we still see today. Like the show? Then why not head over and support me on Patreon. Perks include early access to future episodes, and stickers: https://www.patreon.com/adventofcomputing Important dates in this episode: 1980: Rogue Written for PDP/11 1984: Rogue Ported to PC, Macintosh, Atari ST

Who doesn't love a nice game of Dungeons and Dragons? But, then again, there's always the time commitment involved. Getting enough people together to play can be hard. And then getting everyone's schedules to match up for a regular game quickly becomes a nightmare. There has to be a better way. Well, dear listener, you may just be in luck. That is, if you can handle adventuring solo. You may just be in luck.

That is, if you can handle adventuring solo. In high school, I played a lot of Dungeons and Dragons. That should come as no surprise. Even with a weekly game going on, I still wanted to delve into a fantasy world more often. And, well, there was one thing for that. Over the course of time, there have been countless fantasy role-playing games written for countless different computers and video game consoles. My game of choice during high school was called Slashem, but the game came by many different names. You may have played it as Darkest Dungeon, Faster Than Light, NetHack, or Diablo, or Risk of Rain, or even Pokemon Mystery Dungeon.

or Diablo, or Risk of Rain, or even Pokemon Mystery Dungeon. All of these games, and many, many more, are based heavily upon a much earlier video game. That game was called Rogue, and it was originally written all the way back in 1980 by a small group of programmers that happened to have access to a mainframe. But the game wouldn't stay in computer labs for long. So how did such a small production escape into the wild? And how did it go on to establish one of the more enduring genres of video games? And hey, how fun is Rogue anyway? Welcome back to Advent of Computing. I'm your host, Sean Haas, and this is episode 22, Going Rogue.

Today, we're going to be looking at one of my favorite types of video games. That's the roguelike. Specifically, we'll be diving into the origin of that genre, Rogue. So, what is Rogue anyway? In simple terms, it's a randomly generated dungeon crawl. Each game, the levels, and a lot of the items in the game are procedurally generated. That makes no two sessions of Rogue the same. That, combined with its depth and difficulty, make it a very repeatable and addictive game. It really cracked the code for this type of gameplay, establishing a pattern that would become

ingrained in many games to follow. Another key factor to Rogue's success and spread, outside of the randomness that is, comes down to the context that it was developed in. For 1980, there really weren't that many options for video games. You gotta keep in mind that the Atari 2600 wouldn't be released for another two years. At this time, arcades existed, but they were built for a very different type of gameplay, something more fast-paced and at least somewhat sociable. There were examples of complicated RPGs like Play-Doh's Moria, but those were being played on isolated systems that didn't spread outside of their

intended platform. By contrast, Rogue itself would end up having a wide reach even before imitations appeared. And a big part of that spread was thanks to the ARPANET and UNIX. And a big part of that spread was thanks to the ARPANET and UNIX. So let's dive into Rogue. How did the game come to be, how did it spread, and just why has it created such an enduring legacy? To get down to the root of how Rogue became so popular, I think that we should first look at the state of computing in 1980, or more specifically, the state of computing in academia.

ARPANET, the government-funded predecessor to the internet, was already 11 years old. In that time, it had gone from a small collection of mainframes to a large and relatively robust network that connected most of the US. But even with its large reach, most installations were either military, government, or university-run. It wasn't yet the open network that we enjoy today, but it was open enough to allow for a little bit of fun. Strictly speaking, fun was prohibited on ARPANET by national law. Rather, it was only supposed to be used for research. But it seems like that rule was pretty rarely enforced, or at least enforced

selectively. The network had been designed to quickly and efficiently transfer data around the country. Ideally, that'd make it a great aid for researchers, especially computer scientists, since it opened up your resource pool significantly. Instead of having a single mainframe, you could access computers across the nation. However, things rarely work out as intended, especially when computers are involved. When you get down to it, ARPANET really excelled at connecting together people. In fact, in the early era, most traffic on the network was from email. In the early era, most traffic on the network was from email. Amongst all that chatter, something fun would occasionally come through.

And those were early computer video games. This is how a lot of early computer games would end up spreading. Someone at a university or research center would write up a video game in some stolen computer time, and then it would get out and be passed around on the ARPANET. In a lot of ways, this was the first time something could really go viral, so to speak. One such game that made the rounds in those days, those days being around 1976, was called Colossal Cave Adventure. This was one of the first fantasy adventure games to get really much traction, and it became a perennial favorite in computer labs across the country. It's still played today. Colossal Cave Adventure, or just Adventure for

short, is a text-based adventure game. The entire game is played through text alone, with the program explaining just what's going on around you as you type back what you want to do. Through this interface, you travel into a cavern, solve puzzles, fight monsters, and eventually collect treasure and escape. Adventure spread very quickly thanks to ARPANET. Once it was discovered, it was only a matter of weeks before it had spread from university to university over the network. Students and faculty alike became obsessed with the game just as quickly. They'd spend hours trying to find every secret that the colossal cave had to offer. Two of the game's victims were named Michael Toy and Glenn Wichman, both students at the University of California at Santa Cruz.

A few years after its initial release, the two would come into contact with adventure on a university mainframe. Both were impressed and instantly enamored with the game. Toy was a computer science major, so he did what came naturally. In his spare time, he started writing his own text-based adventure games in the mold of adventure. Witchman, however, was on a slightly different track. He wasn't primarily a programmer. Instead, he wanted to become a board and card game designer. Witchman was a huge fan of Dungeons and Dragons, but once he saw Adventure, his plans started to change. He realized that computer games were the future, not pen and paper or any physical games. The pair would meet shortly after in the UC Santa Cruz computer lab. Both were using the university's PDP-11 mainframe to write their own adventure games,

and it wouldn't be long before they were collaborating on larger games together. This new team made a few games, mainly more clones of adventure, but early on they identified a few major problems with the state of games in the 1970s. The first was the issue of replayability, or rather, lack thereof. The way a toy saw it, there wasn't much reason to play a game a second time after you beat it. Adventure was a really fun game to play, but once you find every treasure and defeat every monster, the excitement's gone. You've seen everything the game can throw at you. Sure, there was still an element of uncertainty, but that did little to add replay value. There was only so much fun you could have with adventure. There was a market cap, so to speak.

Toy and Witchman also saw this problem in their own games. They noticed that programming a new adventure game meant that you could never really enjoy it. You already knew how it ends. You know everything along the way, and you know everything that can possibly happen. It saps the fun out of things. In Toy's words, quote, the ideal would be to write a computer game that was fun for me to play, and that was the problem In Toy's words, The second issue came down to the technology of the era. By the time Toy and Witchman found Adventure, text-based games were already becoming somewhat obsolete. Let me explain. Colossal Cave Adventure had been designed to run on a mainframe and be controlled over

a teletype. This is an archaic form of a computer terminal that displayed messages by printing them onto a paper feed. As such, Adventure was built to be playable one line at a time, that's where the text interface comes in. As the 70s wore on, the teletype went more and more out of fashion, replaced with CRT terminals. These new terminals offered a host of advantages, but one was that instead of paper, everything was printed on a glass screen. A program was

no longer restricted to line-by-line operation. And, with some careful code, it was now possible to move a cursor around on the screen or control where something was placed on screen. To be fair, this kind of display technology had existed previously. There were already early microcomputers coming to market that had video displays, and there were already mainframe computers with their own video displays also. But in the late 70s, these quote-unquote glass teletypes, as they were called, were becoming more accessible. The issue here, as Toy and Witchman saw it, was that the newly in-vogue terminal displays weren't being used to their full potential. Terminals of the era didn't really do graphics

in the sense that we would think of today. But it was possible to use text characters to build up something resembling graphics. Think of something like ASCII art, where special characters are put together to make a picture, and you have a pretty good idea of what this could look like. There were already some programs and games that took advantage of these rudimentary graphics. One example was a game called, in a burst of creativity, Star Trek. Players took control of the USS Enterprise to hunt and destroy enemy Klingon ships. The playing field was displayed as a grid of dots with a capital E marking the player's ship,

and other symbols marking enemies and hazards. Typing out commands would move your ship and advance to the next turn. It was simple, but it was using the display better than text-only games. There were also much more mundane uses for a movable cursor, such as full screen text editors. With these two perceived issues in mind, Toy and Witchman started to put together an idea for a new game. The duo wanted this game to be an adventure that could be played over and over without feeling boring. It would also need to be graphically impressive, at least for the hardware they had access to. This game would come to be known as Rogue.

So how did the team go about planning an infinitely replayable game? Toy figured that the best way to accomplish this would be to lean very heavily on randomness. Now, most programming languages have a function to generate a random number. Think of it as a computerized roll of the dice. It's a feature that gets used occasionally by programmers, but Toy decided to use it much more extensively in Rogue. Everything from items to monsters to combat to the design of the dungeons itself would be dictated, in large part, by randomness. This would solve the replayability problem by making no two sessions of Rogue the same. But, as with anything on a

computer, the specifics of how that came to be were dictated by some major limitations. The PDP-11 mainframe that Toy and Witchman had access to at UCSC ran an operating system called Unix. Now, there's a whole lot to be said about Unix. In fact, I have two episodes on the matter in the back catalog. But for now, just know that it was a popular software package for mainframes of the time, and it came in a few different varieties from a few different vendors. For the time, the UCSC computer lab was a pretty reasonable setup. There were even a handful of CRT terminals connected up to their shared mainframe. However, when it came to the actual specs of the computer, Toyin Witchman would run into a pretty big wall. The PDP-11 that they were using only had 128 kilobytes of

memory. And that's for the whole system. Keep in mind that memory, storage, and even CPU power had to be shared between users. That meant that by the time you actually log in, you would have access to radically less resources. In practice, that meant that whatever program Toy and Witchman would write had to be relatively small. That includes the code itself and all the data that it would need to keep track of. There was one saving grace, however, and this is where Unix comes into play. Any good operating system should do two main things, manage the computer's hardware and provide a useful programming environment. Unix does the latter through what are called libraries. These are essentially chunks of reusable code that make a programmer's life a little bit

easier. These range from drivers for hardware to network interfaces or even math packages. The particular version of Unix that was used at UCSC was called Berkeley Standard Distribution, better known as BSD. For our purposes today, the only two things that really matter about BSD are, one, it was developed at UC Berkeley, and two, it had a library called Curses. Fun fact one will matter later on, so just keep that in your back pocket for now. Fun fact two is a little bit more obtuse. Amongst computer geeks, there's a tradition of naming things very poorly.

This is the case with Curses. It stands for, somehow, Cursor Optimization. The library first showed up in BSD sometime around 1979, and it was written by the then-undergrad Ken Arnold. The package made it easy to control where a cursor was on the screen, and it provided functions for rudimentary character-based graphics. It turned out that it was also a perfect tool for toy and witchmen. It gave them a quick and easy way to start rendering graphics, or something near graphics, on a terminal using only text characters.

Curses would prove to be invaluable, but even with the library, there were still issues with memory use. It was decided that the best way to present the game with these limitations would be to show a top-down view, where each screen would represent a single floor of the game's dungeon. If you went up or down a floor, that would get kicked out of memory, thus saving a little space. The top line of the terminal's display was used for messages, with the bottom line showing the player's status. The rest of the screen was used to display the dungeon map itself. All of this was rendered using characters like equals, underscore, minus, plus, and the number sign.

And this is where the randomness would come back into the foreground. Each dungeon level was procedurally generated. The actual level layout was based on just a handful of random numbers. Each new level looks distinct, or at least distinct enough. They're complex without being overly maze-like, just enough to be fun to explore. As you wander through a level, the map fills itself out, going from a black screen to a full floor map. But there is a trick at play here that you probably won't notice if you're playing the game. It's tricky to write a program that can create new

levels all by itself, especially if you want those levels to be playable and somehow traversable. This is further hamstrung by the limited resources that Toy and Witchman had to work with. The solution that Toy came up with is rather elegant. In Rogue, each level is broken up into a 3x3 grid, making 9 total cells. To generate a new level, you go through each cell and randomly decide which adjacent cells it will be connected to. For cells that end up being connected to at least one other cell, the program then decides on the random dimensions and placement within that cell for the room's walls. So you get the height, width,

and offset within the cell all randomized. Then everything's finished up by plotting hallways between each room and placing a stairway down to the next level. This means that each level of the Dungeon of Doom is relatively simple, but it's still fun and engaging to navigate. A level can have at most nine rooms, sometimes less, all arranged in a rough grid. But thanks to the randomized size and offset of each room, you'd be hard pressed to notice the underlying grid unless you're specifically looking for it. Since Rogue makes levels on the fly, it never needs to store very much map data and memory, just enough for a single

screen. And that saves room for more code. But the map is just one aspect of the game. It wouldn't really be that much fun if you were only moving around in an empty dungeon. Michael Toy did a good deal of the initial work. He was the partner that had more experience programming. But it wasn't long until Witchman was up to speed. There isn't really a line-by-line account of what each of them contributed to the game. Rather, Toi would characterize it as a full and total collaboration. That being said, you can see a lot of Witchman's influence in how combat was designed specifically. He was a huge fan of Dungeons and Dragons, as I've said before, even going so far as

to create his own variations on the game. In D&D, combat depends heavily on dice rolls and modifiers. To calculate damage done by an attack, you roll a die dependent on the weapon your character is using and then you add any relevant modifiers. For instance, attacking with a dagger, you use a six-sided die plus some extra bonus for your character's strength. Rogue works in a very similar way. Your character, called Rodney, is represented by an at sign on the screen, the joke being that it shows where you're at. Rodney has a strength stat that modifies how much damage you deal to monsters

in combat. He has health points that dictate how much damage you can take, an armor class that determines how hard you are to hit in combat, and a player level. Killing monsters gains experience points. Once you earn enough, you level up and that increases your maximum health. Compared to Dungeons & Dragons, the stats and leveling system in Rogue is very simplistic, but it's about all you need because you're basically going to be spelunking and doing a little bit of combat. Here, combat is similarly simplified. Everything in Rogue is turn-based.

On each of your turns, you can move, attack a monster, or use an item. To attack a monster, you just bump into them. You don't have to hit any special keys. It's simple and effective. But under the hood, Rogue takes care of a lot of calculations to manage these simple encounters. Each monster has a similar set of statistics to Rodney. They have an armor class, attack damage, and health. If you hit or not is determined by the monster's armor class and how much damage you do is determined by the weapon you're wielding and your strength stat. But monsters aren't just static targets. They can

move and attack, just like you. Each monster is represented by a letter, like Z for zombies or I for ice monsters. To further complicate things, different monsters act in different ways. Some will attack you without provocation, running straight at you. Others are more passive. They're waiting for you to make the first move. Some monsters, such as the bat, fly around in a random zigzag pattern. Still others have special attacks, such as the wraith, which can drain player experience points and even knock you down a few levels. There are a little over 20 or so monsters, but the overall diversity keeps things interesting and really gives a feeling

of danger, with more powerful enemies appearing as you delve deeper into the Dungeon of Doom. If you aren't careful or pretty well equipped, then your adventure may come to an end before you know it. Luckily, there is some help for you on your quest. In addition to randomly placed monsters, there are also randomly dropped weapons, armor, wands, potions, food, and scrolls. Weapons are pretty self-explanatory. There's about nine different types, and they each do a different amount of damage. Some are ranged like a bow and arrow, some can be thrown like a

shuriken, and some are melee weapons like an axe. Armor also comes in a few varieties, each granting you a different armor class. Interestingly, armor is one of the few features that has a traceable attribution. Witchman suggested the addition. Food is another simple mechanic. As Rodney explores the dungeon, he gets hungry, so he has to eat something. Failing to do so may result in premature death and an end to your adventuring session. So far, all of those mechanics are a little complex, but pretty graspable. It changes for magic items.

Potions, scrolls, rings, and wands are a little more complicated. This is how Rogue implements the magic that has to be in any RPG for it to be very fantasy flavored. But it does so in an interesting way. Like everything in Rogue, these items are randomly dispersed in the dungeon. But they also have random names. Other items like weapons for instance all have set names. A spear is a spear and it has a set amount of damage it can do. A food ration is just some food. But magical items are less predictable. To quote Witchman, we wanted to be able to be surprised by our own game. That's why, for example, when you find a scroll or potion, it's got a random flavor and name. The correlation of the name to the flavor is hidden from the player.

When you pick up a potion, you're only given a rough description. In the original game, it would be flavor. Later versions used color. Scrolls are initially named something unintelligible, just a string of letters and characters. Rings and wands are described by their material, something like a zinc wand or a ruby ring. You can only tell what a magic item does by using it, and even then, it may not be apparent right away. A potion might heal your wounds, increase your strength, or render you blind. Every game, the name of these items are randomized, so you never know what you're in store for.

This adds another very deep layer of risk-reward to the game. Sure, you found a magical staff, but will it kill a monster, or will it transform it into a dragon that will kill you? All this together, the procedural levels, the complex monsters, random items, and a deceptively complex combat system makes up Rogue. The details sound really complicated, and they are, but it's surprisingly easy to sit down and pick up. There's a lot more going on under the hood than you see in a game. All actions are bound to the keyboard. Originally, Rodney was moved with the HJKL control scheme, but most versions of Rogue quickly dropped that in favor of arrow keys. In practice, combat is as simple as running into a monster to attack it, or running away to flee. And that's all you need to start. Most of the game is spent moving around.

But you can go a little deeper and use more features of the game is spent moving around, but you can go a little deeper and use more features of the game if you want. Other actions are all tied to their own key. Drinking a potion is Q for Quoth, changing weapons is W for Wield, and so on. It may sound cumbersome, but it's surprisingly easy to get used to, and you can always hit the question mark key to get an on-screen help menu. The final key piece of Rogue is a mechanic called Permadeath. There are no checkpoints in Rogue. If you die, the game exits you back to Unix. Later versions let you save your

game, but when you die, the save file is deleted. This, once again, escalates the stakes, since reading the wrong scroll or not being able to find food fast enough can kick you right out of Rogue. Then you have to start all over again from level 1. Toy and Witchmen would finish the first version of Rogue in 1980. The two had been showing off the game since early in development, but 80 is usually the agreed upon date for when it was written. The game would start circulating around the UCSC campus that year, and it would spread like wildfire. Much to the surprise of its creators, people quickly became engrossed with the game. It was just the right mix of simple gameplay with a lot of hidden depth,

and a lot of players got really deep into Rogue. To quote Toy once again, they would place themselves in this situation and their creativity would express itself. They made the world more interesting and beautiful. So even though the thing I created wasn't beautiful, people would color it with their own imagination, in the same way you would do when playing a text adventure game. I'd listen to someone explain how to play the game to someone else, and they'd start talking about something that was completely ridiculous and made up." In a lot of ways, Rogue would take on a life of its own. Even though it was created using just text characters, people really felt like it was a fully realized adventure.

And yes, it did live up to its creator's hopes. Toy and Witchman loved the game, and they were surprised by every session. But despite its popularity at UCSC, it may have stopped at the university. That is, if Toy had been better at, well, school. It Turns out that while developing Rogue, Toy had sort of disregarded all of his university classes. As a result, he flunked out of college. But he wouldn't stay away from computers for long. In 1982, Toy would move to UC Berkeley, not as a student, but as a programmer in their computer labs.

And he brought some new and exciting code along with him. In 1980, in the world of computers, Berkeley was known for one thing, BSD Unix. Toy was already well-versed in BSD, since it was the flavor of Unix that was used at UC Santa Cruz, and it was the development environment that he wrote Rogue in. No doubt it would have been exciting and tantalizing to get a chance to work on the BSD project personally, something like a pilgrimage that had no expiration date. He would have already known a lot of the programmers on the project by reputation, by using their software, so the experience must have been pretty exciting. And of all his new co-workers, there was one that Toy was especially excited to get to know. That would be one Ken Arnold, the author of Curses,

the library that made Rogue possible. Arnold may have been just as excited to meet Toy. As luck would have it, Arnold himself was a huge fan of Rogue. The game had preceded Toy through the ARPANET onto Berkeley's campus. But he had some issue with Toy and Witchman's program. Rogue worked, broadly speaking, but some technical aspects could be made a whole lot better. Specifically, it wasn't using curses to its full potential. Toy knew this too. He may have been a good programmer, but the best person to get Rogue running better and to use curses better had to be Arnold. With both Toy and the code now at Berkeley, it was only a matter of time before Arnold would join up to help polish the game. Improvements to the codebase of Rogue were important, but it's one of those boring

operational things. As any programmer will tell you, this kind of stuff is really at the core of software development. But it's not very flashy. With Arnold's help, Rogue started to run faster, maps would draw more quickly, and with a little tweaking, menus were operating a lot more smoothly. But there was a more flashy side to Rogue's tenure at Berkeley. You see, a big part of the BSD project came down to picking and choosing software. The operating system, like any other, came with a pre-selected package of programs and libraries. You get things like the Curses library, fancy text editors, programming utilities, all the stuff you need to get a computer up and off the ground and make it useful.

Which software is included in an operating system is an important decision. The minutiae of which version of text editor you should ship with may seem boring, but it could have major implications for your user down the line. You need to be able to provide what users want. While TOY was at Berkeley, Rogue only became more popular on campus. The program's arrival had preceded him, but his arrival on campus and the subsequent improvements that he and Arnold implemented made the game even more popular. So when programs were being selected for the next release of BSD,

So when programs were being selected for the next release of BSD, Rogue was widely requested. In 1984, BSD version 4.2 would be released, complete with a copy of Rogue. The humble game had already been spreading quite a bit, but once it was part of a standard BSD installation, it really picked up steam. This was the most popular version of Unix at the time that was being used on large computers. What's more, a huge amount of the mainframes on ARPANET were running BSD. So as those mainframes were upgraded to the newest release, Rogue came along for the ride. However big Rogue got at Berkeley, the university would ultimately just be a stopover for Michael Toy. After a few years working at the campus computer lab, he moved on to another job, one a little further away. The new job would be

in Italy, working as a consultant for Olivetti. Originally a typewriter company, Olivetti had been working on breaking into the computer market for quite a while with some success. It should go without saying that Toy was working at the computer branch of the company. Just like any respectable computer lab, Olivetti was outfitted with a mainframe running BSD Unix, so once again, Rogue preceded Toy's arrival. Toy's actual job at Olivetti isn't that important to our story. Rather, it's simply the setting for him to meet the next player. One of Olivetti's systems administrators at the time was a programmer named John Lane. Rogue was already well known to him. In fact, it was one of the most used programs

on the mainframes that he managed for the company. Lane himself worked out of the US office, but he made the occasional trips to the home office in Italy. And on one of those trips, as fate would have it, he met Toy. In Lane's words, Michael and I became fast friends. I said, hey, your game is unbelievable. We should get that running on the new PC that just came out. End quote. The PC that he was referring to was, of course, the IBM PC. It had only been unveiled a few years before, but had already become the next big thing in computers. The PC was primarily a business machine, but games like Colossal Cave Adventure had already made the jump from mainframes to this new platform. There was a small but growing market

for more games on the fledgling computer. It was a chance to get Rogue out into the larger world. The game had already become a mainstay on mainframes, so why not take it to the next level and bring it into the home market? Even better, they may be able to make a little bit of money off the whole affair. Following that line of thinking, Toy and Lane left Olivetti and founded Artificial Intelligent Design. The name doesn't really matter that much, it may as well have been called Rogue Incorporated, since the company would spend its life bringing the game to new platforms. And the first would be the IBM PC. Lane would head up this version, partly since he had some

experience with programming for the IBM machine already. But it wouldn't be a trivial process. Rogue was written for Unix mainframes, and the PC was a totally different computer. There was no Curses library for the new computer. But in exchange for that, Lane got access to color graphics. There was also more memory to play with. A well-appointed PC could have up to 256 kilobytes of RAM.

And you didn't need to share that between users. And the character set was different. IBM implemented all the standard letters and symbols that we see on a keyboard, but it also included an extended set of characters, such as smiley faces, some foreign language characters, and even some characters specifically for drawing rudimentary graphics. PC Rogue ended up being a total rewrite under the hood, but it kept the same gameplay, albeit with some more colorful and improved graphics.

Rodney was now replaced with a smiley face. Walls were now more solid than the earlier dashes. Toy and Lane would try to sell copies of the game themselves, but they'd meet with mixed success. It's important to note here that the spread of the game, from Toy leaving UCSC, to BSD shipping with Rogue, to Toy leaving Olivetti to make a PC part of the game, took place in the span of just two years, from 1982 to 1984. To paraphrase Witchman, during that time, quote, Rogue was my resume. It spread was so fast among the burgeoning computer scene that a lot of doors were open for everyone involved with the game, and a lot of opportunities showed up without prompting. One of those came from the company Epix, a game developer

and publisher. One with a lot more experience than the very new Rogue Incorporated. So to the list of fans of Rogue, we can now add all of UCSC, UC Berkeley, almost anyone on ARPANET, Olivetti in both America and Italy, and, it turns out, the employees at Epyx. Rogue had become somewhat of a favorite game around the office, so much so that there started to be internal pressure to help fund AI Design's work to port Rogue to new computers. So in 1984, Epyx got in touch and struck up a formal contract with AI Design. The details worked out something like this. Epyx would pay the Rogue team to produce more ports of the game to other computers, starting with a new version to the Macintosh computer.

Epyx would also publish, advertise, and distribute the game. It was just the kind of opportunity that Toy and Lane were looking for, so they took the deal. The newest versions of Rogue in the works were going to be a pretty big jump from the Unix original. Up to this point, each version had used text characters to draw its quote-unquote graphics, but the new Apple Macintosh offered a chance for a really big upgrade. Apple's machine was all about graphics, so the rogue crew was excited to make use of the Mac's shiny new black and white graphics. The thing was that neither Toy nor Lane knew how to program the thing.

The thing was that neither Toy nor Lane knew how to program the thing. It was going to be a pretty big undertaking to get the game off the ground on the young system. Not to mention that neither of them had much experience with graphics. So, they reached out to someone that they knew could help them. Someone who was already intimately familiar with Rogue. That would be Glenn Witchman.ichman himself had been estranged from Rogue for a number of years. Major development on the game seemed to follow Toy as he moved from place to place. But starting with the Macintosh version, he joined back into the fold. While Toy

and Lane worked on the code for the game, Wichman handled drawing all the graphics. the code for the game, Witchman handled drawing all the graphics. The flashy new version would use sprites and tiles to render a 2D world in a pixelated black and white. Compared to today, it's rudimentary, but it was a huge jump from the Unix and PC days. Rodney was now a little knight, complete with armor and even a hat with a feather in it. As legend has it, the Macintosh version of the game was built by the new team of three while snowed in at a cabin near Lake Tahoe. I really like the idea of a bunch of programmers stuck in a cabin for days on end, but with the state of evidence, that's something that I can't really confirm or deny. After the PC and Macintosh versions were completed and starting to sell, the team worked

on various ports. There were versions written for the Amiga, the Atari ST, and the TRS-80. All would have varying levels of graphics, but the same gameplay. Rogue was already a huge success amongst computer nerds, and rightly so. Even its earliest versions with black and white Texmo graphics were fun and addictive. Later iterations, the graphical versions especially, must have been huge hits, right? Well, not so much. There was modest success, the team made some good money, but Rogue didn't catch on fire in the home market. some good money, but Rogue didn't catch on fire in the home market. Even with the backing of Epix, the game just didn't take off. Now, there's a lot of factors behind that, and I've seen a lot of competing theories as to the poor sales. I've heard it blamed on piracy, or poor marketing,

or gamers just expecting better graphics out of their games. But I think it comes down to Rogue failing to make the transition at the right time and place. The gameplay of Rogue is all about discovery. You can spend hours upon hours trying to find new secrets in an ever-shifting and changing dungeon. You couldn't find a better analogy for the environment that it was developed in. The inspiration for the Dungeon of Doom came from games that spread over the ARPANET. In that early era of the internet, you didn't have search engines. To find something, you had limited options. You'd either find out via word of mouth, or you'd spend hours spelunking around the network seeing what you could find.

Once finished, Rogue itself would become part of that network of word of mouth and hard-fought discovery. The people who found and fell in love with Rogue were already used to that game from their time on ARPANET or in computer labs. Something that wasn't as prevalent on home computers at all. There isn't the same sense of a discovery when you walk into a computer shop and buy a small cardboard box full of floppy disks. The other problem came down to timing. Rogue had become wildly popular with programmers very very quickly. The same type of people who made Rogue in the first place were the same type of people who loved it. The PC version would

be completed in 1984, with the Epyx release coming sometime around 1985. But even by then, there were already Rogue-inspired games floating around. There were games like Hack, first written in 1982 and later rewritten for PC in 1985, or Moria, which first appeared in 1981. These games are now called roguelikes, and they would copy and expand on the original gameplay of Rogue. This tradition continues on into the modern day, but it started very early on in Rogue's history. The distinction between the AI-designed versions of Rogue was that these roguelikes were

all free. Instead of buying a commercial version of Rogue, you could just play a free roguelike, often with much more features than the original game that you'd have to pay for. Outside of the roguelike flood, there were also just improvements being made to more standard RPGs. Remember that part of the reason Rogue was developed was to fix the problem of running out of adventure games to play. But with more adventure games being produced and new games being longer, it would take more time to run into the replayability issue that Rogue was so good at addressing. Many of the gamers that may have loved Rogue were simply busy with newer adventure titles. But even if Rogue never made Toy, Witchman, Arnold, or Lane millionaires, it may have done something better.

The Rogue formula can still be seen in games today. It set up a genre for later success. Even after all the advancements in graphics and gameplay improvements made over the decade, Rogue is still a fun game. It's still something good to come back to again and again, and again, and again, and every time, it'll feel just as new as the first time you played. So that does it for today's episode and for our discussion of Rogue. The game went from a hobby project at UC Santa Cruz to a standard part of BSD to a commercial project. It eventually flopped in the market, but at every step of the way it gained fans and

massive acclaim. Rogue grew out of a very specific set of circumstances. Toy and Witchman wanted a way to keep playing adventures in cyberspace despite the limitations of other games. But it turned out that the same feeling was shared by many in the computer scene at that one time. Despite Rogue itself never becoming a household name, it inspired games that would go on to become much more popular outside of computer labs. So how should we make sense of Rogue's legacy? Personally, I like Witchman's take on the game. Quote, I think Rogue's biggest contribution, and one that still stands out to this day, is that the computer itself

generated the adventure in Rogue. Every time you played the game, you got a new adventure. in Rogue. Every time you played the game, you got a new adventure. End quote. That was the biggest single contribution that Rogue made to video games that would follow. The idea that a game could go on forever and still be fresh and new. Many later games that aren't explicitly roguelikes make heavy use of this idea. You have things as simple as randomized quests that show up in a lot of modern RPGs to fully procedurally generated games like No Man's Sky. Rogue unleashed something new and exciting that we still benefit from today. If you want to learn more about Rogue and its descendants, then you're in luck. There are a lot of resources within easy reach. I would suggest you start by playing the game. There's many versions to choose from. The Internet Archive is a great way to get the

game from the comfort of your web browser, but you can also track down later updates to the original. Many roguelikes are free and open source and easy to find, with Slashim or NetHack probably being my personal favorites. If you want to learn more about the history of Rogue and its derivatives, then I'd highly recommend tracking it down a copy of Dungeon Hacks, How NetHack, Angbang, and Other Roguelikes Changed the Course of Video Games by David L. Craddock. The book has some great original interviews with the creators of Rogue, and it proved an invaluable resource for me in preparing this episode. Thanks for listening to Advent of Computing. I'll be back in two weeks

time with another episode exploring the strange path to the modern world. Until then, if you like the show, why not take a minute to share it with a friend? You can also rate and review me on Apple Podcasts. If you have any comments or suggestions for a future episode, go ahead and shoot me a tweet. I'm at Advent of Comp on Twitter. And as always, have a great rest of your day.