Core War: programs that fight inside memory

In Core War the players never touch the game. Every player writes a small program, a warrior, in an assembly language called Redcode, and both warriors get loaded into the same circular block of memory, the core, where they take turns executing instructions. Warriors lose when all of their processes have died by executing DAT instructions. There’s no screen and no input, just two programs trying to overwrite each other’s memory.

Below is a full ICWS'94 simulator (a MARS, Memory Array Redcode Simulator) that I wrote for this page. It runs with the standard “94nop” hill settings, which means an 8000-cell core, up to 8000 processes per warrior and a tie after 80,000 cycles.

How to read the arena

#

Squares are memory cells, numbered left to right and top to bottom, and since the last cell sits next to the first, the core has no edges.

• Colour tells you which warrior wrote to a cell last. Bright means recent and fades with age, and cells holding a DAT are darker, so you can tell bombs from live code at a glance.
• White dots are processes, the program counters waiting to run.
• White flashes mark the instructions that just ran.
• Hover over a cell, or tap it on a phone, to see which instruction it holds.
• Show code opens the instructions around every warrior’s last executed line, with a one-sentence description of that line and arrows on the core for where it wrote, jumped or split. It’s easiest to follow at low speed or with Step (keyboard: →, and Space to pause).
• Finish plays the current battle to the end at once. Tournament plays every warrior against every other one in a background thread and scores them the way King-of-the-Hill servers did, 3 points for a win and 1 for a tie.
• Edit warriors lets you change a warrior, or paste in your own, and send it straight into battle.

A short history

#

1961, Darwin. Core War goes back to Darwin, a game that Victor Vyssotsky, Robert Morris and Doug McIlroy wrote at Bell Labs for the IBM 7090, in which programs tried to find and destroy each other in memory.

1984, the article. D. G. Jones and A. K. Dewdney published the Core War Guidelines in March 1984, and in May Dewdney’s Computer Recreations column in Scientific American introduced the game to the public under the title “In the game called Core War hostile programs engage in a battle of bits”. The name comes from core memory, the magnetic-core RAM of older computers, and that article also had the first two famous warriors, Imp and Dwarf.

1986, the first tournament. The International Core War Society (ICWS) was founded in 1985, and 1986 brought both the first standard, ICWS'86, and the first tournament. Mice, a self-copying program by Chip Wendell, won it.

1988 and 1994, the standards. ICWS'88 fixed the instruction set for years. The 1994 draft added instruction modifiers (.A, .B, .AB, .F, .I…), new addressing modes and new opcodes, and although nobody ever formally ratified it, it became the de facto standard, which is also what this page implements.

1990s, the Usenet era. The newsgroup rec.games.corewar and the automatic King of the Hill servers turned Core War into a competition that never stopped. You mailed your warrior to a hill, it had to fight every warrior already there, and it got to stay only if it scored high enough. The reference simulator pMARS comes from that time, and so do the classic strategies people refined on those hills: imp spirals, paper (Silk), quick-scanners and core clears. A few hills still run, and corewar.co.uk collects history and warriors.

Redcode in two minutes

#

There’s a visual guide to the language, with a step-by-step debugger, in Redcode, instruction by instruction.

Every cell holds one instruction made of an opcode, a modifier and two operands, A and B, and each operand has an addressing mode and a number. All addresses are relative, so 1 is the next cell and -1 the previous one, and a program has no way to know where it sits in the core.

Warriors 1 and 2 alternate, an instruction at a time. Having many processes doesn’t buy a warrior more CPU time, because every turn goes to the next process in that warrior’s queue, so SPL makes a warrior harder to kill and slower at the same time.

The warriors

#

Core War strategies form a rock-paper-scissors triangle: stones (bombers) tend to beat scissors (scanners), scanners beat paper (replicators), and paper beats stones. Imps are a fourth element that’s hard to kill, rarely kills anything and mostly forces a tie. The simple warriors here follow the triangle only roughly, so run the tournament to see where they break it.

