The New Yorker Radio Hour - Unearthing Entombed

Episode Date: January 26, 2021

Now that we are some sixty years into the digital era, the early days of modern computers are growing distant and mysterious to us. The field of game archeology seeks to uncover the origins and uses of these technological artifacts, and to determine what they tell us about the industry that created them. The New Yorker writer Simon Parkin and his producer Alex Barron try some archeology of their own on a video game from 1982 called Entombed. With the tiny amount of memory on an Atari 2600 cartridge, Entombed accomplished something new, and to this day nobody can figure out how it worked. Was it really developed during a programmer’s drunken blackout? New Yorker Radio Hour listeners, we want to hear from you.  We have a few questions about the show and how you listen to it. The survey takes about twenty minutes, and your feedback will help us make our podcast better.  Take the survey here.

This is The New Yorker Radio Hour. I'm David Remnick. Simon Parkin writes about technology for the New Yorker, and he was on the show recently to talk about playing video games with his kids during the pandemic. At the same time, he was working on a story from the dawn of the video game, age, about a game that came out when Simon was barely out of diapers. Simon's partner in telling radio stories is our producer, Alex Barron. So here's Simon and Alex. Once upon a time.

Specifically, the early 1980s. In a far-off land. Santa Monica, California. There was a bunch of hippies making video games at a place called Western Tech. And one of the projects they were working on was a game for the Atari 2,600, called Entombed. In Tumed, you play as an archaeologist who is trying to escape from an underground catacomb. But this is a video game from the early 80s, so your character is, just a little stick figure that you navigate through this blocky maze that scrolls up from the bottom of the screen.

If you get stuck, then the maze pushes you to the very top of the screen and you die. Now, the programmers working on Intumed had a big problem. They didn't want the player to just play the same maze over and over again, because that would be boring. But Atari cartridges had a tiny amount of memory on them, like two kilobytes. That's about a thousand times smaller than a photograph you might take off. your mobile phone today. Not nearly enough room to store a bunch of different maze designs. So they came up with this idea. What if instead of drawing a bunch of different mazes and trying to fit them all into that tiny bit of memory, what if instead of that they just wrote some code that could

draw mazes? Then you wouldn't have to store all the mazes, you just have to store the code, and it could generate a new maze every time a new game started. These days, there's a term for this kind of coding. It's called procedural generation, and it's a big deal in video games today. Like if you've ever played Minecraft. Every time you start a new game, it gives you a new map. That map is created with procedural generation. Here's the problem, though. In the early 80s, nobody really knew how to do this yet.

So for weeks and weeks, the programmers on Entombed are banging their heads against this problem. They just can't settle on the right algorithm. And so, the legend goes, one night, one of these Western tech programmers, these early techies, goes out to a bar and gets super drunk and also super stoned. And he blacks out. And when he wakes up in the morning, he's at home, and he discovers that while he was blacked out, he wrote an algorithm to generate a maze for entombed. And not only does he not remember how he wrote this algorithm, but he doesn't remember how he was blacked out. But he doesn't remember how the algorithm works.

And he checks it, looks it over, and realizes that this really is the solution to the problem they've been looking for. So in the case of Entombed, we're taking a look at procedural generation. And it's evolution. This is one of the earlier examples of prokgen use in game code. This is Andrew Reinhardt. He's an archaeologist, but Andrew doesn't do his digging in ancient burial sites or market places. He does his digging in video games. First of all, let me explain that I was a trained classical archaeologist. I was a pottery

specialist, and I don't know if this will get me into trouble, but I don't see a difference between the archaeology of a pot that we've gotten out of the ground or of a coin and the archaeology of a digital artifact. All of these analyses that we might do of games, you know, yields the same kinds of answers about what people. people were thinking about, what they were doing to entertain themselves, what they were doing to make a living. Legends like the mysterious maze generation algorithm of Entombed, you know, you hear them more and more.

We're maybe 60 years into the digital age now. And the things that happened in the very early days of the digital world are growing kind of mysterious to us. Even when we're talking about early versions of technologies that we still use, like procedural generation, how those technologies came up. about and why can become sort of shrouded in mystery. So performing archaeology on digital artifacts like in tombs can help us better understand how we got to where we are right now with technology.

So we decided to do some digital archaeology of our own. Simon and I are keen to try to solve this mystery. Yeah. But we are not archaeologists. So we need some help from you to figure out how exactly we go about. about this. Yeah, so there's a method to this archaeological. Teach us the method, oh, young, young Jedi.

All right, so you have this digital thing in front of you. In this case, it's a video game for the Atari 2,600. What do you do? So you can decompile the source code so that you can see what the inscriptions. Well, we're not computer scientists, so we actually can't decompile the source code. Fortunately, there's somebody who has already been researching this particular artifact, and he is a computer scientist.

