So far in this series, I’ve tested Adventure, which had an original to compare against but little randomness, and Gauntlet Reforged, which had plenty of randomness but no original. This time I get both problems at once. Lucky me.

“Another visitor. Stay a while … stay forever!”

If you owned a Commodore 64 in 1984, not only were you immensely cool (at least in your own eyes), but you heard that above line in a slightly crackly digitized voice. That’s Professor Elvin Atombender welcoming you to Impossible Mission, published by Epyx. You play Agent 4125, and you have six hours to infiltrate Elvin’s underground stronghold before he launches a strike that ends the world.

Elvin, by the way, wasn’t always like this. According to the game’s lore, his mind was warped by a freak accident with a video game. I can totally relate.

The stronghold is a tower of rooms connected by elevators and corridors. Each room is a set of platforms and lifts, patrolled by robots, some of which zap you and some of which just get in your way. Hidden in the furniture are 36 pieces of nine punch cards. You search the furniture, collect the pieces, then assemble them in your pocket computer. Each finished card gives you one letter of a password, and the full password opens the door to Elvin’s control room. Along the way, you do some of the most graceful somersaults ever rendered in 1984, and you fall to your death a great deal. Each death costs you ten minutes off the clock.

If you play the game, though, ask yourself this: whare are you falling to? I mean, the floors all stack atop each other, right? Well, whatever. Who am I to question 1980s game logic?

I built a browser version called Improbable Mission. The name reflected the likelihood of my actually pulling it off. It’s open sourced and it’s playable online, written in TypeScript, and it’s by far the most complex of the three games in this series.

I put in a little initial title screen and a Star Wars style crawler, which are unique to my version. I don’t know why I did that. Well, whatever. Who am I to question my own logic?

Let’s talk about testing it.

Purpose and Audience

The biggest testing problem with this game is that almost nobody reaches the end of it. The original is famously hard. I would be willing to bet most people who played it in 1984 never saw Elvin’s door open. That means the endgame is the least exercised part of any implementation: assembling all nine punch cards, entering the password and opening the door. Think about that from a testing angle. The part of the game that matters most, because it’s the point of the whole thing, is the part that gets tested least, because it’s the hardest to reach.

That’s not a game problem. That’s a software problem. Every application has a “hard to reach” part: the year-end batch job, the rare error path, the workflow only three customers use. Those are exactly the places where bugs live longest.

So, as I put all this together, my strategy aimed to cover the end of the game as well as the beginning. As with the previous two games in this series, the overall strategy serves two kinds of tester.

• Testers who explore by playing. You have the live game, the dossier (acting as a game manual), perhaps the original in an emulator. You’re using the keyboard, cheat codes, the map flag, notes and screen recordings.
• Testers who explore the code. Testers who can read TypeScript can look at the source, the ported data tables, the original disassembly and the test suite, with code review, unit and parity tests, and scripted play in a browser.

The cheat codes and the map flag matter more here than in most games, which is why I spent a lot of time putting them in place. They let a tester reach late-game states in minutes instead of hours, without needing the skill to get there. A tester who can’t survive room 3 can still test the endgame.

Notice something though: if a tester can’t get there by skill, could that be because the game is too hard for people? That’s a quality judgement. When I talked about the AI orchestrator that I wrote for FromSoftware for testing Elden Ring, I showed how automation could determine the game was “fair.” It would just require human players to have preternatural response times and God-tier reflexes.

What Correct Means

We’re back in Adventure territory here. The 1984 Commodore 64 original of Impossible Mission is the specification. When my version and the original disagree, the default verdict is that mine has a bug, unless the difference is documented as deliberate. I have some sources that settle questions, in order of authority.

1. The original running in the VICE emulator. The repository holds disk and tape images of the original. Play the same situation side by side and compare. This is the main oracle for testers.
2. The disassembly and ported tables. The repository holds a disassembly of the original. The data in the layout tables is the original’s data, and a parity test checks it against the original’s tables whenever a copy is present.
3. The original manual and the in-game dossier. They describe intended play, but not edge cases.
4. Documented deviations. The project docs record where this version knowingly differs. For example, puzzle piece shapes are fixed rather than cut fresh each game. A tester who finds one of these shouldn’t report it as a bug.
5. Other remakes, as weak evidence only. A 2013 browser remake and a Defold tribute were references during development. My project notes record bugs in the first, so agreement with either proves little.

