Claude reverse-engineers 1997 DOS game into a web version

Rebuilding a lost legacy

A developer recently tasked the AI model Claude with a complex project: turning a 1997 MS-DOS game called Beer Manager into a modern web application. The original game, an economic simulation where players build a brewery business, was created over two years in the mid-1990s. Because the original source code was lost, the AI had to work exclusively from the finished executable file.

The developer wanted a 1:1 clone that preserved the original graphics, sound, and gameplay mechanics. This meant the AI could not simply create a new version of the game; it had to behave identically to the original. The developer wanted to ensure that if a player made the same moves with the same starting conditions, the outcome would be exactly the same as it was on a 1990s computer.

Orchestrating the AI workforce

The project utilized a multi-model approach to manage the different complexities of the software reconstruction. The Opus 5.5 model served as the primary lead, handling the core simulation logic and the main development sessions. It acted as the central coordinator for the project's most difficult technical hurdles, ensuring the primary game engine remained consistent across the entire build.

To handle specific components, the developer deployed Sonnet 5.5 sub-agents to focus on specialized tasks like building the audio systems and the in-game dialogs. This division of labor allowed the AI to tackle various parts of the code simultaneously while maintaining a unified structure. The main session reviewed the work of these sub-agents before any code was officially committed to the project.

The final web version was built using TypeScript, Canvas 2D, and WebAudio without using any common UI frameworks or runtime dependencies. The only third-party runtime code included in the project is ymfm, which is an OPL3 sound-chip emulator compiled to WebAssembly. This specific component allows the web version to produce the same tunes that the original 1990s sound hardware did.

Decoding the machine language

To begin the reconstruction, the developer had to prepare the original 1997 executable for analysis. This involved relocating the LE image by applying all 40,517 fixups, wrapping it as an ELF, and using a decompiler called Ghidra. The developer also had to add a specific calling convention for Watcom’s register passing to ensure the decompiler could accurately interpret how the processor handled data.

The resulting decompile produced a massive amount of C code that lacked any human-readable names or comments. Because the compiler strips away information like variable names, the AI had to identify functions based on their behavior. For example, a routine the original author might have named for delivering beer was reduced to a simple memory address, requiring the AI to deduce its purpose from its actions.

The developer also ran the original game in a headless DOSBox Staging emulator to observe the user interface behavior. This allowed the AI to pull out graphics, fonts, maps, audio, and all 2,235 strings from the original file. By comparing these observations with the decompiler's output, the AI could gradually reconstruct the meaning of thousands of different building blocks.

Achieving mathematical parity

A major challenge was ensuring the new web version behaved exactly like the original in every scenario. To achieve this, the AI had to recreate specific C semantics for integer helpers and maintain the exact x87 evaluation order for floating-point code. Even tiny differences in how a computer rounds numbers can cause an economic simulation to drift significantly over many months of game time.

The developer also worked closely with the AI to resolve specific design choices during the process. During a second round of questions, the developer accepted the AI's recommended answers for every single one of the 24 product questions posed. This level of precision ensured that the final web version was not just a functional imitation, but a strict clone that reproduces the original's specific rules and odds.

The AI had to ban modern shortcuts like Math.pow in favor of a port of Watcom’spow and use the Watcom random generator with a specific ID for each call site. This was necessary because a single extra roll anywhere would throw off the entire game. The AI even had to ensure that the game state lived in one 402,672-byte buffer, arranged exactly as it was in the original, to allow for byte-for-byte comparison.

Verification and testing

To guarantee the accuracy of the clone, the developer implemented four levels of automated testing. One level compared the building blocks of the game logic to ensure they matched the original down to the last byte. Another level ran both versions side by side for two game years at a time, checking the state at every month boundary to catch bugs that a single routine test might miss.

The testing process also included logging every dice roll to see if the new version followed the same sequence as the old one. Furthermore, the developer compared 86 reference frames and scripted UI cases by checking the palette index and DAC entry. This pixel-perfect check ensured that the colors and images were identical. An independent review was required to fix a bug where the checker would have accepted white text drawn in the wrong color, such as magenta.

The developer faced several technical hurdles during the verification phase. For instance, an x86 emulator's fxch instruction silently did nothing, which made a demand formula look wrong until the real x87 settled it. Additionally, a hung emulator once froze a test run for nine hours, leading the developer to add a timeout to those calls. Finally, the developer confirmed the clone's accuracy by exporting a save file from the new version and loading it into the 1997 original to see if it continued identically.