Advent of Computing - Episode 93 - Fun and (Horror) Games

Episode Date: October 16, 2022

Anybody up for a fright? This episode we are looking at 3 of the earliest horror video games I can find. Over this journey we will look at different programmatic ways to instill fear, how platforms can affect the route to terror, and even dig up the mystery of the first horror game.   Selected Sources:   http://www.twenex.org/ - Sign up for an account and play Haunt   https://www.zx-gaming.co.uk/games/monstermaze/default.htm - Escape from Rex and his maze!   The Untold History of Japanese Game Developers, by John Sczepaniak

There's something in the history of video games that we just don't see in other aspects of the computerized world. Games have always had this profound connection to non-digital fiction, which I find fascinating. No one has really tried to adapt Star Wars as the basis of a database management system, but countless programmers have used those classic films as the inspiration for games. Off in productivity land, parts of the non-digital world do get adapted into programs, but the focus is always on the mundane.

You get spreadsheet programs that look like physical spreadsheets, photo editing software with little pink brush icons, and, gasp, electronic mail. All useful, all important, but not the most fun. With games, fiction is often a driving force. Take Space War as an example. We don't have practical space fighters that do battle around black holes, firing missiles and lasers at each other. But there are instances of similar events in science fiction. The game isn't a practical implementation of something we use in real life. It's inspired by fiction.

This phenomenon extends beyond the realm of sci-fi. Any genre you can think of has served as influence for at least one video game. But not all genres make for easy digitization. Sci-fi, hey, that's relatively simple. You can just program up some spaceships with lasers. Done. But what about something that necessitates stronger human emotion as a key component? What about horror? It would take a longer time for horror to make the jump into the digital realm. Why? Well, I think it's partly because it requires a little bit of subtlety. You can't really just have games say, oh hey, here's the part where you get scared. That was spooky, wasn't it?

That doesn't really work with us. You need a little bit more. So how did the jump occur? How can you digitize something as primal as fear itself? Welcome back to Advent of Computing. I'm your host, Sean Haas, and this is the second entry in Spook Month 2022, Fun and Horror Games. Today, we're going to be examining the earliest horror games I can find, and hopefully getting a little scared in the process. Now, I'll just start out with this. I'm not a fan of most modern horror games. I scare easily. Jump scares have a very profound effect on me, and it's not an effect that I find very enjoyable. That said, I do appreciate the genre, and there are some games that I actually

enjoy. For instance, I haven't finished it yet, but I've been playing a lot of Pathologic lately. That game is definitely in the horror genre, and I've actually enjoyed it. I guess I find that the jump scare kind of games I don't like so much, but slow burn kind of psychological stuff, I enjoy. I'm fine getting a little spooked by that. It can be a little bit difficult to peg games in the genre sometimes, partly because the genre itself is so expansive. The general gist here is that a horror game scares you. It's quite literally spooky.

That can be accomplished in a lot of ways. What makes this a little weird and a little interesting, at least in my head, is how personal of an experience fear can be. Some people have very specific phobias. A jump scare in a game, or in real life for that matter, can physically make me jump, while for others it might do nothing. I'm fine with small spaces, but I have friends who are very claustrophobic. One person's horror is another person's fun seasonal decor. Accordingly, the horror genre has a widespread to its spooks. That means that if I really wanted to be annoying, I could just pick any old game and justify it as a horror title. However, we don't need to go down that route. It all comes

down to feel at this point. If a game has the right set dressing, the right atmosphere, all the right intentions, then that can be a horror game. But when did the genre start? What was the first game to label itself as horror? And does the end product match the label? I don't want this episode to just be a dive into what's scary. Instead, I want to explore different strategies that software developers have used to create terror. I think this should be more interesting the further we go back. As computers have become more capable and more graphical, it's easy to scare someone away from their keyboard.

Rewinding the clock, we get to an age with fewer options and just less power in general. Can simple graphics be scary? What about no graphics at all? Can you induce fear with text alone? Well, let's find out. But before we jump in, I have my usual announcement these days. I'm currently still looking for more authors for Notes on Computer History. That's a journal on the history of computing that I'm working to put together. It's planned to be a community project, and the community is growing, but we could use your help. I'm looking for people who are experienced editors or inexperienced authors. The idea of the journal is to provide a space for anyone who wants to write about the

history of computing. You don't have to have any background in academics or writing at all. You just have to want to contribute. So if that's you, and it probably is if you're listening to this podcast, please get in touch or go to our website. The project's website is history.computer. You can go there to find details on where to send submissions. And really, any time's a good time to submit. So if you're on the fence, let me help you jump off that. I want you to write for me. So go over, write up a draft, and send it to me. I'll hook you up with an editor, and we'll be able to make the first issue a great one. With that out of the way, let's get into today's episode.

There's a healthy debate over the first horror video game. One option that I've seen put forth is Atari's 1972 arcade machine, Killer Shark. It's a shark. You shoot it with a light gun as it chases you. That doesn't really smack of fear to me, and it's also not very complicated, so as such I'm not very interested in this contender. Another option is, and forgive me for the pronunciation, AX2 Uchiyosouzen Nostromo. This was a video game written in the late 70s by a developer named Akira Takaguchi. The game's name might be a tip-off to the fact that it was developed and released in Japan.

