ZOREWARS

ZoreWars › History

How Core War warriors evolved

Forty years of strategy, traced through the authors' own posts, warrior sources and the Core Warrior newsletter. What each family of warriors learned, and what you can use today.

This page summarizes; it does not replace the originals. Every claim links to its primary source in the archives where it belongs. Please read, credit and cite those authors. Our own research notes, with hashes of every source we reviewed, are in the repository's docs/ folder.

Origins

Core War was introduced to the public by A. K. Dewdney in his Computer Recreations column in Scientific American, May 1984, based on a game he had devised with D. G. Jones. The column already described the three basic ideas: programs that bomb, programs that copy themselves, and programs that move. A detailed history of the game is kept at corewar.co.uk.

The International Core War Society standardised Redcode in 1986 and 1988, and a 1994 draft (ICWS'94) added modifiers, new addressing modes and new instructions. That draft, as implemented by the pMARS simulator, is what the public hills and ZoreWars use. From the early 1990s, the King of the Hill servers ran standing tournaments, and players explained their warriors on rec.games.corewar and in the '94 Warrior and Core Warrior newsletters, now archived at corewar.info.

Dated milestones

DateWhat the sources show
May 1984Dewdney introduces Core War: bombing, copying and moving programs. Article record.
1986; 1990The archive places MICE (a replicator) in 1986. Stone and Scissors name the 1990 tournament in their own headers.
14 Oct 1992Anders Ivner's original post explains imp spirals, layered imps, launch vulnerability and why they produce ties.
10 Aug 1994Juha Pohjalainen posts Silk Warrior 1.3, with notes on distribution and self-testing.
30 Nov 1994The '94 Warrior #14 discusses quickscans with '88 and '94 prototypes and scan coverage.
Aug–Sep 1995The archive associates a P-space demo with pMARS 0.8.0. myVamp v3.7's author gives 30 September 1995 as its submission date.
8 Jul 1996Ivner explains Q² in Core Warrior #37.
1999Core Warrior #73 presents Q³ by Humberto and Metcalf; #75 a compact form.
8 Dec 2002Core Warrior #84 tests quickscan correctness with every placement against a stationary target.
Apr 2004Fatamorgana X: a persistent controller choosing between several attacks.
TodayHill leaders such as Arvon and pst_v4 credit earlier components in their sources and refine them.

How we date things

Warrior history is easy to get wrong, so we separate four kinds of evidence:

For example, Agony II appears in the 31 October 1994 hill report, and Torch t8 in August 1994, while the archived Torch t18 is dated 1996. Both are true once the age of a family and the date of a version are kept apart.

Stones and bombers: from a stride to a lifecycle

The archived Dwarf is a tiny stride and a DAT bomb. Torch t18 combines incendiary bombing, a clear, a boot and decoys; its author notes that this version restores the boot and decoy and uses a zero test in the bombing stage. Tornado 3.0 instead changes the clear and replaces the boot with a decoy maker. These are alternatives, not a ladder where each addition wins.

Thermite II is a confirmed relationship: its source includes the Brand 3.3 body, credits Torch, and describes changes to its scan, anti-paper settings and launcher. Opening, body and endgame were tuned together.

Lesson: treat placement, stride, bombing duration, trigger and fallback as separate choices that must be safe together. Measure when the first bomb lands and when the fallback begins, not just whether the warrior survives. Check the stride against the actual core size.

Scanners, quickscans and one-shots: buy information, then use it

Scissors already combines a scan with an attack loop. Iron Gate uses comparisons, SPL/JMP bombing and pointer arithmetic. Blur 2 lays an SPL carpet before a DAT/DJN endgame. Frontwards v2 is a one-shot two-pass design whose author documents the arithmetic that keeps its scan, decrement stream and decoy from damaging each other.

Quickscans spend a different budget: many probes at the start of the round, compact decoding of a hit, a short targeted attack, then a backup warrior. Q², Q³ and compact Q³ differ mainly in how a hit selects and computes its target. Their decoder constants are part of the probe geometry, not free numbers.

Lesson: test each probe with an injected target and confirm the right cell is attacked, with the backup switched off, as Core Warrior #84 does. Then switch the backup on and check whether the information pays for its startup time and size.

Clears and gates: the handoff is the innovation

A clear is more than a MOV loop. Frontwards' two-pass setup, Blur's carpet-then-DAT transition and Torch's clear and gate placement are different endgames with different handoffs. A later Core Warrior #89 discussion distinguishes switching a scanner into a clear from keeping the scan running while changing to DAT attacks.

Lesson: decide where the clear starts, what it spares, who owns its counters, whether it returns, and whether it defeats an imp or only delays it. A clear that is correct on its own can still start too late to matter.

Papers and silk: replication is scheduling

MICE copies its body, launches the copy and moves on. Silk Warrior's version notes discuss distribution and self-testing. TimeScape describes cooperating replication cells and the processes needed to sustain them. Copying became a schedule of which process copies, launches and attacks, and when.

Modern sources make the lineage explicit: Arvon credits Azathoth's decoding and body and its author's pst line; pst_v4 credits Azathoth's launcher, stone and paper and Eternal Exile's quickscanner. They are related variants with a reused body and a new front end.

Lesson: get the launcher and the paper working as one unit before varying either. Track where parent and child start, copy direction, queue order and how much is copied, including blank cells beyond the visible code.

Imps and launchers: arithmetic, not tuning

Ivner's 1992 post derives the step of a three-point imp and a layered version, and records their weak points: vulnerable launches and little winning power against fast process growth. Cannonade pairs a stone with gate-breaking imp spirals. Freight Train later uses a seven-point imp, two continuous launchers, a stone and an optional quickscan.

Lesson: derive the step from the number of points and the core size; don't tune it by trial. Launch order, timing and process budget belong to the design. Score wins as well as survival, or you'll build a tie machine.

Vampires: capture needs a pit and an endgame

PIPER is an early example, though its archive metadata says the 1987 or 1988 tournament and gives no reliable author. myVamp v3.7, submitted in September 1995, combines jump bombing, opportunistic scanning and a multi-phase clear. The August 1994 hill report links vampires' losses to stronger replicators and easy anti-vampire measures, a change in the field rather than proof that vampires stopped working.

Lesson: the fang and the pit are one mechanism. Check that a fang dropped anywhere still points into the pit, and tell captured processes apart from killed ones.

P-space switchers: a portfolio, not an attack

P-space is memory that survives between the rounds of a match; the pMARS manual documents it. Fire and Ice II chooses between a stone with a fallback clear and an anti-imp scanner. Fire and Brimstone says in its source that it replaces the scanner with Kenshin. Fatamorgana X packages several attacks with a larger selector.

Lesson: build and test each attack without P-space first, then add a small controller and test first rounds, wins, losses, ties and corrupted state. Removing the controller may not remove every P-space instruction: Fire and Ice's scanner drops an STP bomb.

Limited processes: scarcity changes the design

On the limited-process hill, leaders such as R.O.U.S. (a compact bombing paper), Replinator (quickscan and paper) and Bronze minotaur (separated papers) solve the same problem in different ways. Their similarities are a family comparison, not a proven line of descent.

Lesson: a normal silk launcher with different constants is not an LP warrior. Watch the peak queue size, which children actually start, and how the second generation copies.

The common thread

Across every family, the strongest recurring change is better cooperation between parts. Launchers place attacks safely, process schedules sustain replication, scanners hand useful pointers to attacks, and a damaged or exhausted attack turns into a suitable endgame. New instructions mattered less than the interfaces between pieces. That is also why ZoreWars' evolve works with whole, tested components rather than splicing random instructions.

Our plane and volume modes are a ZoreWars extension, not part of this history. Lessons from the ring don't automatically carry over to them.

Where to go next

Corrections

If a date, credit or lineage here is wrong, please open an issue with a source. We keep uncertain dates marked as uncertain rather than guessing, and we'd rather link to an author's own words than paraphrase them.

Last reviewed 28 October 2026. Original warriors and posts remain the work of their authors and are linked, not copied.