The project began as a simple question: could an AI model take Jordan Mechner's published Apple II source code — 6502 assembly for a 1989 Broderbund game, later acquired by Ubisoft — and produce a working C# port? Priyan R. supplied the source, wrote no code himself, and played the results.
The opening paragraph explains that the experiment started from Jordan Mechner's published Apple II source code — 6502 assembly for a 1989 Broderbund game later acquired by Ubisoft — with Priyan R. supplying that source as the only input.
Round 1 (Claude Opus 4.6, February 2026) produced a C# console game, then a level editor, then a Raylib graphics version. It parsed the original level files correctly — rooms, tiles, gates, guard positions — but the engine was wrong. The prince moved one tile at a time, hopping between cells, while the real game plays hand-drawn animation frames with sub-tile movement per frame.
Round 2 (OpenAI Codex, March 2026) made sensible surface fixes: sharper pixel filtering, transparent sprite backgrounds, openable gates, pillar tops that were no longer walls. The prince still ended up in wrong positions and got stuck. It polished without fixing the foundation.
Round 3 (Claude Opus 5, September 2026) changed the rules. Two Claude Code skills controlled DOSBox — launching the real game, sending keys, taking screenshots — and the model compared against it. Opus 5 diagnosed the architecture problem, rebuilt the engine around the original's frame-sequence design, and extracted animation tables from PRINCE.EXE by searching for byte patterns recognised from the Apple II source. It confirmed each table against a second known value before trusting it. No copyrighted game data entered the repository; the C# program reads it live from the user's own DOS install.
Round 4 (Claude Opus 5.5, September 2026) required a single prompt: "the character moves runs jumps but gate positions bricks all different, you are new model let see anything u can improve." Opus 5.5 found the original game's room-drawing routine, documented by Dávid Nagy and the princed.org community in the open-source SDLPoP project, and ported it. The resulting DosRoomDrawer.cs is a C# port of SDLPoP's src/seg008.c, as the file header states.
SDLPoP's documentation explained what earlier sessions had only guessed at: the brick pattern is seeded from room, row, and column so every wall looks identical on every visit; the level-1 gate is open in the level data, with a hidden button press as the prince drops in that explains the slamming sound.
Opus 5.5 also discovered that PRINCE.EXE is compressed with Microsoft EXEPACK — earlier tables had only worked because they sat in a stretch the packer left untouched. It wrote an unpacker and read the tile-drawing tables directly. A pixel-by-pixel comparison against the real game in DOSBox reduced differences on the first screen of level 1 from 8,429 to 2 (a torch flame caught at a different moment). The second room and the level-3 exit door matched too.
It was not flawless: the prince's sprite drew correctly facing one way but sank a few pixels into walls facing the other. Opus 5.5 verified movement across all test ticks, isolated the sprite problem, and reverted only that part — a self-check the author calls a sign of progress.
The project repository (github.com/priyanr/PrinceOfPersia_C-Sharp_Port_By_AI) preserves every session in SESSION_HISTORY.md and is licensed under GPL-3.0-or-later because DosRoomDrawer.cs carries SDLPoP's GPL notice. It requires the player's own legally obtained DOS copy of Prince of Persia; no game data is distributed.
Paragraph 9 describes the project repository at github.com/priyanr/PrinceOfPersia_C-Sharp_Port_By_AI, noting it preserves every session in SESSION_HISTORY.md and is licensed under GPL-3.0-or-later because DosRoomDrawer.cs carries SDLPoP's GPL notice.
What remains uncertain. Opus 5.5 itself said it could not have reconstructed the drawing code from the DOS binary alone in one prompt — it relied on SDLPoP's published reverse-engineering. Guards, sword fighting, palace levels, and exact landing positions are still incomplete. The experiment demonstrates what successive models can achieve when given a way to test against reality, but it is one developer's single project, not a controlled benchmark.
The experiment stands on decades of community work: Jordan Mechner's published Apple II source, Dávid Nagy's SDLPoP reconstruction, and Fabien Sanglard's code review of the original.