FORK BOMB: A Programming Game

From the Devs

Write real code in a Python-like language to control one machine that copies itself. Then watch a thousand copies of your program eat a world. A single-player programming incremental game about self-replicating machines.

You are handed one machine on a dead rock and a text editor. The machine can move, dig, sense the ground under it and read the colony's energy. Around lesson four it learns to do the one thing that changes everything: build a copy of itself. The copy runs your code. From the top. Exactly as written.

ONE MACHINE BUILDS ONE MACHINE

That is the entire game. Nothing else scales. There are no stat upgrades, no multipliers, no currency to spend on being stronger. Every unit of progress is a new function in your vocabulary - seventeen of them, from move() through sense() and spawn(). Fifteen arrive across the first ten lessons. The last two, send() and recv() for machine-to-machine messaging, open at lesson eleven. Your code is the only thing that scales.

CODE THAT WORKS FOR FOUR MACHINES FAILS AT FOUR HUNDRED

Not because of an artificial difficulty gate. Because a hundred machines converge on the same ore vein and starve. Because the swarm's own bodies block the only corridor. Because one event wakes every machine on the same tick. Because each machine gets a fixed instruction budget per tick, and naive code burns it and stalls where you can watch it happen.

Growth is the reward and the pressure at the same time. The machine count is the difficulty curve, so the late game never plays itself.

FIFTY LEVELS, AND THE HARD ONES TAKE THINGS AWAY

Eleven guided lessons introduce one idea each and never hand you a blank buffer. Thirty-nine scenarios across four tiers escalate from "one machine, five lines" to a radius-sixty world where the best program we know of puts four hundred machines on the map inside a hundred ticks. The pro tier is built by subtraction: no sensors, no price readout, no position, no identity. Ten levels switch an instrument off and tell you in-fiction why your sensor array is slag.

Then there is a sandbox with about thirty dials - world radius, ore density and hardness, radiation, volatile ore, turrets, holes, machine lifespan, upkeep, the instruction budget, and the API calls you can individually disable - and no goals at all.

THE ERRORS ARE THE TUTORIAL

The errors you will actually hit have a plain-English translation that points at the line and names the concept: "After a line ending in :, the next line must be indented 4 spaces - that's how the machine knows it belongs inside." The full API reference is one keystroke away, searchable, with a worked example on every call, and it tells you which calls are locked and which the level has taken away from you before you deploy. A Field Guide names every symbol on screen.

WHAT IT DOESN'T HAVE

No microtransactions. No PvP, no matchmaking, no ranked queue. No random numbers the game keeps to itself - the simulation is deterministic to the tick, so the same seed and the same program always produce the same run, right down to the machine that dies.

[hr][/hr]

Programming is done in a small language similar to Python. The first lessons introduce every concept you need, one at a time, and you edit working code rather than filling an empty file.

It will not hold your hand once the concepts are in. Figuring out how to actually solve a level is the game, and that can be genuinely hard if you have never programmed before.

And if you already write code for a living: the first ten lessons will take you under an hour, and then the interesting problems start, because they are the ones you have already met at work.