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.
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.
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:
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.
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 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.
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.
> 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.
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.
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.
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.
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!
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.
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.
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 ;)
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.
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
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 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
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.
> 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.
> 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.
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.
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