[This article is also available in English]

Zusammenfassung

Conflict Nexus ist ein Unterstützungsprogramm für Warmachine/Hordes in der Regeledition MK3. Es soll primär solchen Spielern helfen, welche die War Room 2 App vermissen. Die aktuelle Version ist eine Beta-Version.

Hier geht es direkt zu Conflict Nexus

Nachfolgend wird die Entstehung Conflict Nexus’ geschildert.

Was kann Conflict Nexus?

Conflict Nexus ist eine Webanwendung für Warmachine/Hordes MK3. Im Kern hat sich eine Listenbaufunktion „List Builder“ und eine „Go to War“-Funktion, um während eines Spiels Schaden zu vermerken, aber auch Statuseffekte zu vermerken.

Des Weiteren ist jedes Modell mit einem Link zum Warmachine University Archive ausgestattet, so dass die zahlreichen Tipps aus dem Wiki „nur einen Mausklick“ entfernt sind.

Hintergrund

In unserer Spielrunde war das Entsetzen groß, als MK4 erschien: Einige hatten gerade erst ihre Armee gekauft oder aufgestockt oder waren entsetzt, dass die mit Mühe angebrachte Front- und Back-Arc-Bemalung nun obsolet sein sollte. On top kam natürlich noch die ubiquitäre Rüge ob der neuen Bewegungsregeln von Einheiten. Ein anderer Spieler konnte mit seinen Figuren nicht nach MK4-Regeln aufstellen, was ihm zugesagt hätte.

Im Laufe der Zeit hat sich dies etwas gelegt – der ein oder andere spielt heute auch MK4, wenn auch überwiegend im „Unlimited“-Format. Ich selbst habe mir auch ein paar MK4-Figuren gekauft, die mir gut gefallen. Im Kern ist es aber so, dass die überwiegende Mehrheit lieber weiter MK3 spielen möchte – und so ist es auch.

Allerdings wird dies zunehmend schwerer: Mit dem neuen Google SDK wurde die Einstellung der War Room 2 app im darauffolgenden Sommer (Ende August 2024, wenn ich mich nicht täusche) angekündigt und die App aus den App Stores genommen. Auch wenn man ein (für Android-Geräte) eine apk-Datei hat, kann man die App nicht verwenden: Sie wird zwar installiert, startet auch, ist dann aber unmittelbar nicht nutzbar, weil auf einen Server zugegriffen werden soll, der nicht mehr existiert. Ich investierte doch einige Mühe, aber es gelang mir nicht, die App zufriedenstellend nutzen zu können.

Im Ergebnis nahm die Zahl der Mitspieler, die keine lauffähige War Room 2-Installation mehr hatten, immer weiter ab. Vor allem, wenn ein neues Mobiltelefon gekauft wurde, war dies die regelmäßige Folge.

Und ich wusste: Dieses Problem würde im Zeitablauf weiter zunehmen. Ich hatte War Room 2 seinerzeit auf drei Geräten. Das eine war ein Geschäftstelefon, dass ausgetauscht wurde. Das zweite ein Telefon, das mittlerweile kaum noch startet. Und das Dritte ist ein Tablet, dass bis heute funktioniert.

Kurzum: Seit rund zwei Jahren überlege ich, wie man einen Ersatz für War Room 2 schaffen könnte. Im Herbst 2024 begann ich mit der Umsetzung; richtig los ging es aber erst im Winter 2025/26.

Erste Grundlage: Conflict Chamber

Im Kern verfügt War Room 2 über zwei Funktionalitäten: Den Listenbau (Build an Army), natürlich unter Beachtung der Regeln hierfür und die Unterstützung währed des Spiels (v.a. Festhalten von Trefferpunkten). In beiden Fällen können aber die Daten und Fähigkeiten der Modelle nachgeschlagen werden.

Für das reine Zusammenstellen der Liste gab es einst die „Conflict Chamber“. Dieses browserbasierte Programm war im Internet erreichbar, wurde aber ca. 2021 offline genommen, da, so meine Lesart, der Betreiber über mangelnde Unterstützung aus der Community klagte.