I'm John Aycock. I'm an associate professor in computer science at the University of Calgary, and I study old computer games. John Aycock teaches modern computer science students about old games. and I had never heard of this one before. I didn't know anyone who had ever played it, and I just tripped across and I said, hmm, amaze, that might be interesting.

An ACOC cracked open the code, a bit like an archaeologist rolling back a stone on an actual tomb. In Tumed is written in something called assembly language. It's a very early computer coding language that's very easy for computers to process, but really very hard for human beings to understand. Back in the 1980s, when people wrote assembly code, they usually included comments within that code,

basically plain English sentences that would tell a human what the assembly code did. But unfortunately, that did not happen with Entombed. There's no comments, there's no variable names, there's really nothing conveying any information at that stage. And what I have to do is I have to start with that and reconstruct a lot of the meaning as to what was going on in the code. Eventually, John was able to figure out, what the code was doing.

Do you want to try and explain this, Alex? I'll give it a shot. The maze generation algorithm is trying to draw a maze that's challenging enough to keep the player entertained, but isn't actually impossible to solve. And it does that, I guess, by going block by block across the screen and trying to decide if each block should be part of the wall of the maze

or part of a path through the maze. okay are you with me so far right i think so if i had like a sheet of square paper and i was trying to draw a maze really quickly by coloring in certain blocks and leaving other blocks blank i can sort of just look at it and see which ones to do for the maze to make sense whereas a computer can't actually look at it in that way and is using some sort of mathematical algorithm to figure it all out right exactly it's actually taking some data about the maze it's already drawn plugging it into this algorithm, and then the algorithm makes the call about whether a particular block should be part of the maze wall or part of the path. The problem is that nobody can figure out exactly what the relationship

is between the data that goes into the algorithm and the answer that comes out. The generation of this maze relied on this very odd table in the game, and it was using this to somehow produce this maze. And I was fortunate enough to get in touch with the programmer. And the programmer actually didn't have any idea how it worked either because it had been something that had been handed off to him. And it's this programmer who first tells John Acock the story we told you. The saga of the drunken coders in the bar. There did seem to be an indication. that there was some intoxication involved in the production of this code.

The programmer John talked to is a guy named Stephen Sidley. You, Stephen, how are you? Good, fine, thank you. I just wanted to ask you guys. Stephen Sidley was a recent UCLA grad when he got hired to work at Western Tech. The company was full of a bunch of crazed, drunk, and stoned misfit youth, with bare feet and long hair and torn clothes and social awkwardness and those were the sort of people at the beginning who were interested in video games. And shortly after he was hired, Western Tech dumped a half-finished game in his lap.

And I was told to pick up and finish a game that they were writing, which was called Mays at the time and eventually was renamed as entombed. No manuals, no understanding of how the machine worked, nobody's sitting around me, total, utter fear. So Sidley asks one of these hippies around the office where this code that he's working on came from. And the following story rolls out. The person who had started this game had divined this well-drunken stone in a Mexican bar drinking tequila one night. Sidley told John Aycock his story, but it was also told to Sidley secondhand.

And we wanted a primary source here. This is the New Yorker Radio Hour, Simon Parkin, and Alex Barron are bringing us this mystery from the early days of video games. We'll continue in a moment. Do you happen to remember the name of the guy who wrote the algorithm? I want to say Newell, but I may be mixing him up with somebody, so no, I wouldn't fall on my sword about that. You can sometimes get the feeling that the internet puts, like, all of the information in

the world right at your fingertips, but the internet can also be, like, the world's largest haystack and this guy Newell turned out to be a needle. We find an interview on an Atari fan site from 2008 with a guy called Paul Alan Newell. He does say that he worked on the entombed maze generation algorithm. So I have to now join an Atari message board and send a message to the guy who did the interview. But the only email address he has for Paul Allen Newell is dead. We can't find him on Facebook or on LinkedIn. He doesn't seem to have a web page. So I take his name and this defunct email address we have and just start scouring the internet.

And I find that email address pops up a lot on a message board for... Honestly, I'm not actually totally sure what it's for. It's what seems to me to be a bunch of very smart people talking in a very technical way about coding. Eventually, though, I find one post from a few years ago where Paul is complaining about having to change his email address. So I take his name and run it back through the search function on the board to see if anybody else is posting with his name, but from a different address. And that's how I unearth an email I've never seen before. So we cross our fingers and send a message. Well, when I got the email, first thing I did was I checked up to find out who you were just to make sure this was for real.

And I'm going, oh dear, it is for real. Alan Newell is retired now. He lives in Southern California. And like Sidley, he was hired at Western Tech right out of UCLA. So I was assigned Towering Inferno, which basically is the movie, a video game of the movie. It was one of the first, it may have actually been the first time that a movie sold the rights to make a video game out of it. So Western Tech was making the video game version of Towering Inferno. The towering infernal. It's out of control.

