Core War

AI notice: This text is created with the support of AI systems; it is reviewed editorially and taken responsibility for before publication.

Two programs are loaded at random positions into the same memory. They run in turns, and every instruction can overwrite any cell — the opponent's, and their own. Whoever is still running at the end wins.

That is the whole game. Out of it, forty years have produced a discipline where single constants decide rankings and where the top programs are a hundred lines long.

A. K. Dewdney introduced Core War in Scientific American in 1984. It is still played today, on servers that have been running since the early nineties.

Quick access

Why it is interesting

Core War is not a simulation of anything. It is a closed system with very few rules that nevertheless contains everything that makes complex systems interesting: strategy classes that beat each other in a rock-paper-scissors pattern, an arms race spanning decades, and questions you can only answer by measuring, because thinking about them is not enough.

An example: for thirty years the scene has said scanner beats paper, paper beats stone, stone beats scanner. We checked it against 349,866 computed battles. Exactly one of the three statements holds.

Where do you want to start?

What makes this site different

Core War knowledge has been passed down by word of mouth for decades. Much of it is correct. Some of it was correct once and has quietly gone stale — the field moved out from under the rule and nobody noticed.

So we took a different approach: where a number appears here, it has been computed. The basis is an archive of more than 1100 warriors spanning three decades, and a simulator engine built to answer questions nobody else is asking.

A few of the results:

• The classic rock-paper-scissors triangle now holds on only one of its three edges.
• Four out of five real development steps on a warrior are too small to demonstrate with any practical number of rounds.
• Testing against a single opponent does not get better with more rounds — it gets worse. You converge ever more reliably on the wrong answer.
• Two characters in the source separate a warrior that survives three quarters of its fights from one that loses every single round.

Every example on these pages has been checked against the engine. Where something is only a sketch, it says so. Where we got it wrong, that says so too.

You can search the underlying data yourself: over a million computed battles between 1104 warriors spanning three decades, every single pairing available to look up.

→ Who beats whom — the data behind every number here

Under Findings we document measurement results from our own warrior development, with measurement convention and sources — including when the result was negative.

And where this comes from

These pages are a by-product of a project that started in March 2026 at rank 654 and by July held first place in all three standings of the historic 94nop Koenigstuhl hill.

→ Three crowns on the Koenigstuhl — how that went → About this project — tools, methods, and what did not work

Learning path

• Step 1 · 9 min read

  Your first warrior

  How two programs fight in the memory of a virtual machine — and what your own first program looks like, the one that survives in there.

• Step 2 · 6 min read

  Understanding Redcode

  The anatomy of a Redcode instruction, the opcodes, the addressing modes — and why the suffix after the dot matters more than the instruction in front of it.

• Step 3 · 6 min read

  The strategy classes

  Stone, paper, scanner and the other basic forms — and what 349,866 computed battles say about which really beats which.

• Step 4 · 10 min read

  Testing your own ideas

  You changed something — did it get better? What 1.17 million computed rounds say about how much measurement it takes to answer that honestly.

• Step 5 · 8 min read

  Onto a hill

  How the public rankings work, how to submit a warrior — and which formatting mistakes kill a submission before it is ever computed.

Reference

• 8 min read

  Instruction set

  All 16 Redcode opcodes in detail — what they do, which modifiers matter for them, and how they are used in real warriors.

• 4 min read

  Addressing modes

  The eight Redcode addressing modes — how they compute an address, which side effects they trigger, and in what order that happens.

• 4 min read

  Modifiers

  The seven Redcode modifiers and their exact effect — which fields an instruction reads and writes, and why the modifier determines semantics more than the opcode does.

• 4 min read

  Standards and rule sets

  ICWS'88, ICWS'94 and '94nop — what differs between the standards, which settings the hills use, and what p-space is.

• 10 min read

  Strategy encyclopaedia

  The strategy classes in detail — construction, strengths, weaknesses and measured matchups from 349,866 computed pairings.

• 6 min read

  Tools and engines

  Simulators, optimisers, number tools and evolvers — what Core War authors actually work with, from hand-tuning to AI assistance.

• 5 min read

  Hills and community

  Where to play and where to find people — the active king-of-the-hill servers, the scene's gathering places, and the Hall of Fame.

• 6 min read

  Glossary

  The vocabulary of Core War — from addressing mode to warrior, briefly explained with pointers into the reference.

Findings

• 5 min read

  Portfolio and age

  Which of our warriors stand where, and how long they last — the current line-up on koth.org, the three Koenigstuhl standings, and every departure since August, with dates.

• 6 min read

  "Azathoth's stone is dead code" — a mistake, measured

  A counter said six lines of a top warrior were never executed — a process-level trace shows that, as a copy, they carry up to 79 percent of all instructions, and why our rebuilds were bound to fail because of it.

• 6 min read

  The premature pump death

  Why a bomber loses a good 14 percentage points more often with some step sizes than with others — no lattice and no coverage explain it, an opponent-free process counter does; and why it still does not become a build rule.

• 6 min read

  Why the test field overrates scanners

  One of our scanners measured 146.43 in the lab and debuted on the hill at 136.59 — the decomposition shows that stand-in opponents for scanners are off by up to 60 points per cell, with a chance probability below one percent.

• 6 min read

  The endgame clear that catches its own imps

  A stone/imp loses only to three papers and would reach rank 1 with their cells — the obvious rebuild, an SPL pre-pass before the clear, costs 5.65 to 18.70 points and shows why the gap sits in the class.

• 7 min read

  Paper and scanner as chassis — two directions, both measured shut

  A paper replica stays 15 points below the original and costs our own stone/imps 12 points; the best scanner chassis in the archive admits no contribution of our own — the balance of a day on which the top third was out of reach in every class.

• 6 min read

  The paper stalemate — eight parameters, eight null results

  Can a stone/imp be tuned so that it no longer ties against paper? Eight parameters of the chassis, each measured with a control, move the paper cells by at most 1.4 points — and the clear timing turns out to be an accident of the run, not a parameter.

← Core War overview