That last point is worth dwelling on for a second. When there are several versions of something, it’s tempting to treat agreement between them as evidence. But if they all copied each other, or all made the same reasonable-looking assumption, agreement just means the same mistake was made twice.

Case in point: the Impossible Mission: Revisited (or Remastered) on Steam is garbage. Filled with bugs. Using that as any sort of reference implementation would be a big mistake.

The browser itself forces some deviations. The keyboard replaces the joystick, the toolbar adds palettes and pause, and the cheat codes and map flag exist only in my version and only for testing.

Risk Areas

The highest risk is a game that can’t be finished, because few testers would ever get far enough to notice. Hold that thought, because it turns out to be the main story of this post.

Rank	Risk	Why it is risky here	Tracks
1	Completability	Every one of the 36 pieces must be reachable, every card solvable, and the door must open with the full password, on all 11 layouts	Both
2	Real-time timers in game logic	The game’s clock runs on a fixed frame loop, but the intro handoff, phone calls and terminal messages use real-time timers that keep running while paused	Both
3	Platforming and lifts	Jumps, falls and lifts decide which furniture can be reached, and lifts can strand the player	Both
4	Robots and the orb	Twelve robot behaviors, randomly assigned, plus an orb that pursues	Both
5	The puzzle desktop	Pieces must be dragged, flipped, recolored and stacked through a pointer interface, with undo, trash and phone calls	Human
6	Randomness	Layout, item placement, robot types, piece colors and flips all roll at random	Technical
7	Time and scoring	Deaths cost ten minutes, calls cost two, and the final score combines five components	Both
8	Untested pull requests	The deploy workflow runs the unit tests, but only after a merge to main	Technical

Test Layers and Testability

As I wrote this, I realized that my existing automated test suite was strong on data and weak on play. It checks the tables, the map connections and the assets thoroughly. Until the agent work described below, though, nothing drove the game through a room, a search or a puzzle.

Layer	What it checks	Status	Track
Unit and data tests	Room connections, map traversal, layout integrity, sprite regions, palettes, public assets	In place, runs before every deploy	Technical
Parity with the original	Every ported table against the original’s	In place, skips itself without a copy of the original	Technical
Canvas snapshots	Four scenes rendered pixel for pixel	In place, local only	Technical
Scripted play	A seeded game stepped frame by frame with scripted input, checking positions, searches and the clock	In place, through the agent’s harness	Technical
Completion agents	An agent that finishes the game, in the tiers described below	First two tiers done	Technical
Exploratory sessions	Time-boxed play against a charter	Ongoing	Human

The following seams already exist based on how I developed the project:

• The map flag forces one of the 11 layouts.
• Cheat codes switch off death, falling and the clock, and reveal the whole map. They can be set in the URL.
• One random helper. Every random roll goes through one function on top of the browser’s generator, so a seeded generator makes runs replayable.
• Module access in development. The dev server serves the source as modules, so a test page can import the same game objects the running game uses.

Two things stood in the way of frame-exact scripted play. Game logic runs on a 27 millisecond timer rather than a loop that a test can step, and several transitions use real-time timers. As you’ll see, the agent’s harness ended up dealing with both.

Heuristics for Exploratory Play

The following heuristics need no code. You can use the cheat codes to get past the parts you aren’t testing, but turn them off for anything that depends on what they disable. (Testing the death timing penalty with invincibility on is a short, not to mention meaningless, session!)

As with previous posts, you might want to play around with the game a little bit yourself and build your own picture of how you would test it.

Moving and Dying

• Die every way there is. Get zapped, touch the orb, fall into a pit. Check that each costs exactly ten minutes and that the room resets the way the original does.
• Strand yourself. Ride lifts until you can’t get back, then recover with a lift init, and separately by dying. Compare which is cheaper.
• Jump at the edges. Somersault off platform ends, into walls, over robots and onto lifts in motion.
• Hold keys across every doorway. Keep a direction held while walking from a corridor into a room, a room into an elevator, and an elevator into a room.

Searching

• Get interrupted mid-search. Step away, get zapped or jump partway through the search bar, then search again. Check whether progress is kept or lost.
• Search everything in one room. Count the results against what the room should hold, including furniture that is hard to reach.

Terminals, Snoozes and Lifts