Ich wusste, dass dieses Programm große Teile der ersten Funktionalität „Listenbau“ abbilden konnte, möglicherweise aber nicht die letzten Regeln beinhaltete. Ich startete daher eine Online-Recherche und machte so den damaligen Betreiber und Programmierer ausfindig. Ich nahm Kontakt auf und freundlicherweise wurde der alte Conflict Chamber Code auf mein Bitten hin online verfügbar gemacht.

Zweite Grundlage: Warmachine University

Ich hatte die Warmachine University bereits seit einiger Zeit als html-Dump heruntergeladen, so dass mir deren Daten vollständig, wenn auch unstrukturiert, zur Verfügung standen.

Ein Data-Scientist-Kollege war so freundlich, ein Skript zu schreiben, dass alle Daten aus der Warmachine University extrahiert. Das war im Sommer 2025; das Code-Schreiben durch KI steckte da noch mehr in den Kinderschuhen als heute.

Damit hatte ich jede Menge Modelldaten.

Es wurde mühevoll: Nachbearbeitung

Nur basierend auf diesen beiden Quellen war Conflict Nexus nicht möglich. Beide Quellen wiesen Fehler oder Lücken auf, die es zu füllen galt.

1. Uneinheitliche Datenstruktur

Vor allem die Struktur der Waffendaten ist höchst uneinheitlich. Es gibt:

a) Schöne Tabellen, wie hier beim Defiled Archon:

b) Fleißtext, wie hier bei den Satyxis Raiders:

Ein Skript greift die Daten daher oft nicht oder fehlerhaft. Selbst wenn man das Skript flexibler gestaltet – man muss davon ausgehen, dass rund jeder zweite Eintrag irgendwo fehlerhaft ist. Ich musste daher über 2.000 Waffeneinträge einzeln nachprüfen, was mehrere Spätschichten in Anspruch nahm.

2. Vermengung von Einheiten und Attachments

Das zweite Bild oben zeigt es schon – die Seite der Satyxis Raiders enthält nicht nur die Daten der Einheit, sondern auch die des Command Attachments „Sea Witch“. Für meine Zwecke benötigte ich die Daten aber getrennt. Daher wurden alle Attachments von mir gesondert auf Basis der Karten und mit Hilfe künstlicher Intelligenz eingelesen und ergänzt. Ergänzend wurden die Attachment spezifischen Informationen bei den Grundmodellen mit (oft Einheiten) Künstlicher Intelligenz identifiziert und dann gelöscht.

Dasselbe Problem tritt bei Dragonern auf, wo es eine berittene und eine unberittene Variante gibt oder bei Warcaster Units. Hierzu habe ich die Werte händisch zusammengetragen.

3. Schadensanzeigen (Matrix oder Spirale) bei Warjacks und Warbeasts

Die Warmachine University enthält nur die Gesamttrefferpunkte von Warjacks oder Warbeasts; für meinen Zweck benötigte ich aber die Aufteilung auf Spalten bzw. Zonen (rechts, links, Cortex…) für Warjacks und Spiralzweig und Aspekt (Mind, Spirit, Body) für Warbeasts. Auch hier wurde versucht, die Vorarbeit durch KI zu erledigen – eine Kontrolle war aber unumgänglich, da die KI, auch mit einem Vision-Tool, vor allem viel Tokens verbrauchte aber dennoch recht viele Fehler machte.

4. Animi

Die Animus der Warbeasts fehlten. Der Data Scientist hatte nicht gewusst, dass diese auch relevant sind und nur „Spells“ gesucht. Mit KI konnte ich aber ein Skript bauen, welches die Daten auslas.

5. Kleinigkeiten

Die Aliasse (Haley2…) waren oft nicht in der Warmachine University enthalten und mussten einzeln ergänzt werden. Die Regeln für die Objectives tippte ich einfach ab.

6. Listenbauregeln

Wie im Weiteren geschildert, ist die Code aus Conflict Chamber sehr gut – aber nicht fehlerfrei. Zum einen sind die Kosten nicht auf dem neuesten Stand, sondern müssen aus der Warmachine University importiert werden. Zum anderen sind bestimmte Regeln umständlich oder falsch abgebildet oder wurden falsch „eingelesen“ (siehe unten). Gerade das „Falscheinlesen“ musste umfassen korrigiert werden. Auch die Partisan-Regeln spielen für den Listenbau keine große Rolle und mussten in Teilen korrigiert und ergänzt werden. Im Ergebnis musste ich die Listenbauregeln für jedes Theme durchgehen, indem ich die Regeln mit der War Room 2 App abglich. Bei Unstimmigkeiten waren diese zwar oft, aber nicht immer, unmittelbar zu klären (auch die War Room 2 hat Fehler; z.B. ist Madelyn ein mögliches Mercanarie-Modell für Crucible – wird aber in War Room 2 nicht zugelassen). Es war wirklich sehr mühevoll.