It's coming your way. And in that game, you play a firefighter who has to rescue people from different floors of this building. And each floor of the building was a maze. So Paul needed an algorithm that would generate those mazes. So I and a friend went out one night having a beer and I explained the problem. And this is Duncan. Duncan is Duncan Muirhead, who is a graduate student in maths at UCLA. He goes, oh, that's no problem.

We can just generate an endless maze, and you can take static pictures of it. And so he did the math, and he didn't understand how to code. So I did the code. And together we just dreamed it up over a couple beers and wrote it on bar napkins. So can you tell me a little bit about what happens? Now you've got these bar napkins, you and Duncan leave the bar. I drove Duncan home. And I go back to my place, and before I go to bed, I take all that, all that stuff and just dumping it in the machine.

very, very rough coding job. So I'm not going to forget anything. Now, you know, in the retelling of the story that we've heard, the scene that we're given is that you as the author of this algorithm could not remember how you did it, how you did the maths. Is that part of the story true in any way? No way. First off, partially written by a stoner. I don't smoke weed, okay? very unlikely that I would have been able to have gotten drunk and whacked out if we're out on a bar

because how would I have gotten home? I coded it up over the weekend. Very unlikely that I've forgotten the thing. And this is the point when Paul pulls out a big stack of papers. I have in my hand here the entire thing documented. The whole code, paper printout, none of this electronic stuff that is going to die. Got the whole thing, the maze out. algorithm, the random number generator that Icock and Coplestone talk about the whole thing.

So that's kind of more like what happened. Where is that been for the last 40 years? Where have you kept it? My garage. Just in a box? In a box. To review the bidding. There's no smoking pot.

There's no Mexican tequila. There's no blackout. There's not even entombed at this point. Yeah. Paul says he wrote the co-cuit. for a totally different game, and Western Tech repurposed it for Entombed. Okay, so the question remains then, like, how did this legend get started in the first place? I think what may have happened is either Duncan or I may have used the excuse of forgetting

as a way to basically go, we can't provide you with the documentation. So this really is a story more about intellectual property than about irresponsible drinking. Paul Alan Newell was an employee of Western Tech, so the company owned whatever he made while he was there. But he and Duncan had written the algorithm on their own time. Now they wanted to put their code in the game, but they didn't just want to hand over the keys to their mathematical brilliance. Right. So remember how we were talking about how programmers would put comments in their code to explain what it did, and the Entombed Code didn't have those comments when it went to Stephen Sidley?

Well, Paul says that that's how he and Duncan protected their IP. They handed over the code, but not the documentation that explained how the code worked. I think this is where the whacked out of our school and couldn't remember it came in, because I don't think we wanted to tell them, well, we have the documentation, but we're not giving it to you. It's an explanation that, in retrospect, makes a lot more sense than the legend. This is classic archaeology in a way. We went back to Andrew Reinhart, the actual archaeologist, and we told him what we had dug up. The fact that they were probably protecting their IP by claiming intoxication during its authorship. Fine, you can believe that story. It's easy to believe.

You have to take it with a grain of salt. It's like talking to an artist about their art. You're going to get part of the picture, but it's not going to be the whole picture. The best archaeologists will state right up front that this is not 100%. There's always going to be something else to discover. There's always going to be something else to excavate that really adds to the understanding of this particular game, of this particular culture of these particular people. And, you know, okay, great. So here's another example of that. And it adds to that data that brings us a little closer to that limit of knowledge that we're always working towards.

Hello, Steve. Hello, everybody. How are you doing? Hi, Steve. So then all that was left was to relate what we found back to Stephen Sidley, who was, after all, the one who we'd all heard the legend of the drunken coder from in the first place. It was just the code with no comments. And that that's what you would do.

Which I was the lucky recipient of. So does that, like, jive with what you remember? No, it's like a glove. Oh, no, I'm tremendously excited by this new twist. I'm going to go tell my wife with my kids about this now. Yeah, that would absolutely be the most reasonable explanation. I just unfortunately got in the way of it, but everything turned out okay.

Simon Parkin contributes to The New Yorker, and Alex Barron is a producer for The Radio Hour. You can find Simon's piece on the best video games of 2020 at New Yorker.com. I'm David Remnick. Thanks for listening to us. See you next time. The New Yorker Radio Hour is a co-production of WNYC Studios and The New Yorker.

Our theme music was composed and performed by Merrill Garbus of Tune Arts, with additional music by Alexis Quadrado. This episode was produced by Alex Barron, Emily Boutin, Ave Carillo, Riannon, Riannon, Cala Leah, David Krasnow, Gauphin and Putubuele, Louis Mitchell, Michelle Moses, and Stephen Valentino, with help from Alison McAdam, Danny Bonner, Mengfei Chen, and Emily Mann. The New Yorker Radio Hour is supported in part by the Cherina Endowment Fund.