It never saw an English release, and as a consequence, there isn't much information about it on the English internet. However, there are two points that I want to highlight here. First, Nostromo was based off an earlier stealth game. This information comes from the one useful source I've been able to find, the Untold History of Japanese Game Developers. The book has an interview with Takaguchi. One of his friends had also been working on a game project, one centered around stealth. In these games, a player attempted to complete tasks while remaining hidden. The idea was to avoid enemies instead of fighting them. So here we have one aspect to horror, the removal of

agency from a player. Instead of a game serving as some power fantasy, these early horror games were going to be in the opposite direction. You had less power in Nostromo than, say, were going to be in the opposite direction. You had less power in Nostromo than, say, Space Invaders. I know it's a silly comparison, but let's just go with it. Second, Nostromo was loosely inspired by horror films. Nostromo, the namesake of the game, is the ship from the film Alien. It's kind of a seminal work in the genre. Takaguchi was, It's kind of a seminal work in the genre. Takaguchi was, at least in part, trying to make a computer as spooky as this film, trying to port over some of the feel of the film.

That's the whole adaptation thing I was talking about earlier. The game, as near as I've been able to find, is played out on a ship. You try to avoid an alien while carrying out various objectives. This very well may be the first horror game, but we don't have enough information to be sure. One of the first English-language horror titles was a text-based adventure called Haunt. It was developed over the course of John Layard's graduate program, so the date for this game is a little squishy. We're looking at a period between 1978 and 1981, although some tellings just split the difference and say that Haunt was developed in 79. Whatever year you choose, it's clear that Haunt exists very early in the overall horror

game chronology. Better still, the code has been preserved, so we can still play the full game itself. The story of Haunt starts with Laird's graduate research at Carnegie Mellon University. There's this trend in mainframe games from the era. Game developer wasn't really a job title, at least it wasn't a title backed by a degree program. Instead, many who developed early computer games did so as a bootleg kind of gig. A game would either be written in spare time, or used as a vehicle for some tangentially related project. Haunt falls into the second category. Laird was operating from a very specific background. He was working under Alan Newell during his time at Carnegie Mellon. That's THE Alan Newell of IPS fame,

one of the pioneers in the field of artificial intelligence. By the end of the 70s, Newell and AI in general had moved past its earliest days. Lists were still important, but that data structure was more of a fundamental at this point. The field was now large enough for specialization. Newell's lab at this point was researching something called rule-based systems. I've also seen these called, somewhat confusingly, production systems. As a webtech guy, production system means something else entirely, but there is this older meaning, so that's an interesting wrinkle for me to learn. I think the first name speaks for itself here. These are mathematical systems that follow a set of rules.

These are mathematical systems that follow a set of rules. The second name, despite being confusing, is also more obtuse. They're called production systems because these programs produce some conclusion based on a set of rules and state data. This terminology is also found within the system itself. Each rule set is also called a production, but we'll get back to that. Now, this can all sound a bit simplistic. I mean, isn't a program with just a bunch of if statements a rule-based system? Well, yes and no.

Rule-based systems are more specialized than that. In general, a rule-based system works like a kind of mathematical model. The system has some internal state. Then you have a set of rules that modify that state based off events or selections on that state. It's making choices similar to logical inferences. At least, that's what it's trying to model. The easiest example here is what's known as an expert system. This is a program that can aid in diagnostic tasks or information-gathering tasks. You might have an expert system for medical diagnosis. That's kind of the canonical example.

The state in this case could be a human body. You have vital statistics like your heart rate, temperature, general shape and size, and medical history. Data could be added via a questionnaire. Based off a series of questions, the state would be updated. You'd have rules programmed in like, if the patient has a fever, then they are sick, or if the patient has fever, chills, and nausea, then they may have the flu. That's a really basic model, and as with most of my examples, it's not that useful. To make a rule-based system practical, you need a whole lot of rules. That in itself presents something of a problem. Just writing a program with a bunch of if statements isn't very clean code.

It's not very readable. It's also not very flexible. Running complex logic statements, or building nested statements, will quickly lead you into a tangle of code. There's also the matter of performance. A single conditional is pretty darn fast. There's stuff on the silicon to help with that. But what if you have 10 that must be executed before arriving at a result? Or 100? Or even thousand. A normal language doesn't have tricks that make that kind of operation faster. You just have to kind of blindly run one after another after another. There are also a number of technical features that normal languages don't offer, but

this will do for very shallow analysis. For serious rule-based systems, you need a specific environment. The solution being developed at Newell's lab was a series of languages called OPS. I think highlighting OPS will give us more concrete examples of why a special language was needed and what these languages could do. However, we already land on a fun problem. Hant was written in OPS4, presumably the fourth version of this language. That version isn't super well documented. It's attested to, but not preserved in the best detail. OPS5 seems to have been more popular, or one of the more popular languages in the series.

You can actually find pretty good robust documentation for number 5, so my working knowledge of the language is all pertaining to OPS 5. The overall structure and concepts should be the same, but if there's any OPS 4 adepts out there, then please don't get too mad with me. In general, rule-based systems are modeled after the human brain. That's just how AI was trending in this era. So there's a certain fuzziness to OPS5 that's inspired by animal or human neurology. The general breakdown of an OPS-5 program is simple enough. You have working memory, which contains the program's state data. This comes in the form