Imp

#

imp     MOV.I   0, 1

A single instruction that copies this cell to the next. The process moves on and finds the same instruction waiting there, so the Imp crawls through the core one cell per turn and leaves a trail of copies behind. It’s almost impossible to kill, since a bomb has to land exactly on the cell the Imp is about to execute, but it almost never wins either. When an imp reaches enemy code it turns that code into imps, the enemy keeps running, and the battle ends in a tie.

Dwarf, a stone

#

dwarf   ADD.AB  #4, bomb
        MOV.I   bomb, @bomb
        JMP     dwarf
bomb    DAT     #0, #0

The Dwarf was the first real bomber. Every loop adds 4 to the B-field of bomb and copies that DAT to the address the B-field points to (@bomb). With 8000 divisible by 4 the bombs land on every fourth cell, and the only part of the Dwarf they can hit is bomb itself, where a DAT over a DAT does no harm. Sooner or later any enemy longer than 3 instructions gets hit, and whichever process steps on a bomb dies.

Mice, a replicator

#

Mice copies its 8 instructions to a new place (MOV @ptr, <dest in a DJN loop), starts the copy with SPL @dest and moves the target 653 cells further, and every copy does the same. Within a few thousand cycles the core is full of mice, far too many for a bomber to kill them all. This is the strategy that won the first tournament.

Imp Spiral

#

Three imps placed 2667 cells apart. Since 3 × 2667 = 8001, the third imp writes to the cell right after the first one. The processes move in lock-step, with every imp rewriting whatever cell the next imp is about to execute, so single DAT bombs can’t stop the spiral, because the next imp just repairs the damage. The launcher uses SPL to create several processes at every point, which lets the spiral survive losing a few of them too.

Paper (Silk-style)

#

Paper is the modern version of Mice. Three SPL 1 instructions create 8 processes, and all 8 run SPL 3620 and then MOV >-1, }-1. Each process copies only one line, because the post-increment modes advance both pointers, and the new copy starts running before it’s even finished, which is why paper spreads so fast. Once the copying is done, the old processes stay behind in a bombing loop. To kill paper you have to kill every copy, and there can be hundreds of them.

Scanner, scissors

#

scan    ADD.AB  #7, ptr
ptr     JMZ.F   scan, trap+7

Scanners look for targets instead of bombing blindly. This one checks every 7th cell and skips the empty ones (JMZ.F jumps back while both fields are zero), and when it finds something it plants a SPL #0 trap there. Processes that step on that trap just create more stuck processes, until the enemy slows almost to a stop. After a full lap around the core, the scanner kills everything that got stuck with a DAT core clear. Scanners are deadly against large, slow targets like paper, while bombers are small and hard to find.

Vampire

#

The Vampire is a bomber with a twist. Instead of DAT it throws fangs, JMP instructions whose offsets always point back into the Vampire’s own pit. ADD.F changes both fields of a fang at once, so wherever a fang lands, the pit stays its target. Enemy processes that execute a fang jump into the pit and become prisoners. Prisoners run a two-line loop, MOV kill, <pit-10 and SPL -1, which clears the core backwards with DAT while their number stays constant, and when the clear has gone all the way around and erases the SPL, every prisoner dies. With a step that’s a multiple of 4, a fang can land only on the fang itself or on kill, and the pit keeps working. That makes the Vampire as regular as the Dwarf, but against the Dwarf it’s the bigger target, and the tournament shows what that costs.

Write your own

#

Open Edit warriors, change a number and press Load & fight. A few things to try:

• Change the Dwarf’s step from #4 to #3. It will eventually bomb itself. Why?
• Give the Imp a partner: put SPL 1 before it.
• Change step in the Scanner and see how the tournament ranking changes.

The parser understands labels, EQU, ORG/END, arithmetic in operands and the ;name / ;author / ;strategy comments. Write modifiers explicitly, as in the examples above, because if you leave one out the ICWS'94 default applies.