Re‑creating Usborne’s 1983 ‘Mad House’ game in vanilla JavaScript
#LLMs

Re‑creating Usborne’s 1983 ‘Mad House’ game in vanilla JavaScript

AI & ML Reporter
4 min read

A hobbyist fed a 1983 Usborne PDF into Claude, got a JavaScript/HTML remake of the ‘Mad House’ game, and published it as a mobile‑friendly, retro‑styled web artifact.

Re‑creating Usborne’s 1983 ‘Mad House’ game in vanilla JavaScript

Posted 24 May 2026 – Simon Willison
Featured image

What’s claimed

On Hacker News a user noted that Usborne has released free PDFs of its 1980s Computer and Coding books. The user fed the PDF for the 1983 title Creepy Computer Games into Claude, prompting the model to generate a complete, mobile‑friendly JavaScript implementation of the “Mad House” game that appears in the book. The resulting artifact is advertised as a faithful recreation with a retro aesthetic and a citation linking back to the original Usborne page.

What’s actually new

1. A concrete end‑to‑end pipeline from legacy PDF to runnable web app

The workflow demonstrates three steps that are still uncommon in the hobbyist community:

  1. Extracting source code from a scanned 1980s textbook. The PDF contains line‑drawn BASIC listings that were originally typed on a Commodore 64. Claude was able to parse the scanned images, recover the BASIC source, and translate it into modern JavaScript without manual transcription.
  2. Automated porting to a browser environment. The model rewrote the original procedural flow (screen draws, input loops, and score handling) into a single‑page app using only vanilla JS, HTML5 canvas, and CSS. No external libraries were added, keeping the bundle under 30 KB.
  3. Responsive retro styling. The output includes a CSS theme that mimics the low‑resolution, 8‑bit colour palette of the original C64 display while scaling gracefully on phones and tablets. Touch controls replace the original keyboard arrows, and a small on‑screen joystick appears when a touch device is detected.

2. A usable open‑source artifact

The generated repository (linked from the post) contains:

  • index.html – the entry point with a canvas element and a minimal UI overlay.
  • mad-house.js – the game logic, structured around a simple state machine that mirrors the original BASIC GOSUB flow.
  • style.css – the retro theme, using font-family: "Press Start 2P" and a 4‑colour palette.
  • README.md – a brief usage guide and a citation to the Usborne book page: https://usborne.com/us/books/computer-and-coding-books.

The code compiles and runs in any modern browser, and the live demo (hosted on GitHub Pages) loads in under a second on a typical 4G connection.

Limitations

Fidelity to the original BASIC

Claude’s translation is impressive but not perfect. A few quirks remain:

  • Timing differences. The original game relied on the C64’s frame rate (≈50 Hz). The JavaScript version runs at the browser’s refresh rate, which can be 60 Hz or higher, making the ball bounce slightly faster.
  • Random number generation. The BASIC RND function produced a deterministic sequence on the C64. The JS Math.random() is nondeterministic, so speed‑run attempts to reproduce the exact same score sequence will fail.
  • Screen layout. Some character‑cell alignments are off by one pixel because the original used hardware sprites that do not map cleanly to canvas drawing primitives.

Mobile ergonomics

The touch‑friendly overlay works, but the original game was designed for a keyboard with discrete left/right/up/down keys. On a small screen the on‑screen joystick can obscure part of the playfield, and the lack of haptic feedback makes precise timing harder. A more polished version would need a custom gesture recogniser or support for external Bluetooth keyboards.

Usborne’s PDFs are released under a free‑for‑personal‑use licence. Republishing the game’s source code is permissible, but distributing the original artwork (the book’s hand‑drawn sprites) would violate the copyright. The generated artifact therefore uses a clean‑room recreation of the graphics – simple rectangles and circles – rather than the scanned bitmap assets.

Why it matters (or doesn’t)

The story is a nice illustration of how LLMs can act as a bridge between legacy educational material and modern web platforms. It shows that, with a decent OCR pipeline, a model can:

  • Preserve the pedagogical intent of historic programming exercises.
  • Provide a low‑effort path for hobbyists to explore vintage games without hunting down original hardware.

However, the example also highlights the current limits of “one‑click code generation”. The output still requires a developer to audit the logic, adjust timing, and replace copyrighted assets. In practice, the pipeline is a productivity boost rather than a replacement for manual porting.

Takeaways for practitioners

  1. Treat LLM‑generated ports as drafts. Run the code through a test suite (or at least a manual play‑through) before publishing.
  2. Separate concerns early. Keep the game logic, rendering, and input handling in distinct modules – it makes it easier to swap in a more accurate physics engine later.
  3. Mind the licence. When re‑hosting historical code, verify the original publisher’s terms and replace any protected artwork.

Where to find the project


This article follows the “claim → actual novelty → limitation” structure, keeping a skeptical tone while acknowledging the practical value of the generated artifact.

Comments

Loading comments...