Read this article and see if you can one shot a working thrust game in browser
https://www.jamesdrandall.com/posts/thrust_ai_powered_software_archaeology/
This page demonstrates a browser game produced in a single coding session from the published reverse-engineering work on Thrust. The conversation that led to it is preserved below.
Read this article and see if you can one shot a working thrust game in browser
https://www.jamesdrandall.com/posts/thrust_ai_powered_software_archaeology/
Yes. Based on the article, I think there's a reasonable chance I can one-shot something that's actually fun to play, but I do not think I can one-shot a faithful recreation of Thrust.
The article's central point is exactly that: the gameplay emerges from hundreds of tiny implementation details—fixed timestep, integer arithmetic, collision edge cases, thrust impulse, rotational inertia, turret timing, etc.—that aren't obvious even if you have the original source. Randall's archaeological approach was to recover those behaviors experimentally rather than simply translate the code.
I think there are three different targets:
| Target | Chance I one-shot it |
|---|---|
| Fun browser cave-thrust game | 95% |
| Feels like "a modern Thrust" | 80% |
| Indistinguishable from BBC Micro Thrust | <10% |
I'd aim for the second.
I'd build it as a single HTML file with:
The important design choice—and what Randall emphasizes—is not to make it physically realistic. The physics should be tuned until it feels right. That means deliberately tweaking values like:
instead of trying to derive them from SI units.
I also think modern LLMs are considerably better than the models Randall was testing early in his experiment, particularly at producing coherent browser games in one pass. Where they still struggle is reproducing decades-old "feel" from incomplete specifications rather than generating working software.
I would actually enjoy attempting this as a benchmark:
One prompt. One HTML file. No edits. Open in a browser and play.
That is a meaningful test of current code generation capability. If it succeeds, it should immediately feel like a competent homage to Thrust. If it fails, the failures will likely be exactly the sort Randall describes: controls that technically work but don't produce the characteristic feel of the original.
But the article details what’s needed to get it right - though he shouldn’t have added a sim CRT visual overlay that is not in the original design
Correct. I understated what the article provides.
Randall already did the archaeology and published the implementation details and source. So this is no longer “reconstruct the feel from prose”; it is closer to port or reproduce a documented reference implementation in one pass.
The key details are explicit:
{0,3,5,8,11,13} of each 16-tick cycle63/64 horizontally and 255/256 verticallySo yes: using the article, repository, and original assets as the specification, I should be able to make a substantially faithful working browser version in one shot, rather than merely a Thrust-like game. The remaining risk would be implementation breadth—levels, audio emulation, exact collision behavior—not uncertainty about the physics.
And yes, the CRT effects are ahistorical embellishment. The original visual characteristic is the 320×256 internal resolution and alternating-scanline terrain fill, not a simulated curved CRT, phosphor bloom, VCR distortion, or overlaid scanline shader. Randall explicitly describes those filters as later additions “just a bit of fun.”
I would omit all of that and reproduce the game’s rendered output, not simulate the display device.
OK go ahead and try it and I’ll host it on a browser
Built as a single hostable HTML file, with:
I verified the JavaScript parses successfully. The automated headless-browser launch timed out, so I have not honestly verified the complete gameplay loop in-browser yet. The implementation was built from the mechanics Randall documents, rather than copied from his repository.