Your first warrior

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

Core War is a game in which two programs fight inside the memory of a virtual machine. They run in turns, they can overwrite each other, and whoever is still running wins.

That sounds like a lot. Your first program will be one line long.

A. K. Dewdney introduced the game in his Scientific American column in 1984. The programs have been called warriors ever since, and the language you write them in is called Redcode.

The arena

The battlefield is called the core. It is a memory of 8000 cells closed into a ring: after cell 7999 comes cell 0 again. There is no edge to fall off and no wall to run into.

Each cell holds exactly one instruction. Not data and program kept separately — both live in the same cells. That is why the game works at all: what is program to one warrior is a target to the other.

Both warriors are loaded at random positions into this ring. Neither knows where the other is. Then they execute one instruction each, alternating.

The core is not empty

This is worth pausing on, because many introductions leave it out.

People tend to picture memory as an empty field with two figures standing in it. It is not like that. Every one of the 8000 cells is already filled before the round starts — with this instruction:

DAT.F   $0, $0

DAT is the only instruction in Redcode that does nothing. And that is exactly what makes it lethal: a process that runs onto a DAT dies. Immediately and permanently.

So the core is not an empty field but a minefield consisting entirely of mines. The two warriors are the only places where something other than certain death is written.

From this follows the first rule of the game: a warrior does not lose because the opponent hits it. It loses because it runs onto a DAT. The opponent only has to make sure that happens — usually by writing DAT instructions where the other one is currently working.

The smallest warrior in the world

Here it is. The imp, also by Dewdney:

;redcode-94nop
;name Imp
;author A. K. Dewdney

        MOV.I   $0, $1

        END

One instruction. Translated, it says:

Copy the instruction that is here into the cell right behind it.

MOV stands for move, meaning copy. The .I means: copy the whole instruction, not just part of it. $0 is "this cell here", $1 is "one cell along".

What happens

Suppose the imp sits at cell 100.

1. The process stands on cell 100 and executes MOV.I $0, $1. It copies the contents of cell 100 into cell 101. Cell 101 now also holds MOV.I $0, $1.
2. The process then advances one cell, as it always does after an instruction that contains no jump. It now stands on cell 101 — on the copy it just wrote itself.
3. That one does the same: it copies itself to cell 102. The process advances. And so on.

So the imp travels through the core by continuously copying itself ahead and running after the copy. It leaves a trail of itself — and because the core is a ring, after 8000 steps it arrives back where it started.

It is neither fast nor clever. But it is extraordinarily hard to kill, for a simple reason: anyone trying to overwrite it hits a cell the imp left long ago.

Imp versus imp

What happens when two imps meet? Measured over 200 rounds:

Round result: 0 wins : 0 wins : 200 ties

Two hundred ties. Not a single win on either side.

That is not a boring result but an instructive one: two imps can do nothing to each other. Both keep running until time runs out. A tie occurs in Core War whenever both warriors are still alive after a fixed number of cycles — 80,000 here.

Remember this: ties in Core War are not a fallback result, they are a tool. A warrior that cannot win but reliably survives still scores points. We will come back to that.

An opponent

For anything to happen, somebody has to strike. The classic opponent is the dwarf, also by Dewdney:

;redcode-94nop
;name Dwarf
;author A. K. Dewdney

step    EQU     4

start   ADD.AB  #step, $bomb
        MOV.I   $bomb, @bomb
        JMP.A   $start
bomb    DAT.F   #0, #0

        END     start

Four lines, and an entirely different idea. The dwarf does not travel. It stands still and throws bombs:

• ADD.AB #step, $bomb — adds 4 to the pointer held in the last line. The target therefore moves four cells further on each pass.
• MOV.I $bomb, @bomb — copies the DAT instruction from the last line to wherever the pointer currently points. That is the bomb throw.
• JMP.A $start — back to the beginning. Endless loop.
• DAT.F #0, #0 — the bomb itself. An instruction that kills whoever runs onto it.

So the dwarf sows DAT instructions every four cells across the entire core. It does not know where the opponent is. It does not need to — it simply keeps scattering until the other one steps on a mine.

