AI Can't Recreate the Thrust Game (But It Can Help You Understand It) | Hacker News Reader

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

jamesdrandall.com

52 pointsmsephton36 comments

Funny. I had claude recreate Thrust based on wiki article alone - and it nailed it. I then spent a week trying to implement a perfect autopilot for it. And then a solveable level generator. I have this running as a screen saver in one of my apps.

Love this!

It might not have been to the exacting taste of someone who wanted the exact BBC micro version however...

For sure. What it gave me was I think similar to the Amstrad version of Thrust and since I originally played it on a Commodore PLUS/4 I had to tweak it a bit. The fist version also had wrong gravity and rotation speed constants. But those were easy tweaks. Whenever I am bored or waiting for something more serious to complete I recreate games I used to play as a kid. I am currently working on Mercenary.

I’ve had this pretty frequent experience with AI where someone says, “AI can’t do X,” then someone a little more experienced with the tools or maybe a little luckier gets some prompts together with the solution in a few hours.

I think I’ve been on both sides of this.

Those “AI can’t do x” articles/videos are not aging well.

I’m not sure why people keep thinking like that after seeing Will Smith eating pasta.

Also, not for nothing but every one of those “AI got it wrong, it’s really ___” are… training AI how to get it right.

To be fair, designing an autopilot was an ordeal. Opus stuck to the principle of a mix of waypoint based routing plus a PD regulator - which made playing perfect levels hard. I wanted it to use the fact that the game mechanics is perfectly deterministic so theoretically it should be able to compute a perfect walkthrough before starting a level. It very reluctantly tried a monte carlo approach which ultimately kept failing. I have given up and went back to a smarter version of the waypoints + PD + softening the transition between waypoints. It is producing good, fast paced playthroughs but I've seen better speedruns by human players. Need to find time to see if Fable does a better job.

I tried to use his writeup to oneshot the game and you can see my results here along with the prompts I used:

https://kemendo.com/thrust-one-shot.html

Notably while the game "works" it's not even close to an a "reproduction" as far as I can tell - moreso an interpretation.

This has one level that doesn't level increment, none of the adversarial sprites are correct and the color and iconography are incorrect.

Granted I didn't give it much to work with but I figured I'd see what happens. As far as one shots go, I've seen worse.

I used commodity GPT 5.6 HIGH on firefox via chat interface

Your reconstruction is so close, I'm a little surprised you didn't stick with the original controls! Even though the BBC had a rather weird layout for all the non-alphanumeric keys.

