Tools and engines

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

You write a warrior in a text editor. Everything after that — trying it, measuring it, finding constants, running it against a field — needs tools. This page shows which exist and what they are good for.

The selection is not a ranking. What you need depends on how far you want to go.

Simulators

A simulator — called a MARS in this scene, for Memory Array Redcode Simulator — assembles your warrior and lets it fight. Without one you get nowhere.

pMARS — the reference

The portable MARS, written in C by Albert Ma, Nándor Sieben, Stefan Strack and Mintardjo Wangsaw, maintained today by John Metcalf. It is regarded as the scene's official Redcode simulator, and in case of doubt its behaviour is the authoritative reading of the standard.

pmars -s 8000 -c 80000 -p 8000 -l 100 -d 100 -r 200 warrior.red opponent.red

Useful switches beyond the battle parameters:

The debugger (-e) is underrated. If you cannot work out why a warrior dies, it will get you there considerably faster than reasoning about the source.

Other simulators

For a start, pMARS or a browser simulator is enough. The fast variants only become interesting once you want to measure hundreds of variants against a large field.

A note on speed: faster engines sometimes buy their pace with omissions. fmars, for instance, does without p-space and is therefore unusable for hill scoring. If an engine is to serve as a referee, agreement with pMARS matters more than speed.

Number tools

A peculiarity of Core War: a substantial part of the work consists of finding good numbers. Step sizes for bombers, distances for scanners, jump distances for imp spirals — all of it follows number-theoretic regularities, and there are dedicated programs for that.

Why this is necessary is already visible in the dwarf from the learning path: its step size determines how evenly it covers the core — and with a poor choice it bombs itself. That depends on the greatest common divisor of step size and core size, and such questions are better answered by calculation than by trial.

Optimisers

An optimiser takes a finished warrior and searches for better constants without changing the structure. That is remarkably effective: two warriors of identical construction but different numbers can be twenty points apart.

The pitfall when optimising is the same as with measuring in general: anyone picking the best measurement out of twenty variants has not found the best variant but the one with the most measurement luck. An optimiser working with too few rounds reliably produces phantom improvements. More on that under Testing your own ideas.

Tournaments and benchmarks

To learn where a warrior stands, you run it against a field rather than a single opponent.

A benchmark needs a field. The usual sources are the public hill archives — what stands there has proven itself. Measuring against an arbitrarily assembled field measures something other than the hills do.

Evolvers

An evolver produces warriors not from an idea but through mutation and selection: random programs fight, the better ones survive and are varied.

This works — with one important limitation. Evolved warriors are strong in narrow niches, particularly on small cores and with short length limits. On the large '94nop hill, where four decades of hand optimisation sit in the field, blind evolution barely gains a foothold.

That is not theory but our own experience: the first attempt at this project was a classic evolution system. The first submission landed at rank 654. What helped afterwards was not more computing time but understanding and rebuilding proven architectures.

AI-assisted development

Large language models can read, write and explain Redcode. As a tool they line up alongside optimisers and evolvers — with a profile of strengths and weaknesses of their own.

Where they genuinely help:

• decoding foreign warriors and translating them into comprehensible descriptions
• building analysis and measurement tools, rather than writing warriors directly
• evaluating large measurement series and finding patterns in them
• rebuilding an architecture from a description

Where they do not help: inventing good constants. That is the job of number tools and measurement, not of language understanding.

The honest balance from this project: progress did not come from a model writing better warriors. It came from the model building the measurement infrastructure that made questions answerable — and from taking foreign mechanics apart instruction by instruction rather than copying them.

As with any tool: what you submit, you are responsible for. And what you took from others, you name.

What we built ourselves

Two tools emerged for this project and are listed here for completeness:

rmars is a rebuild of the pMARS simulator in Rust — result-identical to the original, verified against a frozen test corpus. It carries Python bindings and measurement channels pMARS does not have: heatmaps, kill attribution, memory snapshots and complete single-round traces. It was built not out of dissatisfaction with pMARS but because questions arose that could not be answered without such instrumentation.

pmars-fast is a native build of the original pMARS with a batch mode — same semantics, just without the process start per battle.

Both exist for the analyses underlying parts of this reference. If there is interest, we will make them available.

Related pages

• Standards — which rule sets exist
• Testing your own ideas — how much measurement is needed
• Onto a hill — submitting warriors

← Core War overview