Strange Leaflet

Making Zork an (almost) pure puzzle game

2026-11-07T17:34:50+00:00

I've always loved ZORK but parts of it have always kind of grated on me in that it isn't purely a cerebral puzzle game but depends on some luck and essentially requires you to save/restore your way through the game.

ZORK I: The Great Underground Empire
Infocom interactive fiction - a fantasy story
Copyright (c) 1981, 1982, 1983, 1984, 1985, 1986 Infocom, Inc. All rights reserved.
ZORK is a registered trademark of Infocom, Inc.
Release 0 / Serial number 261104

West of House
You are standing in an open field west of a white house, with a boarded front door.
There is a small mailbox here.

>

The start of Zork I in the curio's Atari 800 screen. Play it there.

What to do about it? I thought it would mean having to compile a custom version of the game. But it turnss out to be possible to keep the z-machine game completely as-is and have the z-machine interpreter optionally manipulate how the game plays.

So Claude and I did. I've got an in-browser z-machine interpreter over on the cabinet of curios.

Cheats

For ZORK you can set a few options:

Thief stays home: ensure the thief stays in his treasure room instead of randomly wandering around the map.
Stable objects: ensure that items remain where you dropped them instead of randomly teleporting around the map.
Endless lights: ensure that none of the light sources can run out.
Well lit: ignore darkness completely.

Those last two are absolutely cheats, but I think the first two really nicely fit with the game. Or with my idea of the game.

Having the thief stay in the treasure room turns him into a puzzle instead of a potentially game ending random encounter.