of a set of what OPS calls entries, but these are pretty much just tiny, almost objects. pretty much just tiny, almost objects. Each entry has a class, but this isn't a class in the larger programming sense. It's basically a name used to group entries. So if I had a program for simulating dogs, I'd have a bunch of entries each with the class dog. Each entry can have properties. These are assigned in a kind of lazy fashion, so you don't have to declare some prototype for the dog class. Instead, you just add a new dog entry, give it a tail property, and give it a name property. The next dog might not have a tail, but would have a name and a collar property. It's all very free-flowing, so it gets a Ted Nelson point in that category. I might need to make a sound drop for that eventually. Anyway. The second part of an OPS program are the productions. These are the specialized

if-then clauses that make up the active part of the code. Each production is composed of a condition, the if, and an action, the then. On the surface, that's pretty self-explanatory. You have a specialized syntax for if-then statements, and that's it, right? Well, no, there is more. Most languages execute statements sequentially. You go line by line by line, jumping to follow any control statements that may require it. You can actually track execution by just reading down a page. OPS is different, which brings us to the fuzziness I mentioned. OPS code operates in a control loop style. mentioned. OPS code operates in a control loop style. To start the loop, OPS looks for entries in working memory that match some production condition. If a condition matches multiple

entries, then conflict resolution is performed until only one entry is left. Then, the condition's action is executed on the selected entry. The loop is continued until an exit criteria is met. The conflict resolution step should be the only part of that rundown that sounds a little different. There are three strategies used by OPS-5 for resolving conflicts. The first is called refraction, and essentially states that a condition can't match the same entry twice in a row. On the digital side of things, that can prevent certain kinds of infinite loops from occurring. The AI rationale is that organisms have refractory times between

actions. A neuron doesn't normally fire over and over and over again. It has to relax before it can fire. The next rule is called recency. Each element in OPS has a time property that represents when it was last selected. That tag gets updated when an element is, well, selected, but it can also be manually updated. OPS will always pick the most recent element when resolving conflicts, which is supposed to mimic how memory works in organisms. Just as an aside, this is somewhat similar to how some languages handle garbage collection of unused memory. The final rule, if all else fails, is specificity. If all entries pass the refraction rule and

are all equally recent, then OPS will check which entry matches the production's conditional the most closely. Let's say you're selecting dogs named Spot with tail properties. You get back two dogs with that name, both with tails, but one has cute little socks. OPS would select the one without the socks property, since the first dog more specifically matches the conditional. I think it's plain to see here that a normal programming language can't do all of this, at least not on its own. I guess this has been a long rambling way to justify OPS as a language. So it's specialized, but what's it actually good for? You could use OPS as a research language, or to create an expert system, or you can make something a little more bulky.

In 1977, Colossal Cave Adventure, the expanded version, that is, was blazing across the ARPANET. Anyone who had access to a terminal on that network was exposed. That included John Laird over at CMU. Adventure was really something special for the time. There were earlier text-based games, but those were all pretty obscure and pretty isolated events. Adventure quickly became a cultural touchstone for programmers. The game had a one-two punch that helped it become viral, for lack of a better term. Adventure was scored, so each time you died, you could gauge how far along you had progressed. Getting full points took a lot of effort and a lot of exploration.

The entire game is really just one big puzzle. This made it easy to be drawn in. The game was also funny in an irreverent sort of way. The world of adventure is conveyed via text alone. From that interface, you delve into the colossal cave to solve puzzles and find treasure. It wouldn't be very engaging if every room was described in a straightforward way. Oh, just, you enter a room with exits to the north and south. A dragon blocks your way. You can defeat the dragon with a sword. That's not very fun. The text of the game gives you lavish and fanciful descriptions.

You don't enter any old hole in the ground, you bust in through a locked grate and drop into darkness. You don't slay the giant snake with a sword, you scare it away with a bird found in a nearby chamber. The game has this personality that's infectious. chamber. The game has this personality that's infectious, so it should come as no shock that programmers the world over decided to try their hand at the task of creating their own adventure. Laird was just one programmer among many, but Haunt is pretty unique. You see, adventure's source code was easy to come by back in the day. It was also written in Fortran, so most programmers could easily read it or use this code as a base for their own game. Laird went a new route. He decided

to use OPS4. At the time, OPS was a relatively new research language, so a big game would be a good way to test the thing out. It also helps that rule-based systems work really well for text-based adventure games. On the back end, a text adventure is really just a state machine. The entire game world is broken up into a series of locations. That's one of your state values. You also have an inventory of items you're carrying, so there's more values. Then you have miscellaneous things like the state of puzzles, a score, health if you track that. You can also flip things around a bit. Instead of having some player object that has all these properties, you can have a bunch of smaller objects. Let's take items, for instance, since

that's the easiest example to work with. You can set up each item as its own object of the class item. Those objects each have a name and a location. One of the first items you run into in Haunt is a wetsuit. On the code side, it's represented as an object whose initial location corresponds to a hall closet. Once you take it, the location is changed to your inventory. In Haunt, everything from locations to items to creatures are their own objects. As the player interacts with the world, those objects are selected, updated, and sometimes removed. That all fits in wonderfully with how OPS operates. It makes for an elegant solution.

For a time, around 79, Haunt was actually the largest rule-based system in existence. That's some cool research product right there. But what about the game itself? So far I've just told you about the code, which, while interesting, isn't very scary. Clont takes on the expected interface and tropes of any other text-based adventure of the age. You traverse a game world by issuing simple commands, and the game responds in a textual fashion. The theme is what differentiates Laird's game. Adventure was pure fantasy, from its treasures down to its gnomes. Haunt is all campy B-movie horror. Laird has said he was inspired by Saturday

