Doomformer compiles integer neural networks into playable DOOM maps. Duplicated player characters called voodoo dolls carry values through the level, floor lines encode weights, and sector lighting or geometry holds intermediate results. Python reads exposed values back from the game and compares them with a NumPy integer reference, with zero tolerance for differences, according to the project’s repository.
The project appeared on Hacker News’ October 30, 2026 front-page listing as “Show HN: I Turned DOOM into a Transformer.” That establishes its circulation on that date; the repository evidence does not establish a precise launch timestamp.
The interesting part is how much of the computation becomes inspectable game machinery. A network connection can become a line that dolls cross. Closing a gate can change an answer. The project then checks whether those physical arrangements produce the intended numbers.
It is an experimental computing project, with substantial published validation and spectacularly impractical performance. Both qualities matter.
How a Neural Network Becomes a DOOM Map
Doomformer maps numerical operations onto mechanisms available in ZDoom-family engines. Its repository describes the basic translation this way:
| Neural-network element | Representation inside the map |
|---|---|
| An integer value, such as 5 | Five voodoo dolls |
| A weight | A floor line that adds the weight when a doll crosses |
| An accumulated sum | A sector’s light level or floor height |
| A ReLU activation | A staircase of gates that dolls must climb |
| An attention operation | Dolls passing under ceiling gates controlled by another value |
| A disabled connection or lesion | A closed door |
The arithmetic follows from repeated crossings. If an input has value five, five dolls cross its weight line. Each crossing contributes the encoded weight, so the accumulated contribution implements multiplication by that integer input. Contributions from multiple inputs build a sum. The activation machinery then determines the dolls available to the next layer. The repository’s explanation describes attention-related multiplication through ceiling gates: one value changes the clearance, and counting the dolls that get through produces the result.
This is computation through game state, with movement and timing constraints attached. It also makes the choice of integer networks important. Doomformer checks against a corresponding integer implementation, not an arbitrary floating-point model.
The engine introduces hazards that a conventional numerical library would never encounter. According to the project:
- A moving floor ignores a second movement request while it is still moving.
- Teleporting can cancel lines a doll crossed earlier in the same game tic.
- Geometry placement can go wrong far from a spatial-partitioning node, so the compiler keeps maps within 32,000 game units.
Those details explain why this needs a compiler, not simply a collection of cleverly arranged rooms. The compiler must schedule operations around the engine’s behavior while preserving the intended arithmetic.
The project also credits earlier DOOM calculators and cellular automata. Its stated contribution is the neural-network compiler and exact value checking, not the first discovery that DOOM maps can compute.
Exact Arithmetic Is Different From Correct Classification
Doomformer’s strongest technical claim concerns agreement with its reference implementation. Every exposed value is compared with NumPy, and any difference fails the check.
The repository states the distinction clearly:
“EXACT means DOOM got the same numbers as the integer network. It does not mean the digit is right.”
For the full 10,000-image MNIST test set, the project reports these results:
| Measurement | Reported result |
|---|---|
| Digits classified correctly by the integer model | 9,716 of 10,000, or 97.16% |
| Test digits with exact agreement against the integer reference | 10,000 of 10,000 |
| Accuracy of the floating-point model | 97.58% |
These are project-reported results, not independent measurements. This article analyzes the published implementation description and results; it does not reproduce them.
The distinction is consequential. A compiler can faithfully execute a model that makes a bad prediction. Here, exact agreement across 10,000 digits means the checked game computations matched the integer reference for those inputs. The 284 incorrect classifications remain incorrect, even when DOOM reproduces them perfectly.
The floating-point model’s reported accuracy is 0.42 percentage points higher. That comparison helps separate the integer model’s predictive performance from the separate question of whether the map executes it correctly.
I’d treat those as two different scorecards: classification accuracy measures the model, while exact agreement measures the compiled execution against its reference. Combining them into a single claim of “100% accuracy” would erase the most useful distinction in the project.
The Tests Also Attack the Checker
Doomformer goes beyond displaying a correct-looking digit. Its repository describes tests designed to expose mistakes in the generated maps and their validation.
| Published check | Reported outcome | What it helps examine |
|---|---|---|
| Compare exposed map values with NumPy | Zero tolerance for differences | Agreement for the values and inputs checked |
| Fuzz 20,000 random networks at range limits | Zero mismatches | Behavior across varied networks and boundary values |
| Tamper with one weight line | Checks fail on inputs that cross it | Whether an exercised arithmetic change is detected |
| Mutate a map line 1,004 times | 297 mutations caught | Sensitivity to map changes, with unresolved survivors |
The repository also says continuous integration fuzzes a fresh seed on every push. Crucially, its verification section limits what these results mean: a successful run supports the inputs that actually ran.
The mutation result deserves particular attention. Catching 297 of 1,004 changes leaves 707 uncaught, but that is not automatically 707 incorrect computations slipping through. A mutation might affect a path that the selected inputs never exercise, or leave the checked result unchanged. The repository says no surviving mutation is proven harmless.
That qualification makes the result more informative. It exposes an unresolved coverage question instead of turning a large test count into a blanket correctness claim.
My view is that this is Doomformer’s most useful contribution beyond the novelty: it separates a working demonstration, exact agreement on exercised cases, and a general proof of correctness. The published evidence supports the first two. The mutation survivors show why the third remains a much larger task.
Why the Extreme Slowdown Matters
The Show HN poster, falperc, described Doomformer as an alternative to NumPy, adding that it was “a 65000x slower one”. The post does not provide enough benchmark conditions to treat that figure as a general performance ratio.
The repository provides a more concrete example. Its digit-drawing demonstration uses 1,355 voodoo dolls and reads back 248 values. One published READ pass takes 273 game tics, approximately eight seconds at DOOM’s 35-tic-per-second simulation rate. The same output reports about three seconds of wall-clock time, illustrating why simulated game time and elapsed execution time need separate labels.
Frequently Asked Questions
3 questions
1Does Doomformer Run in the Original DOOM?
The documented demonstrations target ZDoom-family engines. The museum self-test reportedly works in four named ports, including GZDoom and ZDoom 2.8.1.
