A Super Mario 64 demake for the GBA built with Claude. Mario’s physics are bit-identical to the original

I built this with Claude as an experiment: how far can an LLM take a demake if I steer it but don’t write the code? I chose the project, the direction and the trade-offs. Claude wrote the code, the tests and the tooling. Repo: github.com/Kodoque1/sm64-gba (MIT, free) What it is SM64’s movement and collision code running under GBA constraints: a 16.8 MHz ARM7 with no FPU. A playable demo: 4 levels, software 3D, Mario animated with the game’s own animation data. An optional libsm64-style import: it reads your ROM to build in Mario’s real model and the real level meshes. The repo contains nothing from Nintendo. How Claude was used My instructions were short (“bit-exact first”, “now optimize”, “make a fluid demo, degrade gracefully”). Claude worked in an agentic session with a toolchain and a headless emulator, profiling, rewriting and checking on its own. The design discussions were the best part. When I asked whether an animated Mario was possible, Claude declined to draw Mario’s likeness but built a wooden mannequin posed by the real animations. I suggested one sprite per body part; it proposed ellipsoids, because an ellipsoid’s outline is always an ellipse, which is exactly what GBA affine sprites can draw. When I suggested a sprite atlas, it explained why that can’t work and proposed rendering the real low-poly mesh, taken from my own ROM. Try it (free) make fetch && make demo builds a ROM that runs in mGBA (mannequin version). With your own ROM: make import ROM=sm64.z64 && make demo make demo-check re-checks the physics. No ROM is distributed. Limits Tested in mGBA only, not on real hardware. 30 fps on 98% of frames. No enemies or objects, flat colors instead of textures.