morning cartoons and old comics, and it really shows. Haunt isn't so much jump-out-of-your-seat scary as it is spooky with a touch of fright. As for the game's setup, I'll quote from the program itself. A long time ago, a young couple was picnicking near the woods on the outskirts of town. They were celebrating the birth of their first child. Unfortunately, a crazed moose inhabited that area and attacked them. The child and husband were unharmed, but the wife was gored to death by the moose. After the funeral, the man bought the land where the incident occurred and constructed a large mansion, Chez Mousse. He filled it with the treasures of his family, and claimed that his wife's soul was still in the area. He vowed to remain in that mansion

until he had returned her soul to human flesh. He tried to bridge the gap between life and death to reclaim her. Some say he was insane with grief, but others claim that the madness was in his blood and his wife's death brought it to the surface. End quote. You play as the child of this fated couple. You had been separated from your father soon after the death of your mother and are only now returning to Che Moose to find out the truth of your family. And, hopefully, get rich in the process. Many adventures have come before you, but none have escaped this haunted mansion. From there, the game plays out in a characteristically zany fashion.

You find secret passages, break into safes, run from monsters, and search out treasure. Now, I've played quite a bit of Haunt. Its code was thought to be lost for a number of years, but it's recently been found and restored. I haven't beaten the game, but I've racked up a respectable score, so I can tell you that the game isn't all too horrific, but it does have some scary moments. What got me was the lack of power your character has. The game is good at removing agency from a player, leaving you trapped or in danger. The way out of these situations is always some puzzle. You have to think laterally or try a bunch of combinations to save your skin.

This is combined with the insanity mechanism to great effect. As mentioned in the game's intro, your character carries a genetic disease that predisposes you to madness. It's what got your father, and it might get you too. As you explore the mansion early on in the game, you start exhibiting symptoms. As near as I can tell, this is a timed event, so you start getting messages after a certain number of actions. You sweat, you get dizzy, and you eventually collapse and end up being revived. On my first session, this happened while I was stuck in a maze of ventilation shafts. To set the scene, I just had a run-in with Dracula. I left the room with the count and didn't know if I was being followed.

I didn't know if the game was smart enough for that. I came into a room with an entry into a ventilation shaft, so figured, hey, why not duck in there and have a look around? I was keeping notes and drawing a map so I could find my way around, but I still ended up getting lost. It was while I was trying to figure out the maze that my character started sweating. A few moments later, I was dizzy, then disoriented, then waking up in a closet somewhere else in the house. For me, at least, that was effective enough to leave me a little spooked. I felt the claustrophobia and fear of the unknown, if only for a brief second. Haunt is relying on the theater of the mind, much like

all text-based adventures. The text interface gets you into this headspace where you have to imagine what's going on based off the prompts the game feeds you. You aren't shown the image of your player slowly losing their mind as they get increasingly lost in a maze of vents. their mind as they get increasingly lost in a maze of vents. You're told, step by step, what's going on. You see how your actions impact the game and, in some cases, how your actions are futile. It's that loss of control paired with your own imagination that makes Haunt's horror more than just set dressing. You can experience a similar feeling in any text game, but the paint job that Laird put in Haunt really does make it a horror game for me. Alright, I think that's probably enough text-based spooks, so let's move on to something slightly more graphic. And trust me here,

I really do mean just slightly. I think the best introduction to this next game is the same introduction I had. When I'm doing these vignette-style episodes, I'll usually finish up all the work for one part, close it out, and then move on to the next section. I'll have some sources picked out, but not a whole lot of research actually done. And, well, this is a game episode, so some of my research is, you know, playing games. Perish the thought. Now, I did mention I haven't really gotten that far in Haunt. It's a 440-point game with points awarded for grabbing treasures, depositing them outside

the house, and escaping. I've scored a grand total of 85 points. That's not a whole lot, but it's taken me quite a few hours, more than I'd like to admit. I figure I'll come back to it later this month, you know, for fun. But for the time being, my adventure at Chez Mousse was over, so I turned my attention to the next game on my outline. Funnily enough, we're staying in the same rough time frame. outline. Funnily enough, we're staying in the same rough time frame. I flipped on an emulator, loaded up a fake cassette tape, and within minutes I was eaten by a Tyrannosaurus rex.

Not the best start. The next game on this tour of spooks is 3D Monster Maze, released in 1981 for the ZX81 home microcomputer. This game has seen quite a bit of coverage, so I was initially a little reluctant to take it on. I like to keep it obscure here to try and add new things to the conversation. That said, I think I can add my own spin by looking at 3D Monster Maze in the larger context of early computer horror software. To start with, this is a much smaller game than Haunt. We aren't dealing with an expansive story, or puzzles, or complex logic. No walls of text either. 3D Monster Maze is just what it says in the title. It's a 3D maze with a monster inside.

The game interface is highly simplified. After you get past the introduction screen, you're dropped into a maze. You can go forward, turn left and right, and do nothing else. That's it. You can't run, you can't fight back, you can't even cower in fear. You can only walk through the maze. The goal is to find the exit, but that's hampered by the game's antagonist, Rex the dinosaur. The beast is somewhere in the maze with you. As you wander around, you'll eventually bump into Rex. This is usually a slow process. You'll get a message at the bottom of the screen alerting you that Rex lies in wait. As you progress, you'll be told that Rex is hunting for you. Eventually, Rex is seeing you. From there, you have to run or face your fate.