• Snooze, then leave. A snooze ends when you leave the room. Re-enter and check the robots are awake.
• Spend with nothing banked. Use a terminal with no snoozes or lift inits and check the response.
• Play the organ to the limit. The tone sequence grows by one note per success, up to fourteen. Check that it stops growing and that the rewards keep coming.

The Pocket Computer

• Stack wrong pieces. Merge pieces from different cards, then undo. Trash merged stacks. The bin only removes desktop copies, so no piece should ever be lost.
• Pause during a phone call. Calls run on real time. Pause partway through and see whether the call still completes and still costs two minutes.
• Call with an empty memory. Use both phone services with nothing in memory and with only one piece.

Time and the Ending

• Run the clock down. Let time expire in a room, in an elevator and in the pocket computer, and watch the game over sequence.
• Finish with seconds to spare. Open Elvin’s door just before the clock runs out and check the score adds up from its five parts.
• Use a cheat, then win. A cheated game should show its score but never enter the hall of fame.

Something to notice here is the sheer regression surface that is possible with this game. It is demonstrably more complicated in its state than either Adventure (which was brain-dead simple) or Gauntlet (which was minimal).

Heuristics for Reading the Code

The following heuristics are for testers who read the TypeScript. As with Gauntlet Reforged, applying these heuristics produced real results. The first one below came from the agent; the rest came from reading. The last three are worries that turned out to be safe, which I think is worth including. A heuristic that tells you where you don’t have a problem is still doing its job.

That last point is important. Testing is not just to find risks. It can also tell you where you lack risk. Or, put another way, contrary to some pundits out there, testing is not just to find bugs in specific conditions. Finding the absence of bugs in specific conditions is a finding in its own right.

Result	Where	What it means	Heuristic
Fixed: room 24’s top floor could not be reached	Room 24, found by the agent’s survey	Covered in the case study below. Nine of the first twelve seeds hid a piece there, making those games unwinnable	Prove every item can be reached
Room transitions advance in the drawing loop	The game’s animation update	Entering and leaving rooms completes at the browser’s drawing rate, against the project’s own rule that the drawing loop owns only looks	Put code in the right loop
Drawing rolls dice	The robot zap beam’s flicker	Random draws made while drawing shift every later roll, so seeded runs depend on the frame rate	Count every draw
Stacking compares images that load asynchronously	Piece images and the merge check	A merge tried before a flipped or recolored piece’s image has loaded compares against an empty image and is refused	Separate game time from real time
Real-time timers keep running while paused	The intro handoff, the phone’s two services, terminal messages	A phone call placed and then paused still completes and still charges two minutes	Separate game time from real time
Shaft limits in the layout data are never read	Each map’s elevator table	Every elevator can travel the whole tower. Worth comparing with the original’s shaft lengths	Check that every table is used
Picking a piece up off the desktop copies it	The pocket computer	The original copy stays in its slot after the piece is stacked elsewhere	Compare every interaction with the original
Safe for now: no card can be finished with another card’s pieces	The solved check	It never verifies which card a piece belongs to, but an exhaustive check found no mixed stack that fits the fixed piece shapes. Cutting shapes fresh each game would expose it	Check every rule against the data it relies on
Safe: trashing a piece cannot lose it	The pocket computer’s bin	The desktop holds copies. Originals leave memory only when their whole card is solved	Look for any action that destroys progress
Safe: items are placed only in rooms 1 to 30	Item placement	Rooms 0, 5 and 31 have no furniture, so nothing can be placed where it could not be found	Check the range math on every random call

Notice that “count every draw” and “check the range math” show up again! That’s three games and the same two randomness heuristics earning their place every time. If you only take two heuristics away from this series, take those.

Time

• Put code in the right loop. The project README warns about this itself: anything paced by the drawing loop runs at a speed that depends on the machine. Game rules belong in the scan loop.
• Separate game time from real time. Every real-time timer in game logic is a place where pausing, a slow machine or a background tab can change the outcome.

Randomness

• Respect the one-based roll. The random helper returns 1 to n, like the original’s BASIC. Any index built from it needs one subtracted.
• Count every draw. A seeded replay only repeats if every roll happens in the same order. A roll made inside a timer or a sound handler can shift all the rolls after it.

Completability

• Prove every item can be reached. For each layout, check that every furniture item can be reached from the room’s entrances with the platforms, lifts and jumps available, without cheats.
• Look for any action that destroys progress. Trashing, undoing, dying, leaving a room and resetting lifts should never lose a piece or a solved card.
• Compare every cost with the original. Death, phone calls and the end-of-game score each have a number the original defines.

