HN Debrief

Decompiling a Nintendo 64 game in 84 days

  • AI
  • Gaming
  • Open Source
  • Programming
  • Legal

The post is a project writeup on decompiling Snowboard Kids, a late-1990s Nintendo 64 game, into source code that can be rebuilt and studied. The notable twist is heavy use of LLM agents, plus workflow tricks like explicit deadlines for agent tasks, to compress a job that usually takes years into 84 days. In this world, “decompilation” does not mean making a rough readable clone. It usually means producing new source code that compiles back to the original binary, or close enough to validate that the behavior has been recovered exactly. That matters because these projects are often the bridge to PC ports, mods, bug fixes, and long-term preservation of games whose original source code is lost or inaccessible.

If you care about preservation, ports, or modding of old software, AI-assisted decomp is becoming practical right now. If you want to build on it commercially or publicly, assume legal risk and plan around asset ownership, derivative-work questions, and the likely need for the original game files.

Discussion mood

Strongly positive about the technical achievement and about AI as a force multiplier for reverse engineering, with a persistent undercurrent of skepticism about AI-generated slop and real concern that the legal basis for matching decomp projects is unresolved.

Key insights

  1. 01

    Binary matching is a useful quality gate

    Matching the original binary gives AI-assisted decomp a rare objective test. That changes the usual AI argument because the hard part is not whether Claude or GPT wrote some C, it is whether the result reproduces the shipped game exactly. Several people drew a sharp line after that point. A matching decomp can be validated mechanically, but a PC port still lives or dies on human testing, controls, stability, and restraint. That is where many AI-heavy projects fall apart.

    Use binary equivalence as a checkpoint, not as the finish line. If you are building a port or modding toolchain, budget serious human time for QA, feel, and platform polish after the decomp is technically complete.

      Attribution:
    • fizwidget #1
    • ndiddy #1
  2. 02

    Asm matching is about preservation, not purity

    The push for byte-for-byte output is not just reverse-engineering machismo. It is the simplest proof that you actually recovered the original behavior, and with old console games that matters because tiny hardware-specific quirks can leak into gameplay, timing, graphics, or bugs. Cleaner code that is only functionally similar sounds nicer, but proving equivalence is harder than people think when the original software depends on exact cycle behavior, uninitialized memory, or other machine-specific oddities. Matching first is the safest way to document what the game really was before anyone starts improving it.

    If your end goal is a modernized codebase, still consider a matching pass first. It gives you a trustworthy baseline before you refactor away behavior that players or dependent tools may rely on.

      Attribution:
    • unknownfuture #1
    • qingcharles #1
    • Jegber #1
    • DSMan195276 #1
  3. 03

    Publishers are blocked by rights spaghetti

    The obvious question was why game companies do not run this playbook themselves and sell remasters. The answer given was not technical inability. It was that old games often sit inside a mess of contracts, lost source, dissolved studios, and asset licenses written for narrow platforms and time windows. Voice work, motion capture, music, models, and publishing rights may all have separate restrictions. Even internally, commenters with game industry experience said source archives were often badly managed or simply lost when studios collapsed.

    Do not assume a dormant game is commercially neglected because nobody sees the opportunity. In media businesses, broken ownership chains and asset licenses can outweigh engineering cost by a lot.

      Attribution:
    • Teknoman117 #1
    • godwinson__4-8 #1
    • wombat-man #1
    • qingcharles #1
  4. 04

    The bottleneck is workflow and toolchains

    The interesting operational detail was not just “use an LLM.” It was setting up a loop the model can actually work inside. People called out reconstructing the original build environment, wiring old tools through DOSBox, and giving agents explicit deadlines so they stop wandering into overbuilt solutions. Once that loop exists, LLMs are fast at repetitive recovery tasks like naming functions and labels. Without it, they burn tokens and time producing complexity you did not ask for.

    If you want to apply agents to old codebases, invest first in a tight compile-test-feedback harness. Prompting matters less than giving the model a constrained environment with fast verification and clear time bounds.

      Attribution:
    • rowanG077 #1
    • qingcharles #1
    • JLO64 #1

Against the grain

  1. 01

    New source may still be new authorship

    A minority view pushed back on the idea that matching decomps are plainly non-transformative. The claim was that many different source programs can compile to the same machine code, so finding one of those source representations is itself a creative act, especially when the end result is meant to be portable and maintained rather than merely mirrored. That does not settle the legal question, but it reframes the output as more than a mechanical transcription.

    Do not treat the derivative-work question as already decided in either direction. If this area matters to your project, get legal advice grounded in your jurisdiction and your exact distribution model.

      Attribution:
    • jonhohle #1 #2 #3
  2. 02

    For many fans the process is the point

    Some commenters rejected the framing that faster decomp automatically means a better outcome. In retro game communities, a lot of the value is in the craft and puzzle-solving itself. If a person wants to hand-recover a game for the joy and status of doing it, AI does change the meaning of the project even when it improves throughput. That helps explain why resistance is sometimes cultural rather than technical.

    If you are leading a community preservation effort, be explicit about whether the goal is speed, historical recovery, craftsmanship, or a playable port. Those groups will judge the same AI workflow very differently.

      Attribution:
    • doctorpangloss #1
    • trelbutate #1
    • spijdar #1

In plain english

binary
The compiled machine-code form of a program that a computer or console actually runs.
decompilation
The process of turning compiled program binaries back into human-readable code or an equivalent source representation.
DOSBox
An emulator that runs old MS-DOS software on modern computers.
LLM
Large Language Model, a machine learning model trained to generate and analyze human-like text.
PC port
A version of a game adapted to run natively on personal computers instead of its original console hardware.
ROM
Read-only memory, often used informally to mean a dumped copy of a cartridge or game image.

Reference links

Decomp and port projects

Tools and templates

  • dtk-template
    Suggested as a practical starting template for GameCube decompilation projects.

Related games and nostalgia

Personal reverse-engineering projects

  • FlappyBoot
    An older Atari 2600 project mentioned as part of a commenter’s retro development background.
  • u5-spec
    A binary spec for an Ultima V decompilation effort revived with help from modern AI tools.
  • u5-engine
    A Rust port of Ultima V built from the spec, shared as part of the same reverse-engineering effort.