It's been a very long time since I played Thrust, and I've played plenty of WASD games in the meantime, but it still felt really strange to control it that way rather than the classic BBC Z/X/*/? for left/right/up/down.

Pretty sure it was return to fire, space for shield/tractor; and maybe * for thrust? Edit to add: ah, no, shift to thrust. Works very well on modern keyboards too.

Maybe I should pop in an original keyset as an option - I think the original uses the caps key maybe. I'm pretty sure it's weird on a modern keyboard layout. I think the version on the bbcmicro site keymaps it by default, in any case if you want to revisit the original its here:

https://bbcmicro.co.uk/game.php?id=432

Edit: I'm going to have to go and revisit it again now... I was sure it was infuriating on a modern keyboard.

I feel like a lot of the success of an AI project currently still comes down to the skills of the operator. I don't think it is possible to say "AI can't create this because I told AI to create it and it failed" any more than you can say "You can't write this in Rust because I tried and failed."

There is still a TON of skill involved in guiding an AI to create something, and how good it turns out has a lot to do with how the AI development process went.

What I’ve discovered is for things I’m good at when AI takes a first shot at it I think “this is pretty mediocre “ and can guide it to something pretty good. If I’m less skilled on what it’s working on I tend to think “Hey this is pretty good!” But then I remember the former and then realize I don’t really have the skill to judge and that the work done is probably just… ok at best.

I generally apply this thinking when I hear people talking about using AI and their results and what I know about their skill levels.

This is often people invoking chesterton's fence, where the quickest way to have something corrected on the internet is just to say something wrong.

I hate when people say "AI" without specifying which model. It's like saying "plane" without specifying if you're talking about a Cessna or an F-22 Raptor.

> I asked Claude

There is no such thing as 'Claude'. Claude is a brand of model, some incredibly dumb and some incredibly capable. Was this 4.6 Sonnet? 5 Fable? Without specifying, the post is essentially meaningfless.

I get this all the time at work because I am bearish on “AI” - except I try it with the models available and they all fall down similarly.

Perhaps go try it with your model de jure and report back?

No mention of model, effort, harness, prompt, etc. Completely incompetent article, so it generating slop is not too surprising.

Someone should update the Lunar Lander page on Wikipedia -- it doesn't mention Thrust.

https://en.wikipedia.org/wiki/Lunar_Lander_(video_game_genre...

You don't land in Thrust ;)

8 months ago I got claude to do a perfect reproduction of the arcade asteroids game on a simple prompt and a once through.

I then got it to do lunar lander, that was also perfect, and very hard to land.

> This is where things got interesting. Not because AI wrote the code — the code itself isn’t complicated, it’s a 1986 game that ran in 32K of RAM — but because Claude turned out to be an extraordinary tool for interrogating 6502 assembly.

Complaining about slop with slop.

I was about to complain at you for jumping to conclusions, but your cited example contains two emdashes and a nested "it's not X it's Y". It certainly looks like slop. In my own writing I'm increasingly conscious of trying to avoid the appearance of slop, I would like to think I would have caught this.

For what its worth the article was a mix of things I wrote and things I asked an AI to generate from the notes I'd accumulated from the archaeology.

My focus was on the recreation - and getting it accurate was a lot of work (and a lot of fun). It's pretty easy to get an approximation (particularly if you just go with a standard physics model) but one that feels "off" if you played the original a lot.

A lot of people don't hate slop, they hate other people's slop. Of course their slop doesn't stink, they prompted it better or something.

> The tick loop waits at least 3 centiseconds per frame, giving an effective rate of about 33.33 Hz

3 centiseconds instead of 30 miliseconds, totally not a robot

Why would AI say that, when nearly every piece of training data is ever been fed would use milliseconds? I think much more likely that this is how the author thinks of it.

3 hundreds of a second == 33 Hz is very clean in my human brain.

No one, ever, uses centiseconds in this context.

Centiseconds was one of the ways time was measured on the BBC Micro. Your convenient options for accurately measuring the passage of time were vsyncs (50/sec), centiseconds (100/sec), microseconds (1,000,000/sec), or cycles (2,000,000/sec).

It's actually in the commented original disassembly and used in some of the original BBC documentation / writing. Which is how it ended up here - the article is a mix of things I wrote and things I asked an AI to write for me from the notes / findings from the archaeolgy.

Ok, that makes sense. I was commenting from a modern gamedev context.

The weird world of retro game archaeology - it's genuinely fascinating.

Hmm - the article isn't dated and it doesn't mention which models were used for the initial slop version. The initial commit in the git repo is from Feb 15, 2026.

I wonder how the initial pass would fare now with Fable 5 or 5.6 Sol?

I've been saying for months that any time you say something about the capabilities of the AI tooling you should say what exact model, agent, and effort level you're using. Because I've taken a few of those "AI can't do X" and had AI do a fine job at them.

I have Sol 5.6 ultra working on Thrust right now.

I think it was Opus but can't remember the version. Would have been whatever was available in Claude Code in February.

Managed to find some screenshots. It did work but gravity wasn't really gravity - things fell at a constant rate. Turrets were floating in mid-air. It was missing the shields and you couldn't pick up the ball from the pedestal.

https://www.jamesdrandall.com/old-thrust/1.png

https://www.jamesdrandall.com/old-thrust/2.png

https://www.jamesdrandall.com/old-thrust/3.png

> Now to be fair I was working from some commented disassembled source code

So claude didn't understand anything, and you would have done well to read the comments instead of the llm's output summarising the comments...

I'd be interested in seeing the "slop" version for comparison.

Managed to find some screenshots.

https://www.jamesdrandall.com/old-thrust/1.png

https://www.jamesdrandall.com/old-thrust/2.png

https://www.jamesdrandall.com/old-thrust/3.png

Reply on news.ycombinator.com