When you have enough of a score you can find his treasure room and find him there guarding the chalice (and any stolen treasures if you made him stay home after he's stolen things from you). You can still have him open the egg if you realize that's possible (uh spoilers).

There is still an element of randomness in the combat. But the point is that you can face the thief on your terms with intent by thinking about it instead of saving and reloading frequently.

The stable objects also mean you can actually map out the mazes directly instead of having to get lucky and hope that the game keeps the items stable while you're mapping.

Enhanced

And there's more! I have an option to turn on "Enhanced" Zork which gives you a few things that feel like you should have as the player character.

Know how much of a burden you're carrying instead of getting surprised when your character can't pick something up.
See your health directly instead of having to type diagnose.
See the power level of the lamp. It's battery powered after all.
Keep track of your treasure count.
Have an indicator to know if the room you're in is naturally lit or not. This one always really bugged me because your character should just see that instead of making you turn off the lamp to find out.

Tools

There's also an inspector view to see the current game state and object list. Kind of like a web browser inspector for the z-machine.

An automatically generating map if you want to use it.

A built-in notes editor.

The saves also use the Quetzal formatting standard so you can save/load from other interpreters.

AND the built-in notes and map are included in the save files as you and you can choose if you want to reload them from the save.

There's a few themes to pick from as well including an Atari 800 theme that's pretty close to how I remember playing in the 80s. Although I still need to make some more tweaks.

I'm having a blast re-discovering the games and making them more of the pure puzzle experience I always wanted.

The Last Starfighter's arcade game was ahead of its time

2026-11-06T04:03:44+00:00

Let's talk about one of my favorite movies, The Last Starfighter. A fun movie from 1984 telling the tale of a trailer park kid who was so talented at a videogame that he was tapped to fight fascism in space using the same arcade controls to fly a supremely powerful spaceship. One gunstar vs the entire armada. Spoilers: they win!

Even that quick synopsis already points to some interestingly forward-thinking ideas like the rise of competitive e-sports. But I want to focus in on a different aspect of the movie: the arcade game itself.

Check out this clip of the in-movie "Starfighter" arcade game starting up.

Clip from The Last Starfighter (1984, Lorimar/Universal).

In a few seconds we have several motifs that didn't even exist in videogames yet:

a camera that moves through a 3D scene
zooming in from a third-person overview to a first-person in-game perspective
a HUD showing a complete interface to various ship systems and orientation in 3D space

The movie didn't invent all of this from nothing. There were already games putting players in a cockpit in 3D space. Star Raiders, from 1979 on Atari's home computers, had a crosshair, a row of ship readouts along the bottom (velocity, kills, energy, and the target's bearing and range), and an attack computer display in the corner that tracks the enemy you're aiming at.

Clip from Star Raiders (1979, Atari), from Old Classic Retro Gaming's playthrough.

But no actual arcade or videogame was anywhere close to what they dreamed up as the Starfighter arcade game.

In 1980 Atari brought first-person 3D to arcades with Battlezone. You drive a tank across a green wireframe battlefield with a gunsight in the middle of the screen, and a radar at the top sweeps around to show enemies on every side of you.

Clip from Battlezone (1980, Atari), from Shane McComas's video.

Here's Gyruss, a Konami game from 1983 that was in arcades while the movie was being made.

Clip from Gyruss (1983, Konami), from Old Classic Retro Gaming's playthrough.

All great games. Iconic, classic, very 1980s arcade. But nothing like what the movie's game was showing.

For 3D space games at the time the state of the art was Atari's Star Wars, also from 1983. It has real 3D ships and a cockpit view, but the ships are wireframe outlines, the camera is fixed to the cockpit, and the HUD is a shield gauge and a score. Nothing close to the cinematic design of the movie's Starfighter game.

Clip from Star Wars (1983, Atari), from AL82 Retrogaming Longplays' longplay.

Now let's zoom in on the Starfighter HUD.

Still from The Last Starfighter (1984, Lorimar/Universal).

Just look at the artistic beauty of that imagined videogame UI! Sure some games had some of those ideas already like a targeting reticle, power levels. But no actual game had put them all together so elegantly and also added 3D space specific visualizations like the ship model and 3D radar view. That's a lot of complexity to keep up with and it still reads intuitively like a game that you could actually play.

Speaking of actually playing, credit to Lance Guest for really conveying the sense that he's actually playing a game that couldn't have existed. In even more recent movies and tv shows we're all too familiar with the "act like you're playing a videogame" trope that's just mashing buttons and wildly flipping the joystick. In The Last Starfighter the character Alex is playing with careful intent that's completely convincing.

How did they do it? Well from a technical level of course the Starfighter game never had to actually run on arcade hardware. The movie's effects were made by Digital Productions, the company John Whitney Jr. and Gary Demos founded, on a Cray X-MP supercomputer. That was around 25 minutes of computer graphics across nearly 300 shots. An actual arcade game has to draw a new frame many times a second, live. The movie's "game" could take as long as it needed on each frame, so it could show what a game would look like once the hardware caught up.

From a design standpoint I have no idea! I've searched for any kind of explanation and haven't found anything that goes into detail about the making of the movie arcade game concept itself.

So was the movie predicting where videogames were going, or showing them the way? I'd guess predicting, because I've never heard any game developer call out The Last Starfighter as a direct inspiration.

The Last Starfighter holds up when compared to other arcade movies of the time as well. TRON of course had Flynn's arcade showcasing the in-movie game Space Paranoids. But Space Paranoids is more like an enhanced version of Battlezone than an arcade game way ahead of its time.

Clip from TRON (1982, Walt Disney Productions), from Iamthe80sguy2's upload.

Every time I watch The Last Starfighter I'm impressed. The filmmakers clearly loved arcade games and managed to dream one up that would still hold up as a game today.

We take it back

2026-11-04T14:08:45+00:00

Wow I'd hoped for good results from election day (November 3, 2026: yesterday) but these results are amazing. This clip has been running in my head:

Clip from Robin Hood: Prince of Thieves (1991, Morgan Creek/Warner Bros.).

My mesh WiFi died, so I'm running fiber to the attic

2026-10-26T17:47:13+00:00

On Saturday morning, October 24th, we all woke up to no Internet. Well almost entirely no Internet. Two of our Plume SuperPods were offline, one was going on and off randomly. Restarting the pods didn't help at all. They'd worked for years with no changes but I guess with Plume's residential support shutting down this was finally the impetus to change our network.

A laptop plugged straight into the AT&T fiber gateway got online just fine. The ISP connection was working.
A device wired into the main Plume pod, the one connected to the gateway via ethernet, got nothing at all.

Maybe there was a power surge or maybe a bad firmware update overnight. Either way let's change it up!

The new plan

Our house is three stories with my office in the attic. Originally the Plume network was great to cover WiFi because AT&T's gateway was really slow and didn't provide a strong signal. But since then we've upgraded to the BGW320 gateway. So hey maybe the gateway's own WiFi can handle things.

Turns out it works great! I setup its internal WiFi to match the Plume network SSID and password and all of our devices could just hop right back on without the lag or dead spots we had before.

So great! The plan now is the gateway's WiFi for the house, and a new wired link to the attic.

I've thought for a while about having a fiber run instead of two ethernet runs with a Plume superpod intermediary. So this is a great time to try that out and setup a 10G fiber link.

AT&T fiber
    |
BGW320-500 gateway  (WiFi for the house)
    |  ethernet
ES210X-M2 switch
    |  10G single-mode fiber
ES210X-M2 switch  (attic office)
    |  ethernet
all the wired things in my office

The parts:

Two TP-Link Omada ES210X-M2 switches. Each has eight 2.5G ports and two 10G SFP+ slots. One goes beside the gateway, and the other replaces a 6-port switch in the attic office.
Two TP-Link SM5110-LR modules: 10GBASE-LR, single-mode. One for each switch's SFP+ slot.
A run of OS2 single-mode armored fiber cable, LC to LC (UPC), uniboot. Uniboot means both strands of the pair share one connector boot, so it's a single thin cable end to end.

The run from the gateway to the attic goes through a surface raceway I setup for the Plume ethernet backhaul. Now it'll carry a single fiber run directly from the gateway to the office switch.

Why fiber?

Capacity and coolness! A fiber run should be plenty futureproofed for future speed and it's just cool to have data via light.

An ethernet coupler for now

Until the fiber is in, the attic still needs a wired connection. The old Plume pod on the second floor used to sit between the two ethernet cables, so I joined them with an RJ45 coupler right where it used to be. One continuous-ish cable to the office.

Back to a static site

2026-10-25T16:12:23+00:00

A year ago I switched to Bear and I still think Bear is great. If you want to simply write words and have them show up on the Internet, go use Bear. It's fast, it's human, it's delightful, and it gets out of your way.

But recently I've been building the Cabinet of Curios and working on FurtherFrom with Claude. Working on both sites has reminded me how nice it is to have a site that's just files. Way back in the early 1990s I hand edited HTML files as my blog originally hosted from the user hosting account of our ISP, Interpath. Back when publishing was ftp.

I'm getting that same kind of vibe with GitHub Pages which I'd always kind of relegated to either Jekyll things or simple single page HTML. With Claude I've found that it's really quite nice to get back to self-contained HTML files. Push some HTML to GitHub, GitHub Pages serves it, done. And the more curios I made with Claude the more I missed being able to drop interactive things right into blog posts like I could back when this blog was running in SvelteKit.

Bear is very intentionally not that. No JavaScript, just words. That's a feature! But it's just not the feature I want anymore.

Strange Leaflet is a static site again!

So let's walk through some blogging history as best I can remember it. My blogging has changed domains and hosting and frameworks several times.

1990s: something like interpath.com/~ballfam because no one else really cared to put files into our user account. This was purely handwritten HTML files wow.
1990s: At UNC we also got a user hosted space so it was something like web.unc.edu/~sdball?
2000s: I ran a livejournal for some time
2000s: There was an iBlog in there too which was a macOS app to compile posts into static HTML
2010s: I spun up a Ruby/Rails blog at rakeroutes.com which was variously a mephisto blog, jekyll, comfortable mexican sofa, WordPress, and ghost blog
2020s: I started up strangeleaflet and it's been jekyll, blot.im, SvelteKit, Phoenix, and bearblog.

And now back to plain HTML files but now with a light build script and help from Claude which is turning out to be super fun. Going from idea to self-contained HTML file is a great flow and we've been able to extract out my old SvelteKit widgets back into self-contained JavaScript within the posts. Woo!

What I gave up

A web UI to write and edit posts. Posts are markdown files in a git repo again.
Bear's upvotes ("toasts"), visibility toggles, and analytics.
An RSS feed that I never had to think about.

What I got

Every post is its own HTML page that Claude and I fully control. Here's the walking penguin from my SvelteKit reboot post, back from being a screenshot on Bear:

The bitfields post has its interactive explorers back too.

Those used to be Svelte components. Now they're plain JavaScript custom elements that live in the same directory as their post. No framework, no bundler. Each one wraps the static version that was on Bear (a screenshot, some code blocks) so feed readers and anyone without JavaScript still see something sensible.

A custom generator, written by Claude

I've been down the static site generator road before. I don't want to learn another generator's opinions about templates and themes and plugins. I wanted exactly one thing: take the markdown that Bear exported and turn it into the same HTML Bear was making, so my theme just keeps working.

So I asked Claude (Claude Code, specifically) whether that was feasible. It looked at the export, my Bear theme, and my other static sites, said yes, and then built it with me.

The whole generator is one Python file of about 370 lines using mistune for markdown and Pygments for syntax highlighting. It makes:

a page for every post, at the same URLs Bear used
the home page and the blog list, including Bear's ?q=tag filtering
an Atom feed at the same /feed/ URL with the same entry ids, so existing subscribers shouldn't notice a thing
redirects for old URLs from earlier versions of this blog
a sitemap and a 404 page

Pushing to main builds the site with GitHub Actions and deploys it to GitHub Pages.

The part I appreciated most was the checking. Claude fetched every page of the live Bear blog and compared it against what the new generator produced. That turned up a couple of tables that were missing their header rows, which Bear had been quietly rendering wrong, and a dozen links and images that had been broken since earlier migrations. It copied my images off Bear's CDN, dug the missing ones out of this repo's git history, and fixed the links.

How the widgets work

The penguin up above is just a tag in this post's markdown:

<penguin-walker walk>

![screenshot of an animated cartoon walking penguin](/rebooting-this-blog-in-svelte-and-sveltekit/19am.webp)

</penguin-walker>

<script type="module" src="https://strangeleaflet.com/rebooting-this-blog-in-svelte-and-sveltekit/penguin-walker.js"></script>

Any HTML tag with a hyphen in its name is a valid custom element name. The markdown renderer sees <penguin-walker walk> alone on a line, treats it as raw HTML, and passes it straight through. The blank line after it ends the raw HTML, so the screenshot inside is still rendered as regular markdown.

Until the script runs, the browser has no idea what a <penguin-walker> is, so it just shows what's inside: the screenshot. That's also all that a feed reader or a browser without JavaScript will see.

Then the script defines the element:

customElements.define("penguin-walker", class extends HTMLElement {
  connectedCallback() {
    // read attributes like walk, insight, speed="80", and controls
    // swap the screenshot for a real penguin and start it walking
  }
});

The browser finds every <penguin-walker> already on the page and runs connectedCallback() on each one. Each penguin reads its own attributes, replaces its screenshot with the live version, and starts walking.

The script and the penguin GIFs live in the reboot post's directory, and the build copies them next to that post's page. The script finds its GIFs relative to itself (new URL("penguin.gif", import.meta.url)) rather than relative to the page, which is how this post can borrow the penguin from another post without copying anything.

So making a new widget is: drop a .js file into a post's directory, define an element with a hyphenated name, put the tag in the markdown with something sensible inside it, and add the <script> line.

Wrap up

Bear was the right move a year ago and this is the right move now. I get my words in plain markdown files, my theme, and the freedom to make any post as weird and interactive as I want.

This site is also now on a public repo: enjoy! github.com sdball/strangeleaflet.

Respect your tools

2026-10-23T13:17:23.171937+00:00

I really dislike folks using the term "clanker" for LLM things. It seems way too close to other -er slurs and used in the same derogatory way. Maybe there are people out there that also use weird terms to refer to their hammers, drills, trucks, cooking utensils, etc tools but I don't see the point.

Introducing curious.strangeleaflet.com and a new theme

2026-10-13T23:47:00+00:00

Hello! I've been having a ton of fun vibing up self-contained HTML pages to explore random interests and I finally assembled a hosting setup. You can find them all at https://curious.strangeleaflet.com and they are literally straight up from the public folder of curious-strangeleaflet. Very intentionally there's no cohesive theming, no build step, no script at all required. There is a script to serve them all up locally but that's just for convenience the pages work equally well when opened directly as HTML.

You can find a page on how bitfield encoding works which is a much more feature-filled version of the bitfield explorer I have on my toy Elixir site.

Or maybe mess around with complex numbers?

Or check out how morse code operators were basically doing pro-gamer speed things in the 1800s?

Check out the "text adventure interface" on the index page where you can jump back to like 1983 when I, as a little kid, was completely entranced by ZORK and Enchanter and the like. It's all themed like I remember the INFOCOM games running on our Atari 800XL.

I also finally decided to work up a proper theme for this blog. I hope you enjoy!

A History Degree Is A Programming Superpower in the Age of AI

2026-05-06T16:21:00+00:00

A history degree was always a cheat code for being a high level software engineer, but large language models have turned it into even more of a superpower.

The original case: programming is mostly narrative

Most people think programming is about writing code. After a few years in the industry, you realize programming is mostly about figuring out what’s going on. A bug report says one thing. The Slack thread says another. The commit history tells a third story. The person who wrote the original system left two years ago, and the design doc was already out of date before the feature even shipped.

Your job, before you write a single line of code, is to reconstruct what happened from incomplete and contradictory evidence. Then you have to tell the story back to your team in a way that lets them act on it.

This is what historians are trained to do. Sift sources of varying reliability. Notice the gap between what someone claimed at the time and what they actually did. Reconcile accounts that disagree. Build a narrative that holds up to scrutiny and lets the reader follow your reasoning back to the evidence. Swap “primary source” for “repo history” and the muscle is identical.

Engineers with humanities backgrounds tend to be unusually good at the messy, ambiguous middle of a project — the part where you’re not yet sure what you’re building or why the existing thing is broken. They’ve been training that exact skill since their first undergraduate seminar.

What LLMs change

Now add LLMs to the picture. Suddenly, generating plausible-looking code, prose, and explanations is essentially free. The bottleneck shifts. The scarce skill is no longer “can you produce text that compiles or reads well.” It’s “can you tell whether what you’re looking at is actually true.”

This is exactly the part of historical training that doesn’t get talked about much in the “history teaches you to write” pitch. Historians are trained to be suspicious. Where did this claim come from? Who is making it, and what’s their incentive? Is this a primary source or someone summarizing a summary of a summary? Does this document say what people remember it saying, or has the meaning drifted through retelling?

An LLM is, structurally, the worst possible source by these standards. It’s a confident narrator with no citations, no incentives you can audit, and a tendency to smooth over gaps with fluent invention. It is, in historian terms, a chronicler writing centuries after the fact who has heard a lot of stories and can’t always remember which ones were true.

If your instinct when reading any text is “where’s this coming from and how would I verify it,” you are dramatically better equipped to use these tools than someone whose instinct is “this sounds right, ship it.” The historian’s reflex — cross-reference, check the footnote, find the original — is the same reflex that catches a hallucinated API method before it makes it into production.

Writing things down, but more so

The other classic history-major skill is writing clearly. This was already useful in software, where most of the work product that matters long-term is documentation, design docs, and post-mortems. Code rots. Prose rots more slowly.

LLMs raise the stakes here too, in two directions.

First, the quality of what you get out of these models is downstream of the quality of what you put in. Vague, ambiguous prompts produce vague, ambiguous output.

Engineers who can specify a problem precisely in prose get dramatically better results than engineers who can’t. Writing clear paragraphs describing the system, its constraints, its desired behavior, and its edge cases has a huge payoff.

Prompting is a writing skill that wears a programming costume.

Second, as more code gets generated rather than hand-written, the comments, commit messages, and architecture docs become the actual record of human intent. The code shows what the machine produced. The prose shows what the humans were trying to do.

Future engineers and future LLMs reading the codebase will rely on that prose far more than they used to. Being a person on the team who writes it well is a compounding advantage.

Caveats

None of this means a history degree replaces learning to code. You still have to learn to code.

The argument is about which adjacent skills give you leverage on top of that, and how those skills are revalued in a world where generation is cheap and judgment is scarce.

It’s also not really about the degree itself but the habits the degree is supposed to instill. Plenty of CS majors have those habits, and plenty of history majors don’t. The point is that the training is well-matched to what software work actually demands now in a way that wasn’t obvious five years ago and is becoming more obvious every month.

The advantage

Software engineering has always rewarded people who can extract a clean story from a messy pile of evidence and write it down so others can act on it. LLMs make generating plausible stories trivial, which makes verifying them and writing them more clearly the bottleneck.

That bottleneck is the historian’s expertise.

I’d use Spinel for Ruby projects

2025-09-23T23:52:34.502231+00:00

From Shopify, pulling strings at Ruby Central, forces Bundler and RubyGems takeover my takeaway is that on any of my Ruby projects I’d absolutely use Spinel and stay far away from rubygems.org.

It’s a sad state that a core part of the Ruby ecosystem has been taken over by private parties and taken away from the community.

The video from Ruby Central to try and qualify their recent actions is woefully insufficient to justify their behavior.

Switched to Bear

2025-09-14T13:56:00+00:00

I was browsing around the Kagi small web and found that I was on a blog powered by Bear. A couple things caught my eye.

The blog was nice, readable, and fast enough to be a fine human experience.

The little bear unicode logo at the bottom was adorable.

I've been feeling more of a spark of annoyance than a spark of joy maintaining my own stack of blogging lately. While I love having the capability to add games like LiveView Life and a world-wide multiplayer minesweeper clone. The blog writing experience wasn't it.

The major stumbling block is that to write and publish a blog post required that I had to stack together a chain of tooling starting from writing a post an on arbitrary device to getting those words committed to my repo to publishing to fly.io. I've been contemplating writing an actual in-app editing stack but that would mean dealing with authentication and whatever data stacks e.g. probably storing the posts in Tigris.

Static site generators are an option but that's already what I'd written for Strange Leaflet using the excellent Nimble Publisher. I don't want a static site generator I just want to write words and share code snippets.

blot.im is a nice in-between a hosted option and a static site generator that I used before my journey into SvelteKit and then Nimble Publisher. Blot is joyfully scoped but I kept running into friction with its dropbox/git interface. I never found a writing experience that I enjoyed that also supported the mechanics of writing markdown files to Dropbox or committing files to a Git repo.

With a hosted blogging experience I get to leave more of my day job behind when I'm writing for my blog. Here are my words: please put them on the Internet in some kind of way.

Over my years of blogging I've had pretty good but not great experiences from many hosted blogging platforms.

I was writing with and writing plugins for Wordpress more than a decade ago. It is a supremely capable platform but it's also just that: a platform. Wordpress offers hundreds and hundreds of integrations and extensions and customizations. There's also the drama of .org vs .com and I don't really care.

That issue of hosted platforms trying to be appealing platforms for many uses is at the core of my hesitance towards going back to any of them. I'm not a writing team. I don't need editor/publisher roles. I don't need to integrate with single sign-on systems.

That left me wanting to find something but not really with any sense of urgency. So when I spotted that "Powered by Bear ʕ•ᴥ•ʔ" I was primed to click and see whatever the deal was. And what I found is exactly what I wanted and more!

A privacy-first, no-nonsense, super-fast blogging platform

No trackers, no javascript, no stylesheets. Just your words.

YES. And then I found the Bear Manifesto.

Bear won't shut down.

Bear won't sell.

Bear won't show ads.

Built to last

It's beautiful. Even further I found that Bear is source-available with a switch away from the MIT liecnse as of September 1, 2025. I am a huge fan of this approach.

This new license is almost identical to the MIT license but with the stipulation that the software cannot be provided as a hosted or managed service. Everything else is still permitted.

…

We're entering a new age of AI powered coding, where creating a competing product only involves typing "Create a fork of this repo and change its name to something cool and deploy it on an EC2 instance".

I am more than happy to support human programming and explicitly human programming that is focused on human use.

While migrating to Bear I also found that I appreciated its approach to content migration as well.

The easiest way to move existing content to Bear is to create new posts and copy the text content from your existing web pages one at a time.

Yeah! We aren't trying to seamlessly integrate writing and metadata from dozens of arbitrary systems. Get your words together and put them into Bear or don't.

I did.