The Trebor Chronicles

Chapter 4: You Can't Walk Through Walls

Today was mostly about infrastructure.

My Microsoft training left me permanently sensitive to two things: duplicated code and modules that grow until they become impossible to reason about. The first job, therefore, was to shrink decision_engine.py and move the logic for each game location into its own Python module.

Moose handled the refactor, and Campaign-004 was able to continue afterward.

The good news: the party made it into the maze.

The bad news: the party promptly developed a deeply questionable relationship with one particular hallway.

It would walk forward a few steps, turn, walk into a wall, reverse direction, and repeat the same basic pattern over and over. Eventually the 100-keystroke session limit was reached.

You can't walk through walls

At that point Moose tried to get the party safely out of the dungeon. The plan was sensible: use the spell DUMAPIC to determine the party’s location, then use those coordinates to find the most efficient route back out.

There was just one problem.

Nobody knew DUMAPIC.

Fortunately, Moose had a fallback. Rather than continue guessing, the party retraced its steps and successfully escaped the maze.

That left two obvious problems to solve next: spell knowledge and hallway navigation.

For spell handling, I gave Moose this prompt:

The latest.log is available to you. The first problem we need to tackle is that you tried to cast Dumapic, but nobody knows that spell. You will need to hold state on what spells each character knows. You will also need to ensure that a spell is available to the party when you are in the camp handler. Since spells can also be cast in combat, I'd like you to see how you can integrate spell-checking in both of these handlers, with minimal code duplication.

That turned into a fairly substantial piece of work.

The goal is now to keep durable state for each character’s known spells and make both Camp and Combat use the same spell-checking logic before attempting to cast anything. Moose worked through the changes, I ran the game again, and the next failure happened while trying to inspect a character’s spellbook.

That was useful, because it exposed another problem in our development process: Moose was spending too much time repeatedly opening the scanned PDF manual and converting page images into readable text.

That process is slow enough to matter.

So we changed the workflow. Moose converted the manual to text once, and I added the text version to the project. From now on, the text version can be searched directly, with the PDF used only when the OCR is ambiguous or the original page layout matters.

That should save minutes on some iterations.

We also added something I should probably have built earlier: a manual research mode.

Instead of always waiting for the automated player to reach a particular screen and fail there, I can now launch a disposable copy of the latest campaign, play Wizardry manually, and investigate the UI myself.

That immediately paid off.

I was able to explore how spellbooks work in both the Training Grounds and Camp. In both locations, the spell-reading interface behaves the same way. That let us confirm the exact screen sequence, identify the right UI markers, and avoid making the automation depend on brittle text that happens to say “Mage” or “Priest.”

More importantly, it gave Moose enough evidence to pull the spellbook logic into a single shared module instead of duplicating it in multiple handlers.

That is exactly the kind of refactoring I wanted from the beginning: observe the real game, learn the behavior, and then make the code reflect the actual structure of the system.

There was also some Git housekeeping along the way. I had logs appearing in Git that shouldn’t have been there, campaigns behaving differently from what I expected, and a bit of bouncing between GitHub Desktop, VS Code, and the GitHub website while sorting out .gitignore.

Not glamorous work, but necessary work.

The project is now in a better place than it was this morning. The decision engine is less monolithic, spell knowledge is becoming explicit state instead of wishful thinking, the manual is faster to consult, and I now have a way to manually investigate tricky game behavior without risking the real campaign.

The hallway problem still needs attention.

But at least now, when Moose walks into the wall, we have a much better system for figuring out why.