Referenz
2026-07-18 · Lesezeit ~5 min

Werkzeuge und Engines

KI-Hinweis: Dieser Text entsteht mit Unterstützung von KI-Systemen, wird aber vor der Veröffentlichung redaktionell geprüft und verantwortet.

Einen Warrior schreibt man in einem Texteditor. Alles danach — ausprobieren, messen, Konstanten finden, gegen ein Feld antreten lassen — braucht Werkzeuge. Diese Seite zeigt, welche es gibt und wofür sie taugen.

Die Auswahl ist kein Ranking. Was du brauchst, hängt davon ab, wie weit du gehen willst.

Simulatoren

Ein Simulator — in der Szene MARS genannt, nach Memory Array Redcode Simulator — übersetzt deinen Warrior und lässt ihn kämpfen. Ohne einen kommst du keinen Schritt weit.

pMARS — die Referenz

Der portable MARS, geschrieben in C von Albert Ma, Nándor Sieben, Stefan Strack und Mintardjo Wangsaw, heute von John Metcalf gepflegt. Er gilt als der offizielle Redcode-Simulator der Szene, und im Zweifel ist sein Verhalten die maßgebliche Auslegung des Standards.

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

Nützliche Schalter über die Kampfparameter hinaus:

Schalter Wirkung
-A nur übersetzen, nicht kämpfen — der schnellste Syntaxtest
-b knappe Ausgabe ohne Quelltextauflistung
-e Debugger betreten
-f feste Positionsserie — macht Läufe reproduzierbar
-F <pos> feste Ladeposition des zweiten Warriors
-P Startpositionen permutieren
-8 ICWS'88-Regeln erzwingen

Der Debugger (-e) ist unterschätzt. Wer nicht versteht, warum ein Warrior stirbt, kommt damit deutlich schneller weiter als durch Nachdenken über den Quelltext.

Weitere Simulatoren

Name Autor Besonderheit
CoreWin Windows-Oberfläche, '88 und '94, P-Space, Lese-/Schreibgrenzen
A.R.E.S. Martin Ankerl Windows, CWS'94, experimenteller BlueCode-Modus
corewar.online läuft im Browser, keine Installation nötig
exMARS Martin Ankerl auf Geschwindigkeit ausgelegt
fmars Michał Janeczek sehr schnell, aber ohne P-Space
PyCorewar Jens Gutzeit Python-Anbindung, gut für eigene Auswertungen

Für den Anfang reicht pMARS oder ein Simulator im Browser. Die schnellen Varianten werden erst interessant, wenn du Hunderte von Varianten gegen ein großes Feld messen willst.

Ein Hinweis zur Geschwindigkeit: Schnellere Engines erkaufen ihr Tempo manchmal mit Auslassungen. fmars etwa verzichtet auf P-Space und ist damit für Hill-Wertungen nicht verwendbar. Wenn eine Engine als Schiedsrichter dienen soll, zählt Übereinstimmung mit pMARS mehr als Tempo.

Zahlenwerkzeuge

Eine Eigenheit von Core War: Ein erheblicher Teil der Arbeit besteht darin, gute Zahlen zu finden. Schrittweiten für Bomber, Abstände für Scanner, Sprungweiten für Imp-Spiralen — all das folgt zahlentheoretischen Gesetzmäßigkeiten, und dafür gibt es eigene Programme.

Werkzeug Autor Zweck
Optima Nándor Sieben klassischer Optima-Schritt-Algorithmus
Corestep Jay Han findet Optima-Schritte ohne Simulation
Mopt Stefan Strack mehrere Schrittweiten mit begrenzter Lückengröße
Makeimp Jay Han erzeugt Imp-Spiralen
IMPSTEP Imp-Schritte über den erweiterten euklidischen Algorithmus

Warum das nötig ist, zeigt schon der Dwarf aus dem Lernpfad: Seine Schrittweite entscheidet darüber, wie gleichmäßig er den Core abdeckt — und bei ungünstiger Wahl bombardiert er sich selbst. Das hängt am größten gemeinsamen Teiler von Schrittweite und Coregröße, und solche Fragen beantwortet man besser rechnerisch als durch Ausprobieren.

Optimierer

Ein Optimierer nimmt einen fertigen Warrior und sucht bessere Konstanten, ohne die Struktur zu ändern. Das ist erstaunlich wirksam: Zwei Warriors mit identischem Aufbau, aber unterschiedlichen Zahlen, können zwanzig Punkte auseinanderliegen.

Werkzeug Autor Ansatz
Optimax Sasha Zapf, Christian Schmidt mehrstufiger Optimierer in Perl
Simulated Annealing Optimizer John Metcalf schrittweise Änderungen mit probabilistischem Bergsteigen
Randy inversed erzeugt Kandidaten durch Randomisierung der Konstanten

Der Fallstrick beim Optimieren ist derselbe wie beim Messen überhaupt: Wer aus zwanzig Varianten die mit dem besten Messergebnis nimmt, hat nicht die beste Variante gefunden, sondern die mit dem größten Messglück. Ein Optimierer, der mit zu wenigen Runden arbeitet, produziert zuverlässig Scheinverbesserungen. Mehr dazu unter Eigene Ideen testen.

Turniere und Benchmarks

Um zu wissen, wo ein Warrior steht, lässt man ihn gegen ein Feld antreten statt gegen einen einzelnen Gegner.

Werkzeug Autor Zweck
MTS Stefan Strack Rundenturniere und Benchmarks
koth Philip Kendall Benchmark gegen ein Warrior-Feld
TestWarrior Phil Knight Benchmark einzelner Warriors
Corewar Tournament Phil Knight Rundenturniere mit 2 bis 4 Warriors je Kampf

Ein Benchmark braucht ein Feld. Übliche Quellen sind die öffentlichen Hill-Archive — dort steht, was sich tatsächlich bewährt hat. Wer gegen ein willkürlich zusammengestelltes Feld misst, misst etwas anderes als die Hills.

Evolver

Ein Evolver erzeugt Warriors nicht aus einer Idee, sondern durch Mutation und Selektion: Zufällige Programme kämpfen gegeneinander, die besseren überleben und werden variiert.

Das funktioniert — mit einer wichtigen Einschränkung. Evolvierte Warriors sind in engen Nischen stark, besonders auf kleinen Cores und bei kurzen Längenbegrenzungen. Auf dem großen '94nop-Hill, wo vier Jahrzehnte Handoptimierung im Feld stehen, findet blinde Evolution kaum Anschluss.

Das ist keine Theorie, sondern unsere eigene Erfahrung: Der erste Anlauf dieses Projekts war ein klassisches Evolutionssystem. Die erste Einreichung landete auf Rang 654. Was danach half, war nicht mehr Rechenzeit, sondern das Verstehen und Nachbauen bewährter Architekturen.

KI-gestützte Entwicklung

Große Sprachmodelle können Redcode lesen, schreiben und erklären. Als Werkzeug reihen sie sich neben Optimierer und Evolver ein — mit einem eigenen Profil aus Stärken und Schwächen.

Wobei sie tatsächlich helfen:

  • fremde Warriors entschlüsseln und in verständliche Beschreibungen übersetzen
  • Analyse- und Messwerkzeuge bauen, statt Warriors direkt zu schreiben
  • große Messreihen auswerten und Muster darin finden
  • eine Architektur aus einer Beschreibung heraus neu aufbauen

Wobei sie nicht helfen: beim Erfinden guter Konstanten. Dafür sind Zahlenwerkzeuge und Messungen zuständig, nicht Sprachverständnis.

Die ehrliche Bilanz aus diesem Projekt: Der Fortschritt kam nicht daher, dass ein Modell bessere Warriors geschrieben hätte, sondern daher, dass es die Messinfrastruktur gebaut hat, mit der sich Fragen beantworten ließen — und dass es fremde Mechaniken Instruktion für Instruktion zerlegt hat, statt sie zu kopieren.

Wie bei jedem Werkzeug gilt: Was du einreichst, verantwortest du. Und was du von anderen übernommen hast, nennst du beim Namen.

Was wir selbst gebaut haben

Für dieses Projekt sind zwei Werkzeuge entstanden, die hier der Vollständigkeit halber stehen:

rmars ist ein Neubau des pMARS-Simulators in Rust — ergebnisidentisch zum Original, verifiziert gegen einen eingefrorenen Testkorpus. Er bringt eine Python-Anbindung mit und Messkanäle, die pMARS nicht hat: Heatmaps, Kill-Attribution, Speicher-Schnappschüsse und vollständige Einzelrunden-Traces. Gebaut wurde er nicht aus Unzufriedenheit mit pMARS, sondern weil sich Fragen stellten, die ohne solche Instrumentierung nicht zu beantworten waren.

pmars-fast ist ein nativer Build des originalen pMARS mit Batch-Modus — dieselbe Semantik, nur ohne den Prozessstart je Kampf.

Beide sind für die Analysen entstanden, auf denen Teile dieses Nachschlagewerks beruhen. Wenn Interesse besteht, machen wir sie zugänglich.

Verwandte Seiten


← Core-War-Übersicht