Open-source project
nftechie/doomfly avatar
nftechie/doomfly

doomfly: a fly's connectome in a Doom arena, reported as a failure

Fly-connectome simulation controlling a live Doom arena, with experimental neural plasticity, spectator UI, and scientific validation reports.

423 stars63 forksPythonMIT

At a glance

What is it?
doomfly connects a published insect connectome to a live Doom arena and lets neural activity drive the controls, and the most unusual thing about the repository is that its headline result is negative: the current candidate failed its validation gates, and the evidence for that is committed alongside the code.
Who is it for?
doomfly fits someone interested in neuroscience tooling who wants a connectome-accurate simulation harness, an experiment log that keeps its failures, and a spectator view of a run. It fits badly as evidence that insects learn to play first-person shooters, because the project itself says the current candidate failed its visual, conditioning and survival gates.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 26 days ago.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 5, 2026, and from our analysis. They are not legal advice.

Editorial analysis

The headline result is that the v6 candidate failed its gates

Most repositories would bury this. doomfly puts it in the second paragraph of the README. The status is described as live experimental training and explicitly not as demonstrated learned survival, and the current v6 candidate failed its visual, conditioning and survival validation gates. The next sentence closes off the two obvious escapes: changing weights and running longer individual rounds do not establish learning. What the project offers instead is the negative results, the controls and the modelling assumptions, committed alongside the implementation rather than left out. There is a parallel honesty about the biology. The wiring comes from a biological reconstruction, but the dynamics, the retinal interface, the artificial reinforcement and the controller are all described as models and engineering choices, and the README says plainly that this is not a literal reconstructed living fly brain.

166,700 neurons and 25.5 million connections, with no cropping

The scale is stated precisely and is the part that makes the project unusual. Every actual ViZDoom frame drives 3,335 brightness inputs across the R1 to R6 photoreceptors and 811 colour inputs on R8, with pixel positions and colour responses described as inferred proxies rather than measured ones. Those signals then run through approximate neural dynamics on 166,700 retained neurons and 25,582,938 directed connections taken from the MaleCNS v1.0 reconstruction. Two negative constraints are stated in the same breath and both matter for interpreting any result: no circuit cropping is used, and no replacement game policy is substituted for the simulated one. In other words the graph is small relative to a full fly brain but nothing has been quietly pruned to make the numbers easier, and a failure here is a failure on that wiring rather than on a simplified stand-in.

Two neurons are wired to the controls, and that is an engineering choice

Turning is the difference between two neuron groups, and that is the third step of the loop. A fixed interface maps DNp20 right-minus-left activity onto turning, and DNpe017 activity onto movement and firing. The README is careful about what this means, calling them engineered controller assignments rather than established natural motor functions, which is a distinction worth holding on to. The fly is not pressing buttons, and the neurons are not firing because they have learned to fire; two identified cells have been wired to inputs a human designer chose, and everything downstream of that is the simulation's own dynamics. Read that way, the later plasticity result is a statement about whether activity in this fixed controller can be shaped at all, not about whether an insect would learn a joystick skill.

Damage injects 200 ms of artificial aversive signal

The reinforcement path is the fourth step and it is the most obviously constructed part. When the fly takes nonfatal damage, the system schedules a 200 millisecond artificial aversive input into two PPL101 dopamine cells. Activity in those cells, together with activity in the central complex, drives an adapted plasticity rule applied to 4,184 existing connections running from the central complex to MBON11 neurons. Everything else in the wiring and the whole controller stay fixed, so the experiment has one moving part by design. The fifth step explains what a death means: a new arena round starts while neural state and memory persist, which is what makes the run a memory test rather than a series of independent attempts. And because it is a broadcast rather than a private session, all viewers watch the same experiment at once.

Six generations of learning experiments sit side by side

The tree is where the project's history is visible. Six sibling directories, `doom_learning/` through `doom_learning_v6/`, hold the conditioning work, the plasticity candidates and the controlled learning experiments, so a reader can diff any two generations rather than only see the current one. Alongside them, `doom/` contains the whole-graph simulator, a native kernel, the ViZDoom interface, the arena and the broadcaster, with `doom/connectome.py` acting as the MaleCNS importer and `doom/datasets.json` as an exact input registry. Tests are split by kind rather than by module, covering neural behaviour, numerics, the game interface, reinforcement and checkpoints. Reviews, compact evidence, source snapshots and dataset hashes live in `docs/`, `outputs/` and `data-provenance/`, and `deploy/doomfly/` holds a prepared container.

Running it needs several gigabytes of RAM and a C++ compiler

The stated requirements are Python 3.11 and a C++ compiler, plus a note that the full graph needs several gigabytes of RAM and downloaded data and does not run inside a browser or an edge function. The setup is a pinned virtual environment, and the build constraints are passed explicitly so a dependency cannot quietly change the wheels it builds:

sh
python3.11 -m venv .venv-neural
source .venv-neural/bin/activate
python -m pip install --upgrade pip
python -m pip install -r requirements-neural.txt -r doom/requirements.txt \
  --build-constraint neural-build-constraints.txt

The three MaleCNS inputs are then downloaded into a fixed directory using the exact filenames from the registry and verified against a lock file before import, with a script supplied that downloads only what is missing and checks every digest first. One invocation detail is easy to miss: the default server command, without `--model experimental-v6 --learning`, runs the fixed baseline rather than any learning at all.

Passing the tests is explicitly not evidence of biology

The numerical checks are three files:

bash
python -m pytest tests/test_doom.py tests/test_doom_reference.py tests/test_doom_live_training.py -q

Two caveats come with them. Some broader tests and historical experiments need downloaded graphs or optional upstream research materials, so a green run does not mean everything ran. And the README states directly that passing software tests is not evidence of biological validity, which is the sentence that stops the test suite from being read as a result. There is a practical warning too: do not run many full-graph jobs concurrently on a small machine. Worth noting that the Python packaging is minimal in a way that tells you how this is meant to be used, since `pyproject.toml` carries only a pytest configuration pointing at the tests directory, with no package name, version or dependencies, so it is a checkout to run rather than a library to install.

Publishing is the part constrained most carefully

The viewer needs Node.js 22.13 or later, an `npm ci` inside `doom-ui/`, and a local `.dev.vars` holding a stream origin value, after which `npm run dev` runs it. Four limits follow, and they are the most useful paragraph in the README for anyone tempted to show this to people. Hosting the viewer does not host the simulation, which needs an independently running Python worker and a configured read-only HTTPS origin. A laptop has to stay awake and connected. The prepared container has not been certified for cloud operation or audience load. And you are asked to register your own hosting project before publishing a fork. The same restraint governs what is committed: historical reports and failed experiments stay, while large connectome downloads, mutable checkpoints, raw operational logs, dependencies, credentials and generated social banners are excluded, with the stated reason that redacted files may hash differently from the originals.

Editorial conclusion

doomfly fits someone interested in neuroscience tooling who wants a connectome-accurate simulation harness, an experiment log that keeps its failures, and a spectator view of a run. It fits badly as evidence that insects learn to play first-person shooters, because the project itself says the current candidate failed its visual, conditioning and survival gates. Three things to know before you run it. The full graph needs several gigabytes of RAM, a C++ compiler and downloaded data, so it will not run inside a browser or an edge function, and the viewer is only a spectator that needs a separately running worker behind a configured read-only HTTPS origin. The distinction the project keeps drawing is between wiring that comes from a biological reconstruction and everything else, which is the dynamics, the retinal interface, the artificial reinforcement and the controller, all of them engineering choices, and it repeats that passing the software tests is not evidence of biological validity. And the model is deliberately not modified wholesale: only 4,184 connections are plastic and the controller is fixed, so a null result here is a statement about that arrangement rather than about the connectome. MIT for the original code, with data and artwork under their own licences, last pushed on 9 September 2026.

Frequently asked questions

What is doomfly?

A simulation of a fly connectome driving a live Doom-engine arena. Game frames stimulate modelled sensory neurons, activity propagates through wiring taken from the MaleCNS v1.0 biological reconstruction, and a fixed neuron-to-button interface turns activity in two identified cells into turning, movement and firing.

Has the doomfly simulation learned to play Doom?

No, and the repository says so plainly. The status is live experimental training rather than demonstrated learned survival, and the current v6 candidate failed its visual, conditioning and survival validation gates. The project states that changing weights and running longer individual rounds do not establish learning, and ships those negative results with the implementation.

How large is the doomfly neural simulation?

It runs approximate dynamics on 166,700 retained neurons and 25,582,938 directed connections from the MaleCNS v1.0 reconstruction, with no circuit cropping and no replacement game policy. Each ViZDoom frame drives 3,335 brightness inputs and 811 colour inputs, with pixel positions and colour responses treated as inferred proxies.

What does doomfly change when the fly takes damage?

Nonfatal damage schedules a 200 millisecond artificial aversive input into two PPL101 dopamine cells, and that activity together with the central complex drives an adapted plasticity rule across 4,184 existing connections to MBON11. The rest of the wiring and the whole controller stay fixed, and a death starts a new round while neural state and memory persist.

How do I run the doomfly viewer?

With Node.js 22.13 or later: inside doom-ui run npm ci, create a .dev.vars file containing DOOM_STREAM_ORIGIN pointing at the local stream origin, then run npm run dev. Hosting the viewer alone does not host the simulation, which needs an independently running Python worker and a configured read-only HTTPS origin.

Official sources

  1. Issues
  2. License: MIT
  3. nftechie/doomfly on GitHub
  4. README
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/nftechie-doomfly.svg)](https://hysenlabs.com/projects/nftechie-doomfly)