7. Mehrfach Einträge von Modellen

Die Listenbauregeln Conflict Chambers’ kennen keine Unikate für Modelle. Dass z.B. der Toro sowohl in einer Crucible Guard- als auch in einer Mercanaries-Armee verwendet werden kann, wird dadurch gelöst, dass ein einfach mehrere Toro-Einträge gibt. Das war für Conflict Nexus nicht tauglich, da hier auf die Regeln z.B. des Toros hinterlegt sind – aber nur einmal, um mehrere identische Datensätze (und deren Bereinigung) zu vermeiden. Nemo4 war sogar dreimal vorhanden.

8. Texte

Die aus der Warmachine University importierten Texte waren aus für mich nicht nachvollziehbaren Gründen oft schlecht strukturiert oder es fehlten Leerzeichen. Dies konnte aber mit KI recht gut adressiert werden. Diese Texte werden auf Schlüsselwörter durchsucht und ggf. ein Vorteil wie „Pathfinder“ identifiziert und als Symbol eingetragen. Ich betrachte dies als für den Moment akzeptabel, bin mir aber bewusst, dass noch Fehler vorhanden sind.

Exkurs: Die technische Umsetzung („Tech-Stack“) Ich suchte zu Beginn einen Programmierer, der die Umsetzung übernimmt. Der erste, den ich fand hatte aber Schwierigkeiten mit dem Zugang zu Materie und bekam schließnach nach rund sechs Monaten Tätigkeit ein Kind, womit er auch nicht länger zur Verfügung stand. Nach einigen, auch nicht völlig erfolglosen, Anläufen, das neue Programm mit KI (ChatGPT Codex) selbst zu schreiben, fand ich schließlich einen zweiten Programmierer (einen Informatik-Doktoranden), dem das Ganze Freude machte und der die Umsetzung im Wesentlichen übernahm. Im Vergleich zu Conflict Chamber, dessen Quellcode weitgehend in TypeScript und PHP geschrieben war, wurde Conflict Nexus vollständig in TypeScript entwickelt. Der Code wurde durchweg neu geschrieben; Dateien Confict Chambers werden unverändert übernommen und nur bestimmte Informationen hieraus extrahiert, der alte Code selbst wird nicht als solcher verwendet. Alle externen Komponenten sind Open Source. Die Benutzeroberfläche ist mit React geschrieben und mit Vite entwickelt. React kann prompte Veränderungen für den Nutzer anzeigen, wenn zum Beispiel ein neues Modell ausgewählt wird. Vite war während der Entwicklung von Vorteil, da hier Änderungen schnell umsetzbar sind. In der lauffähigen Version erzeugt Vite die fertigen Dateien der Webanwendung. Die Gestaltung selbst erfolgt mit Tailwind CSS. TanStack Router und Query übernehmen die Aufgabe, dem Nutzer die gerade richtige Seite anzuzeigen und die richtigen Daten an die API (im Folgenden) zu übergeben. Hinter der Benutzeroberfläche ist eine Datenbank. Vorliegend ist dies eine PostgreSQL-Datenbank. Für Conflict Nexus war dieser Datenbanktyp unter anderem deshalb von Vorteil, weil er neben klassischen Tabellendaten auch strukturierte JSON-Daten (etwa die Schadensraster und Statuseffekte der Spielstände) nativ speichern kann und die Standard-DB für Prisma/Express-Stacks ist. Eine sog. API verarbeitet Eingaben des Nutzers (oder sonstige, die sich aus der Benutzeroberfläche ergeben) und fragt die Datenbank ab. Hierbei werden die Anfragen mit Zod validiert, das heißt, überprüft, ob die Anfragen überhaupt vollständig und in der richtigen Struktur sind. Zod passt gut zu TypeScript und daher zu dem Projekt. Damit für das API klar ist, welcher Nutzer gerade aktiv ist, werden kurzlebige Access-JWTs verwendet, die über serverseitig gespeicherte, jederzeit widerrufbare Refresh-Tokens erneuert werden können. Für den Datenbankzugriff verwendet die API Prisma (ein sog. ORM; Objektrationale Abbidung). Prisma ist praktisch für TypeScript entwickelt worden und war daher gut geeignet. Die Kombination aus Express, Prisma und PostgreSQL-Datenbank ist sehr geläufig und wurde daher auch hier verwendet. In der Datenbank werden die „fixen“ Daten wie Werte der Modelle gespeichert, aber auch benutzergenerierete Daten wie Armeelisten, Spielstände oder Benutzerkonten. Die Listenbauregeln für die Armeelisten sind in reinem TypeScript geschrieben, bilden aber nur ab, was beim Listenbau möglich ist (dass z.B. Cygnar-Listen einen Firefly enthalten dürfen). Hier fließen Teile des alten Conflict Chamber-Codes ein – allerdings im nächsten Schritt modifiziert. Die Modelldaten (Stat-Block, Zauber, Waffendaten…) sind aus den obenstehenden Quellen zusammengetragen. Es handelt sich also um eine Mischung aus händisch erstellten CSV-Dateien, und aus der Warmachine University extrahierten Dateien. Die Trennung von Spieldaten und Regel-Engine hat den Vorteil, dass dieselben Spielregeln sowohl im Browser als auch auf dem Server verwendet werden können und nur an einer Stelle gepflegt werden müssen. Hierbei werden alle diese Informationen mit langen Seed-Skripten in die Datenbank eingelesen, welche diese Informationen speichert. Während der Entwicklung wurden jedoch oft Regeln (z.B. für den Listenbau) in der falschen Reihenfolge aus zum Beispiel den Conflict Chamber-Dateien eingelesen. Dies musste mühevoll überprüft und korrigiert werden. Insgesamt ist der Datenfluss etwa der Folgende: CSV-Dateien → Seed-Skripte → PostgreSQL → Übersetzungsschicht → Listenbauregel-Engine → API und Benutzeroberfläche Wenn also eine Armeeliste erstellt wird passiert Folgendes: Es werden die Modelldaten aus der Datenbank geladen und an die Engine übergeben. Diese bestimmt, welche Modelle für die gewählte Fraktion im gewählten Theme (und ggf. mit den bereits gewählten Modellen) zulässig sind und welche Punktekosten zu beachten sind. Die Benutzeroberfläche zeigt dies dem Nutzer an. Die „Go-To-War“-Funktion ist deutlich einfacher: Hier wird die gebaute Liste angezeigt und nur Statusänderungen wie Trefferpunkteverluste in die Datenbank als „Spielstand“ zurückgespielt.