Something that caught me off guard at first is that this game isn't turn-based. I had assumed, given its vintage, that Rex would move after you moved. But no, the dinosaur is on a timer. If you don't do anything, then Rex will find you and eat you. It's not a fast process, but it means that you have to keep moving. You can't stop and think too much about the maze. You need to stumble your way to the exit. The game is also a little prone to causing jump scares. You do get a warning that Rex is approaching or somewhere nearby,

but you can't turn around that quickly. So you have this weird situation where you're told Rex is close, and, at least in my case, you start flailing around, trying to find where the dinosaur is and find an escape route. By the time you figure out where Rex is coming from, it's usually too late. I always seem to turn around just in time to see a big dinosaur followed by chomping teeth. That actually does it for gameplay. 3D Monster Maze is a relatively simple game, all things considered. This comes out even more clearly when looked at in contrast.

considered. This comes out even more clearly when looked at in contrast. Haunt is pretty sprawling, there's no way around that fact. When I play text-based adventures, I tend to draw out maps to keep from getting lost. The parts of Haunt that I played took up two sheets of graph paper already. Monster Maze just can't match that level of complexity. The reason for this difference in scale is pretty easy to explain. It all comes down to platform. Haunt was developed to run on a mainframe. It used some pretty high-octane programming to boot. I mean, the game was developed as an offshoot of artificial intelligence research. That's hard to beat.

3D Monster Maze was developed for the ZX81, a home computer with a maximum of 56 kilobytes of free memory. A stock system only had one kilobyte of RAM. That alone, sans anything else, is a major limiting factor. All the text on Haunt could easily crowd out that small memory space. Now, of course, there isn't a historical connection between Haunt and 3D Monster Maze besides the time frame. I'm only comparing these two games because they were contemporaries and they were both going for the same goal, horror. Each game's platform dictated which tactics were possible. For Haunt, you could take a slower approach, something more literary. You can have these sprawling puzzles where you have to figure out how to deal with Dracula to get onto the next room, or you have

to find a way to deal with a sea monster or find a wetsuit so you can even swim away. 3D Monster Maze took a more graphic approach because that was what was available on that platform. The story of the maze starts with Malcolm Evans, an aerospace hardware engineer. In the 70s, Evans started working for Smith Aviation in England. There, he was mainly working with larger electronic systems, but he did make some initial contact with microprocessors. That contact became terminal in 1981, when he was given a ZX81 computer for his birthday from his wife. Perhaps a gentle introduction, but that would prove pivotal in his life. I've already explained one of the computer's major limitations, the thing just didn't have much RAM. Believe it or not, it does get worse. The ZX81 could only output black and

white monochrome video. You could technically generate graphics with this, but only using blocks of pixels. So in practice, this is kind of a text-mode-only machine that allows for some fancy font-tile tricks. But on the plus side, the computer only cost about 50 bucks on release, so you're kind of getting what you paid for. You could characterize these limitations as a bad thing, just write off the 81 as a toy. However, that's a short-sighted view of things. Limitations often breed creativity. Many of these early home micros are really fun to tinker with precisely because of their limitations. It seems that Evans shared this view. So instead of laughing off the computer, he set to tinkering. As explained in an article on sockmonsters.com, Evans started out by

programming up a simple 2D maze generator. From there, it was something of a slippery slope. This is where another outside influence steps in. Evans would meet another ZX81 user in a somewhat unexpected place, a classical guitar club. You see, Evans was also an avid guitar player. What can I say, he must have been a busy dude. At one meeting, he started talking about programming with a fellow member. That third party was John Gray, who also had an interest in game development. In fact, Gray had been thinking about starting a software publishing company. The maze idea sounded intriguing, but it would need some touching up. The two would quickly become collaborators. Evans would show Gray what he had been working on, and Gray would

fire back with ideas for how to improve the maze. Throughout this collaboration, the 3D monster maze that we know took shape. The simple 2D maze was changed into a 3D world. A somewhat smart enemy was added, and the game took on the horror aspects we now know. Gray also pushed the game towards a more coherent presentation. An important part of any spooky activity comes down to setting the stage. You want to get the player in the right frame of mind. A perspective maze makes for a cool tech demo. Adding a monster and a score makes it into a game, but there's still no story there. It lacks an emotional attachment. It lacks a hook.

A ZX81 didn't have enough RAM to fit a story as large as what we saw in Haunt, but you could throw in a little text to dress things up. The final version of Monster Maze starts with a simple animation of a carnival barker. This entity acts as a narrator, setting up the game. You're being offered the chance to enter into the lair of a Tyrannosaurus rex, to see the apex predator of a bygone age, and, best of all, the dudes in his natural environment. But it's a dangerous proposition. You are literally told to enter at your own risk. The title screen even gives you a chance to back out. It tells you that if you aren't prepared, then you should hit the stop button. Otherwise, you're entering at your own risk.

As Evan explained in an interview with Sock Monsters, It was more than a clown. It was a ringmaster. That was put in because I was worried that it could frighten someone. It was half serious because it carries on to say that the management takes no responsibility just to be on the safe side. End quote. Liability aside, this is a well-employed setup. Sure, it might turn away some players, but I doubt many turned back when given the option. The game's issuing a challenge. Watch out, given the option. The game's issuing a challenge. Watch out, beyond here lies Rex. He's probably too scary for you, so, you know, you should probably just quit now. Intentionally or not, that's a