Sample Charters

Here charters are the same form as before with the previous two games in this series: explore a target, with some resources, to discover some information. (That right there is the fundamental description of testing!) Time boxes are suggestions.

Charter	Track	Time box
Explore the endgame on one layout with all cheats on, to discover anything that stops the password or the door	Human	60 min
Explore every room of one layout with airwalk off and invincibility on, to discover furniture that can’t be reached	Human	90 min
Explore the lifts in rooms with several lift groups, to discover states the player cannot recover from without dying	Human	45 min
Explore the puzzle desktop with wrong merges, undo and the bin, to discover any lost piece or card	Human	45 min
Explore pausing during calls, terminal messages and the intro, to discover outcomes that change with real time	Both	30 min
Explore the same robot rooms here and in the original, to discover differences in speed, zaps and turns	Both	60 min
Explore every real-time timer in the source, to discover game rules that depend on the wall clock	Technical	45 min
Explore the layout tables with a reachability script, to discover unreachable furniture on any of the 11 layouts	Technical	120 min

I would encourage a test explorer, at the end of a session, to write down what was covered, what was found and what’s still unexplored. The unexplored list becomes the next charter.

Can the Game Even Be Completed?

With Adventure Uncartridged and Gauntlet Reforged, the AI question was whether an agent could win a level. Here, the honest question is harder: can anything, human or agent, finish this game at all? And if not, is that the game’s fault or the player’s?

You might think: “Well, the game sold at one point. So obviously it could be completed.” Yeah, well, fun fact: lots of games shipped with bugs that precluded completion. Including this one! In the American NTSC port of the original game, a programming mistake placed vital puzzle cards inside computer terminals that turned out to be completely unsearchable, making it impossible to assemble the code and stop Elvin.

The trick is to separate two questions: whether the game can be finished at all, and whether it can be finished by playing well. The cheat codes make that separation possible, because each one removes exactly one kind of difficulty. Invincibility removes the robots and the orb as a threat. A frozen clock removes the time limit. So I set up the work as tiers, each one adding back a difficulty the previous one removed.

Tier	Cheats on	What the agent must handle	What a win proves	Status
0. Reachability survey	Invincibility, frozen clock	Every room entered from every door, every move sequence explored	No furniture is out of reach	Done: all reachable after the fix
1. Logic completion	Invincibility, frozen clock	Elevators, corridors, jumps, falls, lifts, searching, the puzzle desktop and the door	The whole chain from search to password to door works on a layout	Done on all 11 layouts
2. Clock completion	Invincibility	The same, inside the six-hour clock, with phone calls costing time	A win fits in the time allowed	Not started
3. Full completion	None	Robots, the orb, snoozes, deaths and the clock	A skilled player can win	Not started

Tier 2 adds a budget: phone calls cost two minutes, and the route through 26 or more rooms has to fit in six hours. Tier 3 adds opponents: twelve robot behaviors and the orb have to be predicted or avoided, snoozes are scarce, and each death costs ten minutes, which is one thirty-sixth of the whole mission.

You might wonder why the third cheat, airwalk, isn’t on in any tier. Airwalk stops all falling, which sounds like it would make things easier. It doesn’t. The rooms rely on dropping from ledges to lower platforms, so with airwalk on, some furniture becomes unreachable that normal play can reach. A cheat meant to remove difficulty would have added a false one. That’s a good reminder that a test aid can change the very thing you’re testing.

The Harness

This game needed the hardest harness of the three. Adventure had little randomness. Gauntlet Reforged had randomness and one game loop. This game has randomness, two loops, several real-time timers, and images that load in the background. Every one of those had to be brought under control before a run could be repeated. As with Gauntlet Reforged, the harness is injected into the page before the game loads, and it changes nothing in the game’s code:

Problem	What the harness does
Random rolls	Replaces the browser’s random source with a seeded generator whose state can be saved and restored
Game logic runs on a 27 millisecond timer	Captures the timer and advances the game one scan frame at a time
Room transitions advance in the drawing loop	Captures that loop too, and calls the game’s animation update during transitions
Drawing rolls dice (the robot zap flicker)	Restores the random state after every animation update
The intro, phone and terminal use real-time timers	Runs those timers on a virtual clock that moves 27 milliseconds per frame
Piece images load asynchronously	Waits for every piece image to load while the pocket computer is open

