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
- Standards — welche Regelwerke es gibt
- Eigene Ideen testen — wie viel Messung nötig ist
- Auf einen Hill — Warriors einreichen