Über dieses Projekt

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

Dieses Nachschlagewerk ist ein Nebenprodukt. Entstanden ist es beim Versuch, Core War ernsthaft zu spielen — mit Hilfe von KI, und mit dem Anspruch, jede Behauptung nachzumessen.

Diese Seite erklärt, woher die Zahlen kommen, was funktioniert hat und was nicht. Vor allem das Letzte, denn davon gibt es in der Szene zu wenig zu lesen.

Der Verlauf in Kürze

März 2026 — Rang 654. Der erste Ansatz war ein klassisches Evolutionssystem: Populationen von Warriors, Mutation, Selektion über Turniere. Die erste Einreichung auf dem historischen 94nop-Königstuhl landete auf Rang 654 von damals gut 1100.

Juli 2026 — Rang 1. Nach einem vollständigen Neustart mit anderem Ansatz standen auf allen drei Wertungen desselben Hills unsere Warriors an der Spitze.

Wie das im Einzelnen lief, steht in einem eigenen Artikel:

→ Drei Kronen auf dem Königstuhl

Was mit KI funktioniert — und was nicht

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.

Was blinde Evolution nicht schafft. Der Rang 654 war lehrreich. In einem vierzig Jahre alten, hochoptimierten Ökosystem findet zufällige Mutation keinen Anschluss — die Lücke zwischen „läuft" und „konkurrenzfähig" ist zu groß, um sie zufällig zu überspringen. Mehr Rechenzeit hätte daran nichts geändert.

Was geholfen hat, war etwas anderes: bewährte Architekturen zu verstehen, Instruktion für Instruktion nachzuvollziehen und mit eigenen Parametern neu aufzubauen. Der Durchbruch kam, als wir aufhörten, Warriors zu züchten, und anfingen, sie zu analysieren.

Wo KI tatsächlich stark ist:

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

Wo sie nicht hilft: beim Finden guter Konstanten. Dafür sind Zahlenwerkzeuge und Messungen zuständig, nicht Sprachverständnis. Kein Modell „weiß", dass Schrittweite 2667 besser ist als 2000 — das rechnet man aus oder misst es.

Die ehrliche Bilanz: Der Fortschritt kam nicht daher, dass ein Modell bessere Warriors geschrieben hätte. Er kam daher, dass die Messinfrastruktur entstand, mit der sich Fragen beantworten ließen, die vorher niemand gestellt hatte.

Was dabei gebaut wurde

rmars — ein Neubau des Simulators pMARS 0.9.6 in Rust, ergebnisidentisch zum Original und gegen einen eingefrorenen Testkorpus verifiziert. Der Grund für den Neubau war nicht Unzufriedenheit mit pMARS, sondern Messbarkeit: Die Engine hat Kanäle, die es sonst nirgends gibt — Heatmaps, Kill-Attribution, Speicher-Schnappschüsse und vollständige Einzelrunden-Traces.

Der erzählte Kampf auf diesen Seiten ist damit aufgezeichnet. Dass sich sagen lässt, welche Zelle in welchem Schritt von wem geschrieben wurde und wann sie zuschlägt, ist keine Selbstverständlichkeit.

Ein eigener Hill-Server, der drei Wertungen parallel rechnet, und ein Analyse-Werkzeugkasten, aus dem die Zahlen dieser Seiten stammen: die Klassen-Matrix aus 349.866 Paarungen, die Runden-Studie aus 1,17 Millionen Kämpfen, das Stil-Tagging von 1104 Warriors.

Woran wir gescheitert sind

Und jetzt der Teil, der uns am wichtigsten ist.

Wir halten drei Kronen — aber mit zwei verschiedenen Warriors. Arvon führt den Haupt-Hill an, Kaitain die beiden anderen Wertungen. Die naheliegende Frage: Geht das auch mit einem?

Die Antwort ist nein, und der Weg dorthin war aufschlussreich genug, um ihn vollständig aufzuschreiben.

Der Grundkonflikt

Die beiden Warriors sind nicht zufällig verschieden, sondern gegensätzlich gebaut:

Anti-Paper verlangt Aggression — den Gegner finden und flächig wegräumen. Anti-Scanner verlangt Resilienz — sich ausbreiten und Treffer verkraften. Über alle unsere Warriors hinweg sind diese beiden Fähigkeiten anti-korreliert. Man bewegt sich entlang dieser Grenze, nicht darüber.

Vier Anläufe, alle negativ

Konstanten-Tuning, Imp-Patches, ein zweiter Angriffsmodus, und schließlich der naheliegendste Versuch: beide Körper in einen Warrior booten und parallel laufen lassen. Alle netto ≤ 0.

Der Ko-Boot scheitert strukturell, nicht an der Ausführung: Ein core-weites Clear beschädigt zwangsläufig einen core-weiten Silk. Die beiden können nicht koexistieren, weil sie denselben Speicher gegensätzlich benutzen.

Die einzig verbliebene Architektur

Wenn beide nicht gleichzeitig laufen können, dann eben nacheinander: früh im Kampf den Gegner klassifizieren und dann auf Clear oder Silk festlegen, nie auf beides.

Wir haben ausgerechnet, was das brächte, wenn die Klassifikation perfekt wäre — also mit einem allwissenden Orakel statt eines echten Detektors:

+14,6 Punkte über den bisherigen Spitzenreiter. Und der Detektor müsste dafür nicht einmal gut sein — schon bei rund 60 % Trefferquote wäre die Sache gewonnen.

Die Decke ist also riesig. Trotzdem funktioniert es nicht.

Warum es scheitert

Der Reihe nach ausgeschlossen: Es liegt nicht an der Decke (die ist gewaltig). Nicht an der Umschaltung (die ließ sich interferenzfrei bauen). Nicht an den Kosten des Chassis (rund 5 Punkte, vom Gewinn locker gedeckt). Nicht an der Mehrdeutigkeit der Opcodes (das ließ sich sauber trennen).

Es liegt an Lokalität und Latenz des Beobachtens.

Ein Detektor muss Zellen des Gegners finden, um ihn zu klassifizieren. Früh im Kampf ist der Gegner aber räumlich winzig und der Core riesig — der Detektor müsste hunderte Zellen sequentiell abtasten. Als Einzelprozess. Und genau in dieser Zeit tötet ihn ein Scanner, der nichts anderes tut als zu suchen.

Wir haben sieben Redcode-Varianten gebaut. Sie fanden zwischen 30 und 112 belegte Zellen, bevor sie starben — zu wenig für eine belastbare Entscheidung. Auch ein verteilter Detektorschwarm, der die Latenz umgehen sollte, half nicht: Passive Beobachter werden weggebombt, aktive teilen sich die Rechenzeit mit dem Hauptkörper und verschlechtern die Latenz.

Zwei Hörner, zwischen denen kein Weg hindurchführt: Entscheidung zuerst bedeutet Tod durch Latenz. Silk zuerst mit Detektor im Hintergrund bedeutet Interferenz.

Was das heißt

Innerhalb des Regelwerks ist der Ein-Warrior-Spagat durch einen fundamentalen Zielkonflikt blockiert: Beobachten und Überleben verlangen dieselbe knappe Ressource, nämlich die frühen Zyklen. Wer schaut, läuft nicht. Wer läuft, schaut nicht.

Wir halten das für ein echtes Ergebnis und nicht für ein Versäumnis. Es ist vollständig dokumentiert, inklusive aller Sackgassen und Messreihen — falls jemand einen Weg sieht, den wir übersehen haben, würden wir das gern erfahren.

Warum wir Negatives veröffentlichen

In der Core-War-Szene wird viel Wissen weitergegeben und wenig davon nachgerechnet. Das ist verständlich — Messungen dieser Größenordnung waren lange nicht praktikabel. Die Folge ist, dass manche Regel überlebt hat, obwohl das Feld sich unter ihr weggedreht hat. Das Schere-Stein-Papier ist das beste Beispiel.

Uns geht es genauso, nur in die andere Richtung: Wir haben Messwerkzeuge und Rechenzeit, aber keine dreißig Jahre Erfahrung. Deshalb schreiben wir auf, was wir gemessen haben — auch und gerade dort, wo es gegen unsere eigenen Annahmen ausgeht.

Diese Seiten enthalten mehrere Stellen, an denen wir uns geirrt haben und die Korrektur stehen geblieben ist. Das ist Absicht.

Mitarbeit und Rückmeldung

Wenn du einen Fehler findest, eine Zahl anders misst oder eine der hier beschriebenen Sackgassen für begehbar hältst: Wir hören gern davon. Kontakt über das Impressum.

Alle Beispiel-Warriors, die auf diesen Seiten mitgeliefert werden, sind entweder Allgemeingut der Szene oder eigene Arbeit und frei verwendbar. Fremde Warriors werden hier beschrieben und verlinkt, nicht mitgeliefert — Näheres auf der Attributions-Seite.

Verwandte Seiten

• Drei Kronen auf dem Königstuhl — der Projektbericht
• Werkzeuge und Engines — womit gearbeitet wird
• Die Strategieklassen — die gemessenen Kräfteverhältnisse

← Core-War-Übersicht