Editorial introduction · Simon Thomas
A conversation across engines, puzzles and time
When I first wrote to Scott Adams, I simply wanted to preserve — in his own words — how those early adventure
games were built, and what it felt like to create them under such tight constraints. What followed was a thoughtful,
generous exchange that became far more than technical recollection.
Working with just 16 kilobytes of memory and no floppy drives, Scott didn’t just create games — he built foundations.
He refined a single engine over decades, listened carefully to players, and embraced limitations not as obstacles,
but as creative fuel.
What moved me most was the consistency of his philosophy: programming as joy, games as passion, and a quiet refusal
to ever feel completely finished. What follows is presented as the first phase of an ongoing exchange.
When the impossible became possible
Simon
Do you remember the moment when you first realised that Adventure-style games could realistically work on home computers?
Scott
Right after I played Colossal Caves on a DEC mainframe at work. I told my colleagues that I planned to write something similar for my TRS-80 with 16k of 8-bit memory. They laughed and said it was impossible. I didn’t think so 😊
Simon
What was the biggest technical limitation you were constantly working around in those early days?
Scott
Always the memory constraint. 16k memory was it. There weren’t even floppy drives yet, so the whole game needed to work completely in the available memory space.
One engine, evolving
Simon
At the time, did you see yourself as building a reusable engine for adventures — or were the early games more bespoke?
And when you first designed that engine, did it begin as a formal plan, or did it evolve directly in code?
Scott
My initial design to combat the memory problem was to write an engine and a language from the start. I didn’t plan on writing more at first, but then I realised that it would be very easy to do future games using the same engine. Each new Adventure title let me update and tweak the engine to allow more capabilities.
It flowed organically. I designed and coded it mostly as I went. I did spend a short time outlining the format and original structure, but as soon as I began writing part of the game in it, I started adjusting the design to solve problems as they appeared.
Simon
Did the engine ever feel finished?
Was maintaining backward compatibility always important to you?
Scott
I never thought it was fully done. Even in AdventurelandXL, I was still improving the engine but kept backward compatibility with previous games.
Yes, I always wanted to have just one engine and kept things as compatible as I could.
Parsers, verbs and the shape of interaction
Simon
When you introduced a full sentence parser in Spiderman, did that represent a philosophical shift?
Did allowing many verbs encourage creativity, or did it also create ambiguity?
Scott
The engine got a major update for Spiderman. That was the first time I had a full sentence parser, and the language needed major changes to support it. It still retained the features of the earlier two-word versions.
My intent was always to make it as seamless as possible for the player, and whenever it made sense I tried to add numerous verb synonyms.
It was also about allowing fuller thought. Instead of “Get ax, throw ax, at tree”, the player could write: “Get the ax and throw it at the tree.”
Simon
Did you ever consider breaking compatibility to try something radically different?
If you were designing a fresh system today, what principle would guide it?
Scott
I did start work on a potential different engine at one point, but it never panned out. In retrospect, I sometimes think moving from “accept all verbs” to a fixed set of verbs might have been a better choice.
KISS! (Keep It Simple Stupid.) The game is not in guessing the verb — it should be in solving the puzzle 😊
Designing with players, not above them
Simon
How much of your puzzle design came from your own thinking versus watching others play?
And when puzzles emerged organically, were there times a tester’s unexpected behaviour led to something entirely new?
Scott
I can’t answer for the player’s thinking process — that’s beyond my pay grade 😉
But I did both. I tried playing the game as if it wasn’t mine, and I also watched how others played it. I got at least 20% of my ideas from watching play testers.
There were definitely times when a tester tried something unexpected and I thought, “Yes — that would be a good way to solve the problem, and I need to have it in the game!”
Simon
Who were your early play testers, and how much did that process matter?
Scott
I used many friends and family for play-testing in the early days. One of my favourite testers was Neil Novak. He would get a tall glass of water and sit down to be challenged. As he played, I would take furious notes.
If he tried something with no response, I would tell him, “The game will respond such and such in the future. Keep playing.”
Constraint, restraint and what makes adventure design work
Simon
What does strict constraint force a designer to do well?
And has your idea of what makes a good adventure changed over time?
Scott
Probably the biggest issue is that games have become more complex and time-consuming simply because technical restraints have lessened. Sometimes short and succinct is preferable.
All depends on what is fun to the end player. It should be solvable and shouldn’t require weirdness that could never be worked out. I don’t like my game #3, Mission Impossible, as it requires the player to constantly die and start over as they learn things. Totally wrong in my opinion now.
For me, the most important thing is allowing the player to have great AHA moments that are memorable. It has to be fun.
Simon
If you were starting fresh today, what early principle would you still hold onto?
And what advice would you leave for aspiring IF creators?
Scott
Player’s input is important early on. The system should be flexible for future changes.
Put the player first and not yourself. What is the fun for them — why would they want to play this game?
Passion, programming and what still lies ahead
Simon
You’ve described games as your passion and programming as your joy. Did that balance ever shift?
And was there ever a moment when you felt you had achieved exactly what you wanted these adventures to be?
Scott
The balance stayed the same. Games were my passion and programming was my joy. They fit together seamlessly — neither more important than the other.
In Escape the Gloomer and AdventurelandXL I kept extending both the storytelling and the engine. I upgraded the parser, added retro-looking graphics, and wrapped the old game in a new shell and new story layers.
Each time I finished a game, I thought it was the best I had done so far. So in reality, I have never been totally satisfied.
Simon
You’re also working on your biography. How do you see that project now?
Scott
I’ve spent the last quarter researching old emails, interviews and articles, and have started writing segments of the book. I’m seriously considering having chapters segue to web pages with mini-games that readers can complete to uncover more of the story.
Right now, though, the book and everything else is pretty much on hold. I am up to my virtual ears in AI LOL
Contact
Scott Adams welcomes contact from readers and adventure game enthusiasts.
Email:
[email protected]
Website:
www.msadams.com
These contact details are included with permission.
Closing note · Simon Thomas
Why this conversation matters
It’s easy to look back at early adventure games and focus only on their limitations — 16k memory, two-word parsers,
monochrome displays. What this exchange reminds me is that those constraints were not just barriers; they shaped an
entire way of thinking about design.
Scott’s reflections show a rare continuity — one engine evolving rather than being discarded, puzzles refined through
real human interaction, and an enduring belief that simplicity and restraint still matter.
I’m deeply grateful to Scott for taking the time to share these thoughts so openly. Preserving voices like his is exactly
why Sidon Archive exists — not only to document what was built, but to understand how and why it was built.