If you compare that table with the code findings above, you’ll see they line up. Almost every row in this table is a workaround for one of those findings.

I think that’s the clearest demonstration in this whole series that testability problems and bugs are often the same thing seen from two sides.

The Engine Is the Model

With Adventure, the agent planned with a separate model of the player’s movement, and I checked that model against the game before trusting it. That worked because Adventure‘s movement is simple: move six units, check for walls. Agent 4125 is a different story. Running, somersaulting, falling, landing on a moving lift: writing a separate model of all that would be a project in itself. And even then, I would now have to test the model too!

So, this agent doesn’t have a separate model. It plans with the real game. To move inside a room, it takes a snapshot of the room, tries a move by actually stepping the game, sees where Agent 4125 ends up, and then restores the snapshot. The moves are a walk, a running or standing jump, or a lift ride. It searches outward breadth first until it reaches its goal, which is usually a piece of furniture. Between rooms, it routes through the elevator shafts and corridors with a shortest-path search.

The advantage is that the agent can never disagree with the game about physics, because the game is its physics. The cost, as you’ll see in the case study, is that the snapshot has to capture everything. If it misses anything, one planning branch leaks into the next.

Once all 36 pieces are collected, the agent opens the pocket computer and assembles the nine cards through the game’s real controls, moving pieces and clicking buttons just as a player would. Then it walks to Elvin’s door.

It’s worth noting that the agent reads the game’s state, so it knows which furniture holds each piece. That’s fine for proving the game can be finished. It would not be fine for proving the game can be finished within the time limit by someone who has to search all 127 furniture items. That’s one of the reasons Tier 2 is a separate tier.

The Result

The agent won all 11 layouts, with two different seeds each, for 22 wins. Each one spelled that layout’s password and opened Elvin’s door, in 26,000 to 32,500 scan frames, which is 12 to 15 minutes of game time. Every recording replays in a fresh game and reaches the door on the same frame.

Here’s a video of seed 1 on map 0, filmed by the agent from the real game. This one couldn’t be won at all before the fix that I will describe further down. That’s a 12 minute video so you have to decide how much you want to watch of it. I should note that there’s no sound and that’s because I found the sound effects distracted the agent something terrible.

Even an initial watch should show you some interesting things about the agent and how it was operating. Watch at least up to about the two minute mark and you’ll see most of the agent’s quirks. If you want to see an interesting aspect to how it learned what to do, skip to around the 8:38 mark where it’s attempting one of the puzzle configurations. At the 12:10 mark, notice how it had not explored some rooms at all.

I suppose someone could argue that a single win could be a lucky draw of the seed. Plausible, I suppose. So if you want to see that it isn’t, here’s a run with seed 4. The pieces are hidden in different places, so the agent takes a completely different route through the tower, and it still ends at the same door.

Is that the same as proving a human can win it? No. That’s what Tiers 2 and 3 are for. What it does prove is that the endgame, the part that’s difficult to reach by hand, works: every piece can be found, every card can be assembled, and the door opens. And getting there turned up the most important bug in the project.

Case Study: The Unreachable Top Floor

Before the agent tried to win anything, it ran a survey. Tier 0 enters every room from every door and explores every sequence of moves it can, looking for furniture it can’t reach. On the first run, the survey reported that room 24’s top floor couldn’t be reached from anywhere. The fireplace and the chair with the lamp up there were out of reach.

That would be a curiosity if nothing important was ever up there. But pieces are hidden at random, and when I checked the first twelve seeds, nine of them hid a piece on that floor. On every layout. Yikes. That means most games of my version could never be won, and it would be possible for nobody to notice, because nobody might get far enough into the game to notice.

This is precisely the risk I ranked first. And it’s exactly the kind of bug a human tester might never find. You would have to collect 35 pieces, realize you were missing one, work out where it must be, and then fail to reach it enough times to decide it was the game and not you. Given how this game treats players, “it’s me” is always the more reasonable assumption. But, in this case, “No, game. It’s you. Not me.”

Agent Bug or Game Bug?

When an agent says something is impossible, the first question is whether the agent is just bad at it. Remember the heuristic from Adventure: don’t read a failure as evidence. So I looked at what was actually happening.