great way to get the hooks into someone, so to speak. Besides all that set dressing, 3D Monster Maze also offers some neat technical trickery. The entire game was programmed in assembly, which, in sum total, made it a much smaller and faster program. Assembly tends to make software pretty lean and mean to begin with. What's interesting here is that the ZX81 was a basic machine. That's its standard language interface. Instead of taking that path, Evans actually started his exploration of the machine with assembly language. He was trying to learn about the new, smaller computer, so that seemed natural to him just to take the low-level approach.

As a result, 3D Monster Maze started out on a very professional path. It started as relatively good software. There's also the matter of the game's graphics. Everything is displayed in this highly pixelated style. This was a result of how the ZX81 didn't really have a fully addressable graphics mode. Instead of trying to plot a pixel individually, you had to plot blocks. So graphics were generated in this weird pseudo-text mode. The maze and everything in it is rendered using a custom set of half-height font characters, most of which are just different sized blocks.

So you get this overall chunky look. Even Rex himself is roughly hewn in this fashion. Once again, it may sound like I'm just harping on the limitations of the ZX81. However, there was at least one silver lining here. Evans explained in a 1984 Sinclair user article that you could, in fact, pull a neat trick with this little machine. A savvy programmer could directly manipulate the memory buffer that stored graphics data. Now, I haven't programmed for this specific computer before, but it sounds similar to the memory-mapped display modes used by the PC architecture. Essentially, you're just able to move around what's displayed on screen by changing

what's stored in memory. You get some chunk of RAM that maps directly to what's displayed on the screen. This matters because direct memory manipulation is one of the fastest things you can do on a computer. Memory manipulation is just such a common operation that most processors have inbuilt features to help a programmer out. So if you can get away with bashing bits to update the screen, well, that can really be used to your advantage. In Evans' case, this would make it easier to render game graphics and it made the screen faster to update. Monster Maze is by no means a fast game. You kind of plod through it, but it performs well enough to keep you immersed. At least, that's been my experience playing through a relatively accurate emulator.

The 3D effect here is, once again, simple, but it works. The maze is presented in a pretty traditional perspective view. All corners meet at 90 degree angles. Lines are angled off into the distance. Floors and ceilings are flat. You know, the usual kind of projection. By 1981, this was already a somewhat common type of game. At at least it was a pretty traditionally digital game. The first 3D first-person maze game, simply called Maze, had been developed back in 1973 at MIT, so Evans was in good company. An interesting point here is that Maze and many other mainframe progeny of it were multiplayer games. In this genre, it was common to play over a network. Players would traverse the digital space in order to shoot at opponents, thus getting

points and prestige. This, of course, has all the same elements as 3D Monster Maze. These are very similar games, but there's a huge difference. Earlier maze-like games weren't horror games. You as a player had some type of control. You could move and shoot. You also didn't have some deeper reason to be there. You were just playing a pickup game for fun. By simply not having a way to fight back, 3D Monster Maze set itself apart. Add in a touch of drama, some outside reason to enter the maze,

and this seemingly similar game is transformed, at least in feel. No one could look at an early maze game and see horror, but Evans, knowingly or not, was able to put a twist on a somewhat established formula. It didn't take much to go from an unending maze of hallways to the deadly lair of the frightening wrecks. To round things out, I'm taking us back down to two dimensions. Actually, I have to bring us full circle to where we started this episode. Remember how I claimed that Nostromo, possibly the first horror video game, was a little too obscure to discuss? Well, call that a trick. We are going to close out our trifecta of horror by going back to the late 70s and trying to examine

the genre's furthest flung roots. AX2 Uchu Yusosin Nostromo. While hard to track down information about, it does give us an opportunity to look at another route to terror. Haunt instilled horror with a little camp, literary devices, and disorientation. 3D Monster Maze used a feeling of powerlessness and impending doom to spook computer enthusiasts. Nostromo takes a different tact. As I touched on back in the opening, Nostromo is a stealth game. I've often seen it touted as the first survival horror game. Similar to Monster Maze, the goal here is to eventually escape an enclosed space while avoiding an enemy. But there are some distinct differences between the two. Nostromo would be published in 1981, but the publishing

history is kind of messy. Technically, it was published by a company called ASCII, but the original version had been written at Taito, and it would be published on a number of home systems. ASCII doesn't matter so much here, since everything we care about happened at or before the Taito part of the story. To talk about Nostromo, we need to talk about an earlier game, Manabiki Shonen, known in English as Shoplifting Boy. I'm also going to be using the translation here since I'd prefer to only butcher a handful of pronunciations, so you'll excuse me. Once again, in this section, I'm leaning heavily on the untold history of Japanese game developers. It's one of the only English-language sources I've been able to find that can give us actual details on Shoplifting Boy and Nostromo. Anyway, Shoplifting Boy started off as an idle thought in Hiroshi Suzuki's head.

In 1979, Suzuki had just entered into an aeronautics engineering program, but that would really just be a background setting to our story. That same year, he encountered a game called Space Invaders. You may have heard about it. This is one of those digital conversion experiences that I love to run into. Suzuki was immediately enamored by the game. To quote from an interview printed in The Untold History, Suzuki explained his early interests this way, quote, Suzuki explained his early interests this way, quote, These could also be made using microcomputers, though, which motivated me to join a computer club in university. I was involved in this technology club. It was not a game club back then because there were not enough games to warrant it. He continues, however, this computer

