Yeah, I’m quite surprised at this comment. Commercial video games are mass-produced products, and as much as I dislike designers being bogged down in technical minutiae, having a sense of industrial design for the thing you’re making is an incredible boon.
Fumito Ueda was notably quite concerned with the technical/production feasibility of his designs for Shadow of the Colossus. [1] Doom was an exercise in both creativity and expertise.
> Fumito Ueda was notably quite concerned with the technical/production feasibility of his designs for Shadow of the Colossus. [1]
And he didn't really achieve it - the game runs very slowly and has a good deal of cut content.
(I once got him in trouble because I found a GPL violation in ICO. I assume the developer didn't pursue it because I don't see the source code up anywhere.)
My unfounded hunch for the computing bit is that home computers became more and more commonplace in the home as we approached the 21st century.
A Commodore 64 was a cool gadget, but “the family computer” became a device that commoditized the productivity. The opportunity cost of applying a computer to try something new went to near zero.
It might have been harder for someone to improve the productivity of an old factory in Shreveport, Louisiana with a computer than it was for the upstarts at id to make Doom.
Super Mario 64 is a video game that’s had a lot of rereleases, both official and unofficial. I sometimes wonder if the most people who have experienced it did in a way that wasn’t like the original Nintendo 64. The Switch version sold almost as many copies. As a kid, I beat it with arrow keys on an emulator in 2001.
When I read the responses to this document, I wonder if Dragon Ball is the same, where the collective nostalgia is actually quite diverse.
I think the source code in the GitHub repo generates the ROM in the corresponding screenshots, but it seems quite barebones.
It feels very much like it’s cobbled together from the libdragon examples directory. Or, they use hardware acceleration for the 2D sprites, but then write fixed-width text to the frambuffer with software rendering.
Partially correct. The value is not the game interface right now. Its proof you can do actual inference on an LLM the surprise I am developing is a bit bigger than this, just have to get the llm outputs right first!
You’re right that the graphics layer is mostly 2D right now. Sprites are hardware-accelerated where it makes sense, and text is written directly to the framebuffer. The UI is intentionally minimal.
The point of this ROM wasn’t the game interface — it was proving real LLM inference running on-device on the N64’s R4300i (93 MHz MIPS, 4MB RDRAM).
Since the original screenshots, we’ve added:
• Direct keyboard input
• Real-time chat loop with the model
• Frame-synchronous generation (1–3 tokens per frame @ 60 FPS)
So it’s now interactive, not just a demo render.
The current focus is correctness and stability of inference. The graphics layer can evolve later.
Next step is exposing a lightweight SDK layer so N64 devs can hook model calls into 3D scenes or gameplay logic — essentially treating the LLM as a callable subsystem rather than a UI gimmick.
The value isn’t the menu.
It’s that inference is happening on 1996 silicon.
Happy to answer specifics about the pipeline if you’re interested.
Simultaneous turn based top down car combat where you design the cars first. Inspired by Car Wars, but taking advantage of computers, so spline based path planing and much more complicated way of calculating armor penetration and damage.
My first job out of school was on one of the HD expansions at SkyBox Labs. It was mostly grunt feature work and desync fixes, but I remember that some of the handcoded ASM from the legacy pathfinding had been one-to-one translated to C++.
I always wondered if that contributed to the pathfinding regressions that were talked about online. Or, you learn about compiler-induced accidental UB in school, and part of me wondered if something was happening there.
reply