The only way up to room 24’s second floor is a jump from a lift onto a ledge. When the agent made that jump, it landed with only a couple of pixels of Agent 4125’s foot on the ledge. And my version’s landing rule said that wasn’t enough:

So the agent fell, every time, from every lift. The agent wasn’t playing badly. Its jumps were the best jumps available, and my game said they missed.

But was my game wrong? My rule looked reasonable. You could easily argue that a figure balanced on two pixels of toe should fall. This is where having the original as the oracle earns its keep. I didn’t have to argue with myself about what seemed reasonable. I went to VICE, set up the same jump in the original, and Agent 4125 landed on the ledge and stayed there.

The original wins, so the rule changed. Now Agent 4125 stays up while any foot pixel rests on something solid:

After the fix, the survey found every furniture item reachable from at least one door. Seed 1 on map 0, the seed in the video above, had been unwinnable. It now reaches room 24’s top floor and opens Elvin’s door.

The Instrument Had a Bug Too

Here’s a part I want to include because it would be easy to leave out. Right after the fix, the agent reported a new problem: it couldn’t leave room 27. That was alarming. Had the fix broken something else?

It hadn’t. The bug was in the agent. Remember that the agent plans by taking snapshots of the game and restoring them. When Agent 4125 starts to fall, the game rewrites the first frame of the falling animation with whatever pose the fall started from. That pose lives in a nested part of the game state that the snapshot only pointed to rather than copied. So a fall in one planning branch leaked into the next, and the planner started seeing ghosts.

See the position the agent is in with his foot? That’s just like the one from the previous image that I now got working! The agent didn’t fall, he managed to hang on by his toes. (Actually, his one toe. Good job, Agent 4125!)

What I honestly can’t tell you yet is why the leak only showed up after the fix. On the one hand, the end result is that the agent thought this pose should have been falling but it clearly wasn’t now (due to the fix). So the agent just got stuck. On the other hand, the snapshot had been missing those poses all along, and the agent had been planning with it through the whole survey without producing a false report. At least not that I noticed. My best guess is that the fix changed which landings hold, so the planner tried falls it had never tried before, and one of them exposed the leak. But that’s a guess, and I’m still investigating it.

As a tester, I would rather tell you that than give you a tidy explanation I haven’t verified. A cause you’ve assumed is often a bug you haven’t found yet.

Once the snapshot saved those poses too, room 27 was fine, and the 22 wins followed, two of which you could see in the videos.

I think this is the most important lesson in the post, and it echoes the “test the instrument first” idea from Adventure. Your test tools are software. They have bugs. When a test tool reports something surprising, the tool is a suspect, not a witness. In this case, the same agent gave me one true report and one false one, back to back, and the only way to tell them apart was to investigate both.

We humans still serve a role apparently. Yay!

Why Did It Survive?

As with the Adventure freeze, the operative question is why this bug survived. The answer is that none of the existing tests played the game. They checked tables, connections and assets, and all of those were correct. The bug was in how two correct things, a lift’s height and the landing rule, combined in one room. Only something that actually tried to get up there could find it.

A human tester running the second sample charter could have found it too, but only by being stubborn about one ledge in one room for a long time.

Heuristics for Judging Agent Results

All three games taught me something about trusting agents. This one added the most.

• Separate “can it be done” from “can it be done well.” Cheats that each remove one kind of difficulty let you answer those questions one at a time.
• Check that a test aid doesn’t change what you’re testing. Airwalk looked like it made the game easier, and it actually made some of it impossible.
• An impossible result is a lead, not a verdict. Look at what the agent tried before deciding whether the agent or the game is at fault.
• Let the oracle settle disputes. When the agent and the game disagreed about a landing, neither of them was the authority. The original was.
• Treat the instrument as a suspect. A planner with a leaky snapshot reports problems that aren’t there. Investigate surprising reports from your tools as carefully as surprising behavior from the game.
• Keep the seed and layout with the recording. The same frames on a different seed play a different game.

And one last rule, which applies to all three of these games: if the original behaves the same way, it’s not a bug in my version. You could certainly record it as a quirk of the original. Elvin’s stronghold has plenty of those, and I worked hard to keep every one of them for that authentic retro experience.

What’s Next?

Well, the 1980s were big on lasers. The 1970s introduced the technology to the public, but the 1980s exploded with mass-market consumer saturation. So, in the next post, we’re going to test with lasers.