AI Can't Recreate the Thrust Game (But It Can Help You Understand It)

By James Randall

---

The Quest for a Classic

I recently decided to see if modern AI could resurrect a piece of my childhood: the 1986 BBC Micro classic, Thrust. Developed by the talented Jeremy C. Smith (who later co-created Exile before his untimely passing in 1992), Thrust is a masterpiece of deceptive simplicity.

What is Thrust?

The gameplay loop is a tense battle against physics:

• Objective: Navigate a ship through treacherous caverns.
• Challenges:
  • Manage limited fuel.
  • Evade hostile turret fire.
  • Retrieve a pod for extra points.
  • Fight constant gravity and momentum.

I still keep a BBC Master on my desk and occasionally play Thrust alongside other staples like Elite and Holed Out. Having already recreated three of these in various ways, I felt it was time to tackle the fourth.

---

The Experiment: AI vs. 8-Bit Logic

Inspired by the latest claims regarding the capabilities of Anthropic and OpenAI, I gave Claude Code a comprehensive mission. I provided:

1. A detailed technical specification.
2. Screenshots of the original game.
3. The disassembled original source code.

The Result: "Slop"

The output was, in a word, impressive dreadful. While it vaguely resembled the game—it even attempted the scanline aesthetic—it was completely unplayable.

"You can easily build something that looks like Thrust using standard delta-time physics and a frame-rate loop, but the magic lies in the specific timings and the 'weight' of the ship."

---

AI as a Digital Archaeologist

While Claude failed as a developer, it proved to be an incredible translator. I discovered a brilliantly commented disassembly of the original source by Kieran Connell and began using the AI to interrogate the 6502 assembly code.

My Research Workflow:

• Feed disassembled code blocks into Claude.
• Ask specific questions (e.g., "How is the level data structured?").
• Extract detailed explanations of 8-bit logic.
• Test Claude's accuracy by stripping the comments from the source.

The AI helped me uncover hidden nuances I'd never noticed in decades of playing, such as the fact that turrets temporarily cease fire if you destroy their generator, and the specific subtleties of their firing arcs.

---

The Deep Dive: Physics & Timing

The most fascinating revelation came from analyzing the physics engine. Thrust doesn't use floating-point numbers; instead, it employs Q7.8 fixed-point arithmetic.

The Mathematical Foundation

The rotation system is limited to 32 steps, utilizing lookup tables for force components. To represent the drag calculation, we can look at it as: $\text{Force}_y = \text{Force}_y \times \frac{255}{256}$

The Timing Mystery

Initially, I used the exact constants from the disassembly (gravity, thrust, drag), but the ship felt far too agile. I realized the issue wasn't the values, but the timing.

1. The Frame Rate: The game doesn't run at the BBC Micro's $50\text{Hz}$ VSync. It waits 3 centiseconds per frame, resulting in $\approx 33.33\text{Hz}$.
2. The Gating: Physics updates are not constant. They are gated to only 6 active slots within every 16-tick window.

The Implementation

The core logic for this gating looks like this in code:

/** The 6 active physics slots per 16-tick window */
private static readonly ACTIVE_SLOTS = new Set([0, 3, 5, 8, 11, 13]);

private tickStep(input: ThrustInput): void {
    const slot = (this.tickCounter + 1) & 0xFF; 

    // Rotation: occurs 3 out of every 4 ticks
    if ((slot & 0x03) !== 0 && input.rotate) {
        this.rotation = (this.rotation + 32) % 32;
    }

    const isActiveSlot = ThrustPhysics.has(slot);

    // Force calculation — only on active slots
    if (isActiveSlot) {
        s.forceY *= (1 - 1 / 256); // Y: *= 255/256
    }

    // Position integration — happens every tick
    s.posY += s.forceY;
}

By implementing this gating, the effective force/drag rate drops to roughly $12.5\text{Hz}$, finally capturing the authentic, heavy feel of the original 1986 experience.