club became a game club due to the wicked effects of myself and Mr. Takaguchi. End quote. Between Suzuki and his friend, Akira Takaguchi, there was now a place to talk about and play games, and eventually, program some games themselves. Suzuki's weapon of choice back in 79 was the Commodore PET 2001 computer. He didn't like this computer because he owned one, but because he could sneak in some time with a machine. There was a store near the university Suzuki attended that gave demos of a PET, so in his spare time, he'd wander in and familiarize himself with the machine,

which quickly led to the development of a few simple games. There's a lot left unclear in the interviews. As near as I can tell, Suzuki and Takaguchi were attending the University of Tokyo. It also sounds like the university did, in fact, provide some kind of computer access. Suzuki mentions giving demos of his early games at a fair held by the university, so I can only assume there were some pet computers there. The department store antics were probably just a way to squeeze in more keyboard time. Through club meetings, stolen time, and computer magazines, Suzuki and his friends learned how to program. It was during this period that Suzuki came up with an interesting idea. As he tells it, it all started at a 7-Eleven convenience store. The young programmer was picking up some, well, conveniences. As a fellow programmer, I'm betting on a late night snack

myself. That's kind of how we collectively roll. Suzuki noticed how easy it would be to just walk off with some snacks. There wasn't much staff late at night, and the tall shelves would have made it easy to skulk around. You'd only get caught if the one employee actually in the store happened to be looking down the same aisle you were committing crime in. To quote, I translated this idea almost directly into basic code. In Shoplifting Boy, you play who else but a young boy engaged in the act of theft. The game plays out in a 2D perspective, with the field composed of a set of long shelves lined in dollar signs. You run between the shelves, grabbing dollars, while a store employee paces back and forth at the top of the screen. If the employee spots you, then they'll

grab you and call the cops, you lose the game, and you're put in jail. You avoid this by ducking between shelves to stay out of view. Shoplifting Boy, in all its basic glory, would be shown at the aforementioned University Fair. It appeared alongside a number of other games developed by the rest of the Computer Club. So by fall of 79, it's safe to say that the club had been fully converted into a video game kind of outfit, and they had a secret gym in their portfolio. Shoplifting Boy is, by a pretty good margin, the first stealth-based game ever developed. Unknowingly, Suzuki had just defined a new genre. But that's not very scary.

It might be kind of scary in the corrupting the youths sort of way, but that's not horror. To get to Nostromo, we need a short bridge. The name of that bridge is Taito. Once again, this isn't spelled out directly in the interviews within the Untold History. Takaguchi explains that Suzuki worked out some sort of contract with Taito. Presumably, someone at Taito saw a few game demos and became interested. Taito provided them with a small computer lab, really a glorified apartment, and Suzuki and co. set to work developing games to pitch to the company. Some members of the Computer Club were becoming honest-to-goodness game developers. From what I gather, this arrangement formed something like an informal

think tank. As Takaguchi explains, the team would program games, then show them to their bosses at Taito. The programmers would get money for each game demo, but the games themselves weren't published directly. Instead, they served as early prototypes for later games. As such, the apartment office was full of new ideas. It was in this office that Suzuki worked up a game called Doujin, which sounds at least superficially similar to Shoplifting Boy. From Suzuki again, quote, You were inside a forest, and there was a highway with a car going along it.

You were chased through the forest by natives, and then there were these sort of roads going through the forest, and they were trying to get you to run through it so you'd be run over by another one who was driving the car. End quote. This is where Takeguchi comes into the picture. He would take the basic ideas implemented in Shoplifting Boy and Doujin and add his own twist. Takaguchi was a bit of a sci-fi nerd. While Suzuki had been inspired by A Trip to 7-Eleven, Takaguchi was inspired by films like Star Wars and Alien. Thus, Nostromo was created as an homage to those films.

The basic gameplay of these earlier games was retained, but the setting was changed. In Nostromo, the player is trapped in a spaceship. The store manager was replaced by an angry alien, presumably the xenomorph encountered in Alien the Film. The goal of the game was to collect items from around the ship, then run to the exit, all while avoiding the angry alien. Here's the major gameplay difference. You couldn't always see your enemy. In Shoplifting Boy, you had this wide-angle view from above, which was a common view for many games at the time. You could see everything occurring in the game world. As such, it was easy to avoid the watchful eye of the store worker. You only had to deal with short-term

planning. For a more well-known example, look at Pac-Man. In that game, you can see everything. You can see all the ghosts and where they're going. That turns it into a game of reflexes and more short-term planning. In Nostromo, the alien is only visible if you're in line of sight. In other words, you can only see the alien when the alien can see you. The playfield is broken up into a series of storerooms, which each contain items you have to collect in order to finish the game. Get the needed items, make it to the escape capsule, and you pass the level. From what I can tell, the alien can't get inside the storerooms, so these serve as a place to duck in and hide until the alien backs off.

so these serve as a place to duck in and hide until the alien backs off. Is this passable as early computer horror? Well, I can't personally judge this game because it's been lost to time. At least, the original version is. This is where we get to its complicated development history. Takaguchi initially developed Nostromo in BASIC for the Commodore PET. In this way, it matches what Suzuki was doing with Shoplifting Boy. In the case of the earlier game, this was to a benefit. Suzuki's Shoplifting Boy's source code had, at least at one point, been published in a computer magazine. Due to this, we have a handful of derivative works to go off.

Although I haven't seen the original code for the game, we do have ports. Nostromo, however, may be lost to time. It was developed well into this Taito contract era, so it was demoed and then seems to have disappeared. The description I've given is put together from the interviews in The Untold History, which gives us a good idea how the game worked. The problem is, I can't play it and feel the horror for myself. I can't tell you if it scares me. From what we do have, I will say that Nostromo sounds like a scary game for the period. It has the hallmark that I keep going back to, a lack of player control, a removal of agency. You're put into a situation where you're in over your head, and fighting isn't possible.