Why four and not one? Because at step size 4 the dwarf covers the core four times faster. Warriors are almost always longer than four cells, so it still hits them. A pattern you will meet again and again in Core War: you trade thoroughness for speed — right up to the point where you would start missing the opponent.

That 4 happens to be the best choice can be measured. The series is at the end of this page — with a surprising side finding.

The first duel

Imp versus dwarf, 2000 rounds:

The imp wins not once.

That is not a fluke and not a question of tuning. It is structural, and the reason is as simple as it is instructive: the imp writes nothing but MOV instructions into the core. MOV is a perfectly ordinary, executable instruction — running onto it does not kill you, it just executes. The imp has no way whatsoever to kill anything.

It can survive. It cannot win.

The dwarf, by contrast, wins just under a quarter of the time. In the other three quarters the imp simply keeps running until time expires — the dwarf does eventually hit the cell the imp is standing on, but the imp has usually long since moved on.

Why 2000 rounds and not 200?

Because the load positions are randomised for every round, and the result depends on them. Ten runs of 200 rounds each gave the dwarf between 42 and 51 wins — depending on how the dice fell. That is 21 to 25.5 per cent, a swing of four and a half percentage points from chance alone.

At 2000 rounds, three runs landed within 0.7 percentage points of each other.

Remember this for later: a single short measurement run tells you very little in Core War. Anyone comparing two warriors over 200 rounds and seeing a three-point difference has probably measured nothing but the weather. Step 4 of this path goes into that in detail.

The points

Wins and ties turn into a score. The usual formula:

Score = (wins × 3 + ties) × 100 / rounds

For our duel that gives:

• Dwarf: (471 × 3 + 1529) × 100 / 2000 = 147.1
• Imp: (0 × 3 + 1529) × 100 / 2000 = 76.5

So the dwarf sits at roughly double. But look at where the imp's points come from: entirely from ties. A warrior that never wins is still not at zero.

That calculation is exactly why Core War has such depth. There is no single best strategy but several that counter each other — and surviving is one of them.

Try it yourself

All you need is a simulator. The classic one is pMARS, available for Windows, Linux and macOS. Save the two warriors as imp.red and dwarf.red and run:

pmars -s 8000 -c 80000 -p 8000 -l 100 -d 100 -r 2000 imp.red dwarf.red

The parameters are the standard rule set: 8000 cells, 80,000 cycles per round, at most 8000 processes, warriors up to 100 cells long, minimum load distance 100, 2000 rounds.

Your numbers will not match the ones above exactly — load positions are random. They should be close, though: roughly a quarter wins for the dwarf, the rest ties, zero wins for the imp. The zero is the only figure that must match exactly; it is structural.

Then try setting step EQU 4 in the dwarf to other values. Measured over 2000 rounds against the imp:

Two things about this are remarkable.

Dewdney's 4 really is the best choice. Not approximately — clearly. Whoever arrived at that value back then, without a simulator and without measurement series, had good instincts.

At step size 6 the dwarf suddenly loses 656 times — against an opponent that cannot kill it at all. So it kills itself. The reason lies in the ring structure: the bomb pointer travels in steps of six through 8000 cells and eventually passes its own MOV line — which it then overwrites with a bomb. At step size 4 that cannot happen: of its own four cells the pointer only ever hits the bomb itself, and copying the bomb onto itself has no effect.

Remember that effect. A warrior killing itself through its own construction is not a curiosity in Core War but one of the most common mistakes there is — and one you will not notice without measuring.

What you now know

• The core is a ring of 8000 cells, filled throughout with lethal DAT instructions.
• A warrior dies when it runs onto a DAT — not from being "hit".
• The imp survives by moving and cannot win.
• The dwarf wins by blindly bombing the entire memory.
• Ties earn points. Surviving is a strategy.
• A single changed constant can make a warrior destroy itself. Measuring beats reasoning.

In the next step we look at Redcode more closely: which instructions exist, what the suffixes like .I and .AB mean — and why that suffix matters more than the instruction in front of it.

Imp and dwarf are by A. K. Dewdney and were published in Scientific American in 1984. All figures on this page were computed with pMARS under the standard '94nop rule set over 2000 rounds each.

← Core War overview