HN Debrief

How to Make a Nintendo 64 Game in 2026

  • Gaming
  • Open Source
  • Developer Tools
  • Hardware

The post is a making-of for Xibalba 64, a new first-person game released on Nintendo 64 hardware through ModRetro in 2026. It walks through how the game was built with modern community tooling instead of Nintendo's original closed SDK, what had to be solved to ship on real cartridges, and why a project like this is now practical for one developer. The key shift is that N64 development no longer means hunting down leaked IRIX-era tools and undocumented hardware behavior. Libdragon, modern MIPS targets in LLVM and GCC, emulators, flash carts, and reverse engineered docs have turned it into something much closer to normal embedded development.

If you are interested in constrained hardware, this is a real development target now, not nostalgia cosplay. The bigger opportunity is the tooling and distribution layer around retro hardware, where open SDKs, flash carts, clone consoles, and small-batch physical releases are turning old systems into viable niche platforms again.

Discussion mood

Enthusiastic and slightly amazed. People were excited that N64 development has become practical with modern open tooling, and many treated the post as evidence that retro consoles now have a real hobbyist and small-commercial ecosystem rather than just emulation and ROM hacks.

Key insights

  1. 01

    Libdragon now pushes past old assumptions

    Modern Libdragon work has moved beyond basic homebrew and into effects many people would not associate with the N64 at all. Commenters pointed to demos with bump mapping, HDR, seamless streaming maps, and related projects like James Lambert's Portal 64 and Oculus Rift experiments, which reframes the ceiling here from 'simple retro throwback game' to 'surprisingly capable fixed target with a strong software stack.'

    If you are evaluating retro hardware as a dev target, do not assume the limits you remember from commercial-era games are still the practical limits. Check the current SDK demos first, because the software stack has changed the platform more than the silicon has.

      Attribution:
    • Mizza #1
    • phoboslab #1
  2. 02

    Old consoles now feel like normal embedded targets

    People actively building for PS1 and N64 described a workflow that looks much more like modern systems programming than archival archaeology. Standard GCC and LLVM targets, community SDKs, better tutorials, and reverse engineered hardware references have replaced a lot of the pain from old proprietary toolchains. The hard part is no longer getting code to compile. It is understanding the hardware well enough to build good abstractions over things like the N64 display pipeline.

    The barrier to entry has shifted from tool access to hardware understanding. Teams can budget less time for environment setup and more time for building reusable libraries, debuggers, and docs.

      Attribution:
    • boricj #1
    • spicyjpeg #1 #2
    • yellowapple #1
  3. 03

    Boot code and lockout chips remain the real shipping hurdle

    Getting a ROM to run on real N64 hardware still means dealing with Nintendo's lockout scheme, not just compiling game code. Libdragon's signed bootloader works by brute-forcing a hash collision, and its development flow uses a tiny signed stage that loads a larger custom bootloader and even parses ELF binaries. That is the sort of deep platform work that turns homebrew into shippable software.

    If you want to ship physical cartridges, treat secure boot and manufacturing details as first-class engineering work from day one. The glamorous part is the game. The schedule risk is usually in the boot chain and cartridge compatibility.

      Attribution:
    • phoboslab #1
    • yellowapple #1
    • inigyou #1
    • monocasa #1
  4. 04

    The surrounding tools are becoming products too

    The most revealing side project was not a game but a flash-cart menu system with retail metadata, cheats, screenshots, and frame-perfect tool-assisted speedrun support. That points to a broader market around retro platforms where developers can build utilities, operating environments, and creator tooling, not just software that mimics old games.

    There is room to build picks-and-shovels businesses around retro hardware. Look at firmware, cartridge management, testing tools, and creator workflows, because those may have steadier demand than individual game releases.

      Attribution:
    • lmcd #1
  5. 05

    Physical distribution has a plausible niche business model

    Collectors and hardware enthusiasts said they will still buy cartridges even when flash carts and emulators are cheaper and easier. ModRetro's releases, open hardware cartridge plans, and devices like the forthcoming Epilogue 64 Operator suggest the market is closer to vinyl or boutique tabletop publishing than mainstream game distribution. The product is partly the software and partly the object.

    If you are considering a retro release, price and package it like a premium physical collectible, not like a mass-market digital game. The buyers who sustain this niche are paying for ownership, presentation, and hardware authenticity.

      Attribution:
    • dabluecaboose #1 #2
    • someperson #1
  6. 06

    LLMs are now good enough for weird platforms

    The striking part of the AI subthread was not hype about game design. It was the claim that Claude can already produce working N64 code when paired with emulator feedback over GDB Remote Serial Protocol. Others noted that this is believable precisely because the modern toolchain is ordinary enough for models to operate inside it. Niche console development is becoming legible to generic coding workflows.

    Expect old and unusual targets to become easier to automate as soon as they expose standard compilers, debuggers, and test loops. If you maintain a niche SDK, invest in clean CLI tooling and emulator hooks because that is what makes AI assistance viable.

      Attribution:
    • Flashtoo #1
    • yellowapple #1
    • rowanG077 #1
    • gambiting #1

Against the grain

  1. 01

    Retro 3D aesthetics are becoming a crutch

    Some people are tired of the flood of games borrowing PS1 and N64 visuals. The useful counterpoint was that low-fi 3D is not just fashion. It is a production strategy that lets small teams make 3D games without the asset burden of modern pipelines. That makes the style less a nostalgia pose and more an economic compromise.

    Do not read every retro-looking game as a branding move. If you are reviewing or funding one, look at whether the visual style is buying scope, speed, and shippability.

      Attribution:
    • zuzululu #1
    • hbn #1
  2. 02

    Retro enthusiasm is partly a reaction to today's game market

    The nostalgia in this conversation was not only about old hardware. It also reflected frustration with the current games business, especially bloated AAA production, layoffs, live-service friction, and the missing middle between giant studios and fragile indies. That backdrop helps explain why old consoles feel attractive as design spaces and commercial niches.

    If you build in games, do not mistake retro interest for pure sentimentality. It is also demand for tighter scopes, faster startup, clearer ownership, and products that respect players' time.

      Attribution:
    • newswasboring #1
    • pizza234 #1
    • officeplant #1
    • ColdStream #1
    • tayo42 #1

In plain english

AAA ↩
Industry shorthand for very large-budget, big-team commercial video games.
ELF ↩
Executable and Linkable Format, a common binary file format for compiled programs.
GCC ↩
GNU Compiler Collection, a long-running open source compiler suite for C, C++, and other languages.
GDB Remote Serial Protocol ↩
A protocol that lets a debugger control a program or emulator over a communication link.
HDR ↩
High dynamic range, a graphics technique that represents a wider range of brightness than standard rendering.
IRIX ↩
A Unix operating system made by Silicon Graphics that was used with some original Nintendo 64 development tools.
Libdragon ↩
An open source software development kit for making Nintendo 64 software without using Nintendo's original proprietary tools.
LLVM ↩
A compiler infrastructure project that provides an intermediate representation and code generation tools for many CPU architectures.
MIPS ↩
A family of processor architectures used in older game consoles and embedded systems, including the Nintendo 64 and PlayStation.
N64 ↩
Nintendo 64, a home video game console released by Nintendo in 1996.
PS1 ↩
PlayStation 1, Sony's original PlayStation home console released in 1994.
SDK ↩
Software development kit, a bundle of tools, libraries, and documentation used to build software for a platform.
Tool-assisted speedrun ↩
A highly optimized recorded playthrough created with tools like save states and frame-by-frame input control.
Zig ↩
A modern systems programming language often used for low-level software and tooling.

Reference links

N64 demos and projects

  • Libdragon demo showcase
    Shows modern Nintendo 64 homebrew effects that commenters cited as evidence of the platform's current capabilities.
  • Nintendo 64 driving an Oculus Rift
    Example of an unusual modern N64 experiment mentioned to show how far current homebrew work has gone.
  • Portal 64 video
    Referenced as another ambitious recent N64 project by the same developer behind the Oculus Rift demo.

Retro platform tooling and docs

Retro hardware and publishing ecosystem

Historical context