It has the proper element of camp that this early era was seeped in. I mean, come on, it's based off an alien movie. So we have the requisite coat of spooky paint, at least. I'd also wager that the stealth aspect would work pretty well here. Not only do you lack power as a player, you also lack full information. power as a player, you also lack full information. You have to make long-term plans in order to survive, and you have to adapt as what you know changes. You could get ambushed by the alien, at least in a sense. Imagine turning a corner and you thought you were in the home stretch, only to run into your enemy. It feels to me like it shares some of the approach to horror we saw in 3D Monster Maze.

But, alas, we don't have the original game to toy with. However, there is a less obscure version of the game, at least slightly less. It's been hiding in the full title. The AX2 part isn't just some alphanumeric spice thrown onto the front of the game. In 1981, Nostromo was released as part of a bundle of software, a bundle of four games. The company ASCII, which has some connection to Taito that I don't have the full background to tease out, was putting together a series of these game bundles called the AX series. a series of these game bundles called the AX series. Their target platform was the NEC PC-6001,

an 8-bit micro that was only out for the Japanese market. The idea for Nostromo was dusted off, and a developer at ASCII rewrote the game for the 6001. Assumedly, this was an assembly language, at least that's another one of my guesses. That would have been the professional way to go, and would also mean that the release version of Nostromo was a totally different codebase. It's just a different game. Now, AX2 is only slightly less obscure than the basic version of Nostromo. I have yet to find a tape image, disk image, binary, or source file for the actual release game. The best I've seen is a short video on YouTube that shows the program loading

into a main menu and gameplay for all four of the bundles games. That includes a few rounds of Nostromo. The game shown seems to match Takaguchi's description pretty well, except for one big difference. You can always see where the alien is on the screen. The whole invisible alien thing here was kind of the important bit as far as I'm concerned. So either this random video is a different game, or the release version just wasn't that scary. Whatever the case, I think I can say that Nostromo may have been the first horror game, but that hinges on solving its deeper mystery. Maybe one day the original basic code will turn up, or maybe someone listening has X2 handy, but until then, Nostromo's a big maybe. Alright, this brings us to the end of our tour of early digital horrors. I think this has given us a good rundown of early approaches to frightful

games. Haunt is a pretty literary approach, which, you know, it's a text game, it makes sense. It's hard to get around that approach here. Much of its horror was in the set dressing, but it did add in an element of disorientation and claustrophobia. I think the insanity mechanic, although rudimentary, goes a long way towards making the game more spooky. You have a sense of urgency as you're getting lost, and that, at least for me, is kind of scary. 3D Monster Maze takes a much different path, which was largely directed by the hardware it was developed for. Its horror is a little more direct. It generated fear using a timed dinosaur and general anxiety of quickly navigating a maze. The final game we looked at, Nostromo, is more of a wild card due to the provenance around the game itself.

Its frights are broadly similar to the approach used in Monster Maze, with the added element of stealth. It's like a dangerous digital hide-and-seek. One throughline here that I mentioned at the top is the whole removal-of-player-agency thing. They aren't like Space Invaders or Pac-Man. You don't usually have a way to fight back. That's most evident in the latter two, Nostromo and 3D Monster Maze, where all you can do is run, duck, hide, and escape.

Haunt is a little different in this regard. There are parts of the game where you can fight back against monsters that are after you. However, you don't just get a blaster and go to town. You get weapons like a spear gun, which can be used once to kill one underwater beast. You still have very little control over the means of protection, especially when it comes to the illness that's contorting the player's mind. For me at least, the combination of this lack of agency plus the exterior that's painted to be kind of spooky, the intention of horror plus the removal of power makes for a pretty scary experience. At the end here though, we're still left with some mysteries. I have to give a huge thanks to John Sapaniak, the author

of The Untold History of Japanese Game Developers. Without that, I wouldn't have gotten on the whole Nostromo tip at all. That said, there are still questions about Nostromo. We only know about the demo version thanks to Sapaniak's work. I think this leads to a larger question. Are there more early horror games that were never published? Are there demos hiding somewhere that have only been played by a handful of people? The answer is probably yes. It's not really a far-fetched idea to think that some horror nerds or sci-fi lovers wrote spooky games back in the 70s and early 80s. So keep your eyes peeled. Maybe one day you'll stumble on an old disc or old tape that will rewrite history. Thanks for listening to Advent of Computing. I'll be back in two weeks' time

with another piece of computing's past. And hey, if you like the show, there are now a few ways you can support it. You can rate and review on Apple Podcasts, and if you know anyone else who'd be interested in computer history, then please go ahead and share the show with them. You can also support the show directly through Advent of Computing merch or signing up as a patron on Patreon. Patrons get early access to episodes, polls for the direction of the show directly through Advent of Computing merch or signing up as a patron on Patreon. Patrons get early access to episodes, polls for the direction of the show, and some bonus episodes. I actually have a poll up for a bonus episode that's due out in November, so if you've been thinking about joining, now's a great time. You can find links to that and everything else on my website, adventofcomputing.com.

If you have any comments or suggestions for a future episode, then shoot me a tweet. I always love hearing from listeners. I'm at adrenofcomp on Twitter. And as always, have a great rest of your day.