Aktueller Stand

Die nun zur Verfügung gestellte Version ist als „Beta-Version“ bezeichnet, da ich trotz, vieler Tests davon ausgehe, dass sich hier und dort noch ein Bug befindet. Vor allem das Auslesen der Modellwerte aus der Warmachine University dürfte hier und da noch Fehler mit sich bringen. Hier hoffe ich, dass Nutzer Conflict Nexus’ mir helfen, diese Fehler zu finden.

Darüber hinaus werden noch folgende Funktionalitäten ergänzt werden (vermutlich Spätsommer 2026):

1. Herunterladen von Listen, um diese zu teilen
2. Einsicht in die Karten und Zustände (Trefferpunkte etc.) des Opponenten
3. Ergänzen von Modellen, die während des Spieles erst enstehen, z.B. durch die „Opening the Gate“-Fähigkeit
4. Möglichkeit, Brawl Machine-Regeln auszuwählen
5. Unterstützung von Multi Caster-Listen bei „Blended Themes“ (Strange Bedfellows etc.) – dies ist momentan nicht möglich

Ich werde diesen Artikel bei Neuerungen ergänzen.

Dank

Dank gebührt Juckto für die Warmachine University und insbesondere David Bingham Brown, Ph.D für die Entwicklung Conflict Chambers sowie die Bereitstellung des Codes. Ohne dieses Tool wäre die Entwicklung Conflict Nexus’ deutlich schwieriger gewesen.

Zudem ist Cameron Simoleit zu danken, der die technische Umsetzung übernahm und auch das Projekt weiter begleitet.