Der Auswertungsprozess
Wie ein Spielzug in Promy2026 abläuft – Ablaufbeschreibung zur fachlichen Prüfung
Diese Unterlage beschreibt in Worten, was der Code des Auswertungsprozesses tatsächlich tut – vom Einlesen der Spielzüge über Umweltverluste, Bewegung, Kampf, Sichtbereich bis zur Berichts- und Kartenausgabe. Ziel ist, dass eine Person ohne Programmierkenntnisse die Korrektheit der Formeln und der Reihenfolge im Zug beurteilen kann.
Interne Bezeichner (Objekttypen, Speicheradressen, Funktionsnamen) werden im Fließtext nicht verwendet. Stattdessen stehen an relevanten Stellen kleine, grau hinterlegte Marken wie Quelle: Datei, Abschnitt am Rand des Textes – sie dienen ausschließlich dazu, im Fehlerfall die passende Code-Stelle wiederzufinden, und können beim normalen Lesen ignoriert werden.
Legende: Quelle: Beispiel-Datei.cpp So sieht eine Rückverfolgungs-Marke aus. Sie ist bewusst unauffällig (kleine Schrift, grauer Kasten, eigene Schriftart) gehalten, damit sie den Lesefluss nicht stört.
Stand: 2026-08-21. Bezieht sich auf den aktuellen Code-Stand von Promy2026 (modern/-Bibliothek).
Inhalt
Überblick: Die zwei Schritte eines Zugs
Was ein Reich in einem Zug einreichen kann
Schritt 1 – Spielzüge laden
Umweltverluste im Detail
Schritt 2 – Spielzüge ausführen
Der Kampf im Detail
Sichtbereich – was ein Reich sieht
Spielerkarte – was auf der Karte zu sehen ist
Berichtsausgabe
Zusammenfassung: bekannte Lücken und Vereinfachungen
Anhang – Tabellen
1. Überblick: Die zwei Schritte eines Zugs
Ein Spielzug läuft in zwei getrennten, nacheinander vom Spielleiter ausgelösten Schritten ab. Beide sind eigene Menüpunkte im Programm.
„Spielzüge laden“ – für jedes Reich wird dessen eingereichte Zugdatei gelesen, Zeile für Zeile geprüft und übernommen. Am Ende dieses Schritts laufen zusätzlich die Umweltverluste (Standverluste, Vulkanverluste, Steppeverluste, Landungsunterlassung/ Fliegerverluste) für alle Reiche.
„Spielzüge ausführen“ – ein zweiter, getrennter Programmaufruf, der die eingereichten Bewegungen tatsächlich umsetzt, Kämpfe austrägt, Status- und Bauberichte erstellt, Einkommen gutschreibt und den Sichtbereich neu berechnet. Am Ende werden pro Reich ein Textbericht und – neu – eine Kartenausgabe (Spielerkarte als Bild) geschrieben.
Wichtig für die Prüfung der Reihenfolge: Die Umweltverluste (Schritt 1) laufen bevor die eigentliche Bewegung stattfindet (Schritt 2). Ein Reich, das diesen Zug von A nach B zieht, wird von Stand-/Vulkanverlusten während „laden“ also noch anhand seiner alten Position (A) geprüft, nicht anhand des Ziels (B). Die einzige Ausnahme ist Steppeverluste, die ausdrücklich den ganzen für diesen Zug geplanten Weg mitberücksichtigt (siehe Abschnitt 4).
2. Was ein Reich in einem Zug einreichen kann
Eine Zugdatei besteht aus einer Zeile pro Befehl. Es gibt drei Zeilenarten:
2.1 Bewegen
Eine Bewegungszeile nennt eine Einheit (Nummer, Truppenzahl, ggf. ein Heerführer), die aktuelle Position und eine Liste von Wegpunkten (Großfeld/Kleinfeld), die die Einheit diesen Zug ansteuern soll. Optional kann die Einheit unterwegs auf ein Schiff einschiffen („e<Nummer>“), und die Zeile endet mit einem Buchstaben-Code, der die Absicht des Spielers für den Fall eines Zusammentreffens beschreibt.
Bedeutung der Entscheidungs-Codes am Ende einer Bewegungszeile Code Bedeutung
r Rückzug
v Verteidigen
a Angriff
n Nachsetzen
p1 Plündern
p2 Plündern extrem
s<Nummer>,… Splitten – ein Teil der Truppen wird als neue Einheit mit eigenem Weg abgespalten
Hinweis zur Korrektheit: Diese Codes werden eingelesen und gespeichert, aber der aktuelle Auswertungsprozess wertet sie nicht aus. Ob ein Spieler „r“ (Rückzug) oder „a“ (Angriff) gewählt hat, macht derzeit keinen Unterschied: Trifft eine Einheit unterwegs auf eine feindliche, nicht verbündete Einheit, wird immer automatisch und vollständig gekämpft (siehe Abschnitt 6). Das Original hatte hierzu offenbar eine eigene, nicht mehr vorliegende Entscheidungs- Tabelle des Spielleiters – diese wird hier nicht nachgebildet. Quelle: legacy_spielzug_movement_line.hpp / legacy_spielzug_execute.cpp – „decision_rule“ wird nirgends gelesen
2.2 Rüsten (eine neue Einheit ausbilden)
Eine Rüsten-Zeile benennt einen Einheitentyp, eine Truppenzahl, optional einen Heerführer und optional eine „Elite“-Ausbildungsstufe für Kampfkraft und/oder Bewegung. Die Kosten und die Ausbildungszeit ergeben sich aus festen Regeln (siehe Abschnitt 3.1) und werden beim Laden geprüft.
2.3 Bauen (ein Bauwerk errichten)
Eine Bauen-Zeile benennt einen Gebäudetyp und eine Zielposition. Auch hier werden die Kosten anhand fester Regeln geprüft.
Wichtige Lücke: Rüsten- und Bauen-Befehle werden beim Laden geprüft und als „vorgemerkt“ gespeichert – aber der aktuelle Auswertungsprozess (Schritt 2, „ausführen“) verwandelt diese Vormerkung in keiner Weise in eine wirkliche neue Einheit oder ein wirkliches neues Bauwerk. Die Vormerkung wird am Ende der Ausführung ersatzlos gelöscht (siehe „Aufräumen“ in Abschnitt 5). Nur Bewegen-Befehle haben derzeit eine echte Wirkung im Spielverlauf. Das betrifft die Kernfrage „stimmt die Wirkung des Zuges“ unmittelbar und sollte vor jeder inhaltlichen Detailprüfung an oberster Stelle stehen. Quelle: legacy_spielzug_commit_bauen.cpp / legacy_spielzug_commit_ruesten.cpp (erzeugen nur eine Vormerkung) + legacy_spielzug_execute.cpp (verarbeitet diese Vormerkung nicht)
3. Schritt 1 – Spielzüge laden
Für jedes Reich (in fester, aber beliebiger Reihenfolge) geschieht Folgendes:
Die zu diesem Reich und diesem Datum gehörende Zugdatei wird gesucht. Gibt es keine, wird das Reich übersprungen (der Spielleiter kann hier eingreifen und den ganzen Ladevorgang abbrechen, wenn eine Datei fehlt).
Jede Zeile der Datei wird einzeln gelesen und – je nach Art – wie in Abschnitt 2 beschrieben verarbeitet. Fehlerhafte oder nicht auflösbare Zeilen (z. B. eine unbekannte Einheitennummer) werden einzeln übersprungen, ohne die restliche Datei zu verwerfen.
Bei Rüsten- und Bauen-Zeilen werden die eingereichten Kosten mit den nach den festen Regeln erwarteten Kosten verglichen (Formeln siehe 3.1/3.2). Stimmen sie nicht überein, entscheidet der Spielleiter:
Genehmigt – die Zeile wird trotzdem übernommen, aber mit dem korrekten, regelkonformen Betrag, nicht mit dem eingereichten.
Erneut – nur diese eine Zeile wird verworfen, der Rest der Datei läuft normal weiter.
Abbrechen – der gesamte Ladevorgang wird sofort gestoppt, auch für alle noch nicht bearbeiteten Reiche.
Nachdem alle Reiche auf diese Weise durchlaufen wurden (und sofern nicht abgebrochen wurde), laufen für jedes Reich – in dieser festen Reihenfolge – die vier Umweltverluste-Prüfungen:
1. Standverluste
2. Vulkanverluste
3. Steppeverluste
4. Landungsunterlassung / Fliegerverluste
Die genauen Formeln stehen in Abschnitt 4.
3.1 Kostenformel für Rüsten
Elite-Index = Stufe der Kampf-Elite + Stufe der Bewegungs-Elite (0, wenn keine gewählt)
Elite-Vervielfacher(Index = 0) = 1
Elite-Vervielfacher(Index = 1) = 3
Elite-Vervielfacher(Index ≥ 2) = 3 × 2^(Index − 1)
Ausrüstungskosten je Truppe = Grundkosten des Einheitentyps × Elite-Vervielfacher(Elite-Index)
Gesamtkosten = Truppenzahl × Ausrüstungskosten je Truppe + Anzahl Heerführer × 1000
Quelle: legacy_spielzug_cost.cpp – expected_ruesten_cost / elite_cost_multiplier
Die Ausbildungszeit folgt einer ähnlichen, aber additiven Formel:
Zeitzuschlag(Index = 0) = 0
Zeitzuschlag(Index ≥ 1) = 6 + 3 × (Index − 1)
Gesamtzeit = Grundzeit des Einheitentyps + Zeitzuschlag(Elite-Index)
Quelle: legacy_spielzug_cost.cpp – expected_ruesten_time / elite_time_delta
3.2 Kostenformel für Bauen
Hier gibt es keine Formel im engeren Sinn: Die erwarteten Baukosten sind ein fester, pro Gebäudetyp hinterlegter Wert aus den Regeln (kein weiterer Faktor, keine Truppenzahl-Abhängigkeit). Quelle: legacy_spielzug_cost.cpp – expected_bauwerk_cost
4. Umweltverluste im Detail
Alle vier Umweltverluste-Formeln ziehen zufällig eine Prozentzahl und wenden diese direkt auf die aktuelle Truppenzahl an: Verlust = Truppenzahl × gewürfelter Prozentsatz ÷ 100 (abgerundet) Unterschiedlich ist nur, wie die Prozentzahl (bzw. die Spanne, aus der gewürfelt wird) zustande kommt.
4.1 Standverluste
Betrifft eine Einheit, die diesen Zug (zum Zeitpunkt des Ladens, also vor der Bewegung) auf einem gefährlichen Kleinfeld steht. Die Gefahrenspanne ergibt sich aus der Höhenstufe und der Geländeart dieses einen Kleinfelds zusammen (jeweils nur, wenn die Einheit dagegen nicht immun ist). Ist die Einheit gegen beides immun, oder ist die Summe der beiden Werte 0, entfällt der Verlust ganz. Eine Ausnahme gibt es: Zählt die Geländeart als „Steppeverluste“-Gelände, greift stattdessen ausschließlich Abschnitt 4.3 – die beiden Mechaniken schließen sich pro Geländeart gegenseitig aus.
Spanne = (Höhenstufen-Gefahrenwert, falls nicht immun) + (Geländeart-Gefahrenwert, falls nicht immun)
gewürfelter Wert = Zufallszahl zwischen 1 und Spanne
Verlust = Truppenzahl × gewürfelter Wert ÷ 100
Quelle: legacy_environmental_loss.hpp – compute_stationary_environmental_loss
Berichtstext: „<Anzahl> <Einheitentyp> stirbt/sterben durch den Aufenthalt auf <Höhenstufe>-<Geländeart>.“
4.2 Vulkanverluste
Betrifft eine Einheit, die neben einem oder mehreren vulkanisch gefährlichen Kleinfeldern steht (den bis zu sechs direkten Nachbarfeldern). Jedes qualifizierende Nachbarfeld (gefährlich und die Einheit ist nicht immun dagegen) liefert einen eigenen Würfelwurf. Die einzelnen Würfe werden nicht addiert, sondern zu einer gemeinsamen Wahrscheinlichkeit „aufgeschaukelt“: Jeder weitere gefährliche Nachbar erhöht das Risiko, kann es aber nie auf 100 % oder darüber bringen.
p = 0
für jedes qualifizierende Nachbarfeld:
Wurf = Zufallszahl zwischen 0 und (Gefahrenstärke dieses Nachbarn − 1)
p = p + ((Wurf + 1) × (100 − p) + 50) ÷ 100
Verlust = Truppenzahl × p ÷ 100
Quelle: legacy_environmental_loss.hpp – compute_vulkan_environmental_loss
Berichtstext: „<Anzahl> <Einheitentyp> wird/werden von Lava verschüttet.“
4.3 Steppeverluste
Betrifft eine Einheit dann, wenn irgendein Punkt ihres für diesen Zug geplanten Weges (nicht nur die aktuelle Position!) auf „Steppeverluste“- Gelände liegt. Dabei zählt der gesamte geplante Weg dieses Zuges, einschließlich Zwischenstopps – nicht nur Start oder Ziel.
Liegt jeder Punkt des Weges auf solchem Gelände (und die Einheit ist überall nicht immun), wird die stärkere „Aufenthalts“- Gefahrenzahl verwendet (der höchste an einem dieser Punkte gefundene Wert).
Liegt mindestens ein Punkt des Weges nicht auf solchem Gelände, wird stattdessen die schwächere „Erstmond“- Gefahrenzahl verwendet (wieder der höchste gefundene Wert unter den qualifizierenden Punkten).
Qualifiziert kein einziger Punkt des Weges, entfällt der Verlust ganz.
gewürfelter Wert = Zufallszahl zwischen 1 und der gewählten Gefahrenzahl
Verlust = Truppenzahl × gewürfelter Wert ÷ 100
Quelle: legacy_environmental_loss.hpp – compute_steppe_environmental_loss
Berichtstext: „<Anzahl> <Einheitentyp> stirbt/sterben wegen der Lebensbedingungen in der <Geländeart>.“
4.4 Landungsunterlassung / Fliegerverluste
Betrifft nur Einheiten, die derzeit eingeschifft sind (also keine normale Position auf der Karte haben). Für jede Einheit mit einer normalen Position wird lediglich vermerkt „zuletzt an Land gesehen: heute“ – kein Verlust. Für eine eingeschiffte Einheit wird geprüft, ob seit ihrem letzten „an Land“-Zeitpunkt bereits rund ein Myra-Monat vergangen ist. Ist das der Fall:
Ist der Einheitentyp ein Flieger, geht die gesamte Einheit verloren (Fliegerverluste).
Sonst wird ein Wurf zwischen 1 % und 10 % Truppenverlust angewendet (Mangelerscheinungen).
Gefangene Einheiten werden hierbei grundsätzlich übersprungen.
Flieger: Verlust = gesamte Truppenzahl (Einheit verschwindet vollständig)
sonst: gewürfelter Wert = Zufallszahl zwischen 1 und 10
Verlust = Truppenzahl × gewürfelter Wert ÷ 100
Quelle: legacy_environmental_loss.hpp – compute_landungsunterlassung_loss; legacy_spielzug_environmental_loss.hpp – commit_realm_landungsunterlassung_loss
Berichtstexte: „<Anzahl> <Einheitentyp> stirbt/sterben an Mangelerscheinungen.“ bzw. „<Einheitentyp> stürzt/stürzen erschöpft in den Tod.“
Bekannte Vereinfachung: Zwei zusätzliche, im Original vorhandene Modifikator-/Schwellenwerte pro Einheit werden hier nicht nachgebildet (die genauen Bytes dafür ließen sich nicht mehr auflösen) – nur die bestätigte „rund ein Monat ohne festen Boden“-Schwelle und die bestätigten Verlustformeln selbst.
4.5 Flussverluste – nicht angeschlossen
Bekannte Lücke: Die Formel für Verluste beim Durchqueren eines brückenlosen Flusses existiert im Code (10 % maximaler Verlust, gleiche Würfellogik wie oben), wird aber an keiner Stelle des aktuellen Auswertungsprozesses tatsächlich aufgerufen. Ein Flussübertritt verursacht derzeit also keinen Verlust. Quelle: legacy_environmental_loss.hpp – compute_river_crossing_loss (definiert, aber ungenutzt); legacy_spielzug_load.cpp, Kommentar „Flussverluste is deliberately left out“
5. Schritt 2 – Spielzüge ausführen
Dieser Schritt läuft in fünf benannten Phasen ab, in genau dieser Reihenfolge. Die Reihenfolge ist bewusst gewählt, damit jede Phase auf dem bereits korrekten Zwischenstand der vorherigen aufbaut (siehe die Begründungen unten).
Die fünf Phasen von „Spielzüge ausführen“ # Phase Was passiert
1 Einheiten verschieben Jede Einheit wird entlang ihres eingereichten Weges bewegt (Details unten).
2 Kämpfe auflösen Auf jedem Kleinfeld mit sich feindlich gegenüberstehenden Einheiten wird gekämpft (Abschnitt 6).
3 Status & Auflösung Für jede Einheit wird ihr Ergebnis dieses Zuges festgestellt (aufgestellt / gefallen / gefangen) und Einheiten mit 0 Truppen werden aufgelöst.
4 Bauwerke & Einkommen Baufortschritts-Meldungen, Einkommensgutschrift je Kleinfeld, Sammeln der neuen Sichtdaten.
5 Sichtbereich Der bisherige Sichtbereich jedes Reichs wird verworfen und aus den in Phase 4 gesammelten Daten komplett neu aufgebaut.
Quelle: legacy_spielzug_execute.cpp – execute_spielzuege, report_progress-Aufrufe markieren die fünf Phasengrenzen
5.1 Phase 1 – Einheiten verschieben
Für jede Einheit wird ihr eingereichter Weg (siehe Abschnitt 2.1) vom ältesten zum neuesten Wegpunkt durchgegangen. Am ersten Wegpunkt, an dem bereits eine Einheit eines anderen, nicht verbündeten Reichs steht, bleibt die Einheit stehen – der Rest ihres geplanten Weges wird nicht mehr zurückgelegt. Findet sich kein solcher Kontaktpunkt, erreicht die Einheit ihr eigentliches, zuletzt eingetragenes Ziel.
Bekannte Vereinfachung (Reihenfolge-Effekt): Diese Prüfung läuft Einheit für Einheit, nacheinander, nicht wirklich gleichzeitig für alle Reiche. Eine Einheit „sieht“ dabei nur, wo bereits vorher in diesem selben Durchlauf bewegte Einheiten stehen – nicht, wo eine Einheit stehen wird, die erst später in derselben Ausführung bewegt wird. Das ist eine bewusste, dokumentierte Näherung an eine echte Gleichzeitigkeits-Auflösung. Quelle: legacy_spielzug_execute.cpp – Kommentar zur Bewegungsphase
5.2 Phase 2 – Kämpfe auflösen
Siehe Abschnitt 6 für die vollständige Kampf-Formel.
5.3 Phase 3 – Status & Auflösung
Für jede Einheit jedes Reichs wird genau eine der drei folgenden Meldungen erzeugt:
Bedingung Meldung Berichtstext
Wurde diesen Zug gefangen genommen „EinheitGefangen“ „Heer <Nummer> <Anzahl> <Typ> wurde/wurden gefangengenommen.“
Truppenzahl ist 0 „EinheitTod“ „Heer <Nummer> ist vernichtet worden.“
sonst (lebt, hat Truppen) „Aufstellung“ „Heer <Nummer> – <Anzahl> <Typ> auf <GF>/<KF>.“
Anschließend werden alle Einheiten mit 0 Truppen tatsächlich aufgelöst (aus dem Reich entfernt). Diese Prüfung läuft nach Kampf, aber vor dem Aufräumen der Zug-Vormerkungen weiter unten – wichtig, damit eine im Kampf vernichtete Einheit hier korrekt als „EinheitTod“ erscheint und nicht fälschlich als „Aufstellung“.
Aufräumen der Zug-Vormerkungen
An dieser Stelle werden alle temporären Zug-Objekte gelöscht: die Bewegungs-/Rüsten-/Bauen-Vormerkungen dieses Zuges, die Wegpunkt-Zwischenstände der Einheiten sowie alle bereits gelesenen Berichte (siehe Abschnitt 9 für das Verhältnis zu den Textberichten – die Berichte werden vorher eingesammelt, sodass nichts verloren geht).
5.4 Phase 4 – Bauwerke & Einkommen
Für jedes echte, zentrale Bauwerk mit einem bekannten Fertigstellungsdatum:
Vergleichsdatum = aktuelles Datum + 1 Myra-Monat
wenn Vergleichsdatum ≤ Fertigstellungsdatum:
Meldung „BauwerkNeu“ (noch im Bau, nennt das erwartete Datum)
sonst:
Meldung „BauwerkAlt“ (bereits fertig, nennt das Datum)
Berichtstexte: „<Typ> <Name> wird vorraussichtlich am <Datum> auf <GF>/<KF> fertiggestellt.“ bzw. „<Typ> <Name> erbaut am <Datum> auf <GF>/<KF>.“ (Bauwerke ohne festgelegtes Datum erhalten keine Meldung.)
Für jedes Kleinfeld mit eigenem Einkommen:
solange gespeicherter Guthabenbetrag < 2 × normales Einkommen dieses Kleinfelds:
Guthaben += normales Einkommen ÷ 3 (abgerundet)
Das Guthaben eines Kleinfelds wächst also mit jedem Zug um ein Drittel seines normalen Einkommens, bis es das Doppelte des normalen Einkommens erreicht hat – danach stagniert es. Quelle: legacy_spielzug_execute.cpp – Einkommens-Abschnitt der Phase „Bauwerke & Einkommen“
Ebenfalls in dieser Phase werden – ohne dass hier schon etwas geschrieben wird – die für Phase 5 nötigen Sichtdaten gesammelt (siehe Abschnitt 7).
5.5 Phase 5 – Sichtbereich
Siehe Abschnitt 7 für die Berechnung im Detail.
6. Der Kampf im Detail
Kampf wird für jedes Kleinfeld einzeln geprüft, auf dem mindestens zwei Reiche mit lebenden Einheiten stehen, die nicht alle miteinander verbündet sind. Gibt es nur ein Reich, oder sind alle Anwesenden miteinander verbündet, findet kein Kampf statt.
6.1 Parteien bilden (Koalitionen)
Zunächst werden die anwesenden Reiche zu „Koalitionen“ gruppiert: alle miteinander (auch über mehrere Bündnisse hinweg) verbündeten Reiche kämpfen als eine gemeinsame Partei. Ein Reich ohne Bündnispartner vor Ort bildet seine eigene, einzelne Partei. Bleibt am Ende nur eine einzige Partei übrig, gibt es keinen Kampf.
6.2 Stärke einer Partei
Stärke der Partei =
(Summe der Gutpunkte aller eigenen Einheiten + 5)
×
Summe über alle eigenen Einheiten von:
(Truppenzahl ÷ Mindeststärke des Einheitentyps, ggf. aufgerundet)
× (Elitestärke der Einheit + 1)
× Gebietsfaktor
Quelle: legacy_spielzug_combat.cpp – compute_combat_weighted_strength
Gebietsfaktor Situation Faktor
Kleinfeld gehört einem anderen Reich als die Einheit × 0,75 (Nachteil in der Fremde)
Kleinfeld liegt in derselben Provinz, der auch die Einheit zugeordnet ist × 1,25 (Heimvorteil)
sonst (neutral) × 1,0
Wichtig für die Prüfung: Die Faktoren 0,75 und 1,25 sind bestätigt vorhanden im Original (ein Heimvorteil-/Fremde-Bonus existiert wirklich), ihre genauen Original-Werte ließen sich aber nicht mehr auslesen. Es handelt sich um plausible Platzhalterwerte, keine bestätigten Originalzahlen. Quelle: legacy_spielzug_combat.cpp – home_province_bonus_factor / foreign_realm_penalty_factor
6.3 Schadensanteil je Partei
Gesamtstärke = Summe der Stärken aller anwesenden Parteien
Schadensanteil(Partei) = 100 × (Gesamtstärke − eigene Stärke) ÷ Gesamtstärke
In Worten: Je stärker die Gegenseite insgesamt ist, desto höher der eigene Verlustanteil. Bei genau zwei Parteien ist das exakt die klassische Zwei-Seiten-Regel; bei drei oder mehr Parteien verallgemeinert diese Formel sie direkt.
6.4 Bauwerksverteidigung
Steht auf dem Kleinfeld ein fertiggestelltes, echtes (zentrales, nicht Wall/Straße/Brücke/Kanal) Bauwerk einer der Parteien, kann dieses einen Teil des Schadensanteils dieser Partei abfangen – bis zu seinem eigenen Verteidigungswert abzüglich bereits erlittener Schäden. Der abgefangene Betrag wird als „noch zu reparierender“ Schaden am Bauwerk vermerkt.
verfügbare Kapazität = Verteidigungswert − bisheriger Schaden − 1
abgefangen = min(verfügbare Kapazität, Schadensanteil der Partei)
neuer Schadensanteil der Partei = alter Schadensanteil − abgefangen
Quelle: legacy_spielzug_combat.cpp – apply_bauwerk_absorption
Nur das erste passende Bauwerk auf dem Kleinfeld wird berücksichtigt (kein Aufteilen auf mehrere Bauwerke gleichzeitig).
6.5 Vollständige Auslöschung („Überrennen“)
Bekannte Vereinfachung: Erreicht der Schadensanteil einer Partei rechnerisch 99,5 % oder mehr, verliert sie alle Truppen (statt nur den errechneten Anteil). Das ist keine echte Original-Formel, sondern ein bewusster Kunstgriff: Die reine Prozent-Formel allein kann rechnerisch praktisch nie exakt 100 % erreichen, eine vollständige Vernichtung müsste aber möglich sein, damit auch die Gefangennahme (6.7) überhaupt eintreten kann. Quelle: legacy_spielzug_combat.cpp – overrun_threshold_pct
6.6 Verlustformel je Einheit
Schadensanteil ≥ 99,5 %: Verlust = gesamte Truppenzahl der Einheit
sonst: Verlust = Truppenzahl × Schadensanteil der eigenen Partei ÷ 100 (abgerundet)
Berichtstext: „<Anzahl> <Typ> geht/gehen während einer Schlacht (siehe Überblick) verloren.“
6.7 Gefangennahme
Wird eine Partei durch diesen Kampf vollständig ausgelöscht (jede ihrer Einheiten steht bei 0 Truppen), wird ihre eigene, vor dem Kampf schwächste Einheit (nach Truppenzahl) von einer Einheit der stärksten überlebenden Partei gefangen genommen.
6.8 Was dieser Kampf-Mechanismus bewusst nicht nachbildet
Keinen echten Würfelwurf mit eigener Kurve/Streuung – ein direkter Prozentsatz ersetzt ihn.
Kein schrittweises, wegpunktweises Aufeinandertreffen mit Zwischenkämpfen unterwegs – der Kampf wird einmal, an der Stelle des ersten Kontakts, vollständig entschieden.
Bei drei oder mehr Parteien: das Original löst so einen Fall vermutlich schrittweise in mehrere neue Einzelkämpfe auf; hier werden stattdessen alle anwesenden Parteien in einem einzigen gemeinsamen Durchgang gegeneinander abgerechnet.
Keine „welches Bauwerk verteidigt welche einzelne Einheit“-Zuordnung – ein passendes Bauwerk verteidigt pauschal die ganze eigene Partei.
7. Sichtbereich – was ein Reich sieht
Der Sichtbereich eines Reichs wird bei jeder Ausführung vollständig neu aufgebaut: Der bisherige Sichtbereich wird zuerst komplett gelöscht, danach für jedes Reich mit mindestens einer eigenen Einheit oder einem eigenen Bauwerk irgendwo auf der Karte neu zusammengestellt. Ein Reich ohne jede Einheit und jedes Bauwerk hat danach gar keinen Sichtbereich mehr.
Was zum Sichtbereich beiträgt Quelle Sichtweite
Jede lebende Einheit ihr eigenes Kleinfeld plus die 6 direkt angrenzenden Kleinfelder (fest, unabhängig vom Einheitentyp)
Jedes echte, zentrale Bauwerk sein eigenes Kleinfeld plus eine je nach Bauwerk unterschiedliche Anzahl Ringe an Nachbarfeldern („Sichtweite“ des Gebäudetyps)
Bekannte Lücke: Rand-Bauwerke (Wall, Straße, Brücke, Kanal) tragen derzeit nichts zum Sichtbereich bei – nur echte, zentrale Gebäude wie Burgen, Städte, Tempel und ähnliches. Quelle: legacy_spielzug_execute.cpp – Sichtbereichs-Sammlung filtert ausdrücklich auf den zentralen Bauwerkstyp
Diese Neuberechnung läuft als letzte der fünf Phasen, also nachdem Bewegung, Kampf und Auflösung bereits abgeschlossen sind – der Sichtbereich spiegelt somit den Endstand des Zuges wider, nicht die Ausgangslage.
8. Spielerkarte – was auf der Karte zu sehen ist
Die Spielerkarte eines Reichs ist – anders als der Sichtbereich – eine dauerhafte Gedächtniskarte: alles, was dieses Reich jemals gesehen hat, bleibt darauf verzeichnet, auch nachdem es wieder aus dem aktuellen Sichtbereich verschwunden ist.
Der neue Kartenexport (Menü „Reichskartenausgabe“, sowie automatisch bei jeder Ausführung, ein Bild je Reich) zeigt für ein gewähltes Reich:
Jedes Kleinfeld, das laut der geladenen Karten-Datei jemals zur Spielerkarte dieses Reichs gehörte – mit demselben Erscheinungsbild wie die normale Kartenansicht (Gelände, Bauwerke, Einheiten, Grenzen, Küstenlinien, Reichskürzel).
Jedes andere Kleinfeld – vollständig leer, genauso wie ein Kleinfeld außerhalb der eigentlichen Karte dargestellt wird. Es gibt keine Einfärbung oder Abdunkelung „unbekannten“ Gebiets, es wird schlicht so behandelt, als gäbe es dort keine Information.
Sehr wichtige Lücke, unmittelbar korrektheitsrelevant: Der Auswertungsprozess selbst (Abschnitt 5) erweitert die Spielerkarte eines Reichs nicht. Was neu gesehen wird (Abschnitt 7, Sichtbereich), fließt derzeit an keiner Stelle automatisch in die Spielerkarte ein. Ein Kartenexport nach „Spielzüge ausführen“ zeigt daher exakt denselben Stand wie vorher – neu erkundetes Gebiet taucht dort nicht zusätzlich auf. Die Spielerkarte, die exportiert wird, stammt ausschließlich aus dem historischen Datenbestand der geladenen Datei. Quelle: legacy_spielzug_execute.cpp (keine Stelle schreibt auf den Spielerkarten-Datensatz); legacy_spielerkarte_export.cpp (liest nur, was ohnehin schon vorhanden ist)
9. Berichtsausgabe
Für jedes Reich mit einem auflösbaren Namen und Kürzel wird am Ende der Ausführung eine Textdatei erzeugt. Sie beginnt mit einer festen Begrüßung und Kopfzeile:
Seid gegrüßt <Herrschername> von <Reich>! Reich : <Reich> Hauptstadt: <Hauptstadt>
Danach folgen sechs feste Abschnitte. Jede während des Ladens oder Ausführens erzeugte Meldung (Bewegungsbestätigung, Umweltverlust, Kampfverlust, Status-, Bau-Meldung, …) wird anhand eines internen Kennbuchstabens genau einem dieser Abschnitte zugeordnet:
Berichtsabschnitte Kennbuchstabe Abschnittsüberschrift Inhalt Prüfstatus
A Die Heere - Züge Bewegungsbestätigung, Umweltverluste, Kampfverluste, Eroberung, Plünderung, Einschiffungs-Probleme gegen echtes Original-Beispiel bestätigt
D Die Heere - Rüsten (derzeit immer leer – wird von nichts befüllt) nicht implementiert
F Die Heere -Aufstellung Aufstellung / EinheitTod / EinheitGefangen aus Original-Gruppierung erschlossen, nicht einzeln bestätigt
E Die Bauwerke - Eigene BauwerkNeu / BauwerkAlt aus Original-Gruppierung erschlossen, nicht einzeln bestätigt
B Die Heere -Gesichtete (derzeit immer leer – Sichtungsmeldungen sind nicht implementiert) nicht implementiert
C Die Bauwerke - Gesichtete (derzeit immer leer – Sichtungsmeldungen sind nicht implementiert) nicht implementiert
Quelle: legacy_spielzug_report_file.cpp – report_sections, Zuordnungstabelle im Header-Kommentar
Zum Abschluss folgt immer:
Die Finanzen Der Reichsschatz von <Reich> besteht aus <Betrag> Goldstück.
10. Zusammenfassung: bekannte Lücken und Vereinfachungen
Die folgende Tabelle fasst alle in dieser Unterlage genannten, bewussten Abweichungen vom (rekonstruierten) Original noch einmal zusammen – als schnelle Prüfliste.
Bekannte Lücken und Vereinfachungen (Kurzübersicht) Bereich Lücke / Vereinfachung Schweregrad für die Zug-Wirkung
Rüsten / Bauen Vorgemerkte Befehle werden nach der Kostenprüfung nie tatsächlich in eine neue Einheit / ein neues Bauwerk umgesetzt; sie werden ersatzlos gelöscht. hoch – betrifft die Grundwirkung des Zuges
Entscheidungsregel Die Codes r/v/a/n/p1/p2 werden gespeichert, aber bei Kontakt nie ausgewertet – Kampf läuft immer automatisch und vollständig ab. hoch – betrifft, ob/wie ein Kampf überhaupt stattfindet
Spielerkarte Wird durch die Ausführung nicht erweitert; der Export zeigt nur historisch bereits vorhandene Daten. hoch – betrifft die Kartenausgabe direkt
Flussverluste Formel vorhanden, aber an keiner Stelle aufgerufen – Flussüberquerungen verursachen keinen Verlust. mittel
Sichtbereich der Rand-Bauwerke Wall/Straße/Brücke/Kanal tragen nichts zum Sichtbereich bei. mittel
Kampf: Gebietsfaktor Heimvorteil/Fremde-Faktor (0,75 / 1,25) sind plausible, nicht die bestätigten Original-Werte. mittel
Kampf: Überrennen-Schwelle (99,5 %) Künstliche Schwelle für „vollständige Auslöschung“, kein Teil der Original-Formel. mittel
Kampf: Mehrparteien-Auflösung Alle Parteien werden in einem gemeinsamen Durchgang abgerechnet statt schrittweise paarweise wie vermutlich im Original. gering bis mittel (nur bei 3+ Reichen auf einem Feld relevant)
Kampf: Bauwerksverteidigung Nur ein Bauwerk pro Partei verteidigt pauschal alle eigenen Einheiten, keine Einzel-Zuordnung. gering
Landungsunterlassung Zwei zusätzliche Original-Modifikatoren pro Einheit nicht nachgebildet. gering
Berichte B/C/D Rüsten-, sowie Sichtungs-Meldungen (Einheiten und Bauwerke) sind noch leer. gering (reine Berichtsvollständigkeit, keine Simulationswirkung)
Bewegung: Gleichzeitigkeit Reihenfolge-abhängige Näherung statt echter Gleichzeitigkeits-Auflösung beim „wer sieht wen zuerst“. gering, nur bei mehreren gleichzeitig bewegten Einheiten am selben Ort relevant
11. Anhang – Tabellen zum Nachschlagen
Anhang A – Alle Zufallsformeln im Überblick
Verlustart Wann angewendet Formel
Standverluste Aufenthalt auf gefährlichem Kleinfeld (beim Laden, vor der Bewegung) Zufallszahl 1…(Höhenstufen- + Geländewert) ÷ 100
Vulkanverluste Angrenzend an vulkanisches Gelände aufgeschaukelte Wahrscheinlichkeit aus einem Wurf je gefährlichem Nachbarfeld
Steppeverluste Geplanter Zug-Weg berührt Steppe-Gelände Zufallszahl 1…(stärkster oder schwächerer Gefahrenwert, je nach Wegabdeckung) ÷ 100
Flussverluste vorgesehen für Flussüberquerung ohne Brücke – derzeit nicht aufgerufen Zufallszahl 1…10 ÷ 100
Landungsunterlassung rund 1 Monat eingeschifft, kein Flieger Zufallszahl 1…10 ÷ 100
Fliegerverluste rund 1 Monat eingeschifft, Einheitentyp „Flieger“ gesamte Einheit verloren
Kampf feindlicher Kontakt auf einem Kleinfeld siehe Abschnitt 6
Anhang B – Konstanten im Code
Konstante Wert Verwendung
Heimvorteil-Faktor × 1,25 Kampf-Stärkeformel, eigene Provinz
Fremde-Nachteil-Faktor × 0,75 Kampf-Stärkeformel, fremdes Reichsgebiet
Überrennen-Schwelle 99,5 % Kampf – ab hier vollständige statt anteilige Auslöschung
Einkommens-Zuwachs Einkommen ÷ 3 je Zug, gedeckelt bei 2 × Einkommen Kleinfeld-Guthaben
Elite-Vervielfacher 1 / 3 / 3×2^(N−1) Rüsten-Kosten
Elite-Zeitzuschlag 0 / 6+3×(N−1) Rüsten-Zeit
Heerführer-Kosten 1000 je Heerführer Rüsten-Kosten
Sichtweite Einheit eigenes Feld + 6 Nachbarn (fest) Sichtbereich
„rund ein Monat“ 1 Myra-Monat Landungsunterlassung, Bauwerks-Fertigstellungsvergleich
Anhang C – Entscheidungsregel-Codes (eingelesen, aber nicht ausgewertet)
Code Bedeutung
r Rückzug
v Verteidigen
a Angriff
n Nachsetzen
p1 Plündern
p2 Plündern extrem
s Splitten (Truppenteilung mit eigenem Weg)
Anhang D – Reihenfolge-Übersicht des gesamten Zug-Ablaufs
Schritt Teilschritt Reihenfolge
1. Spielzüge laden Zeilen je Reich einlesen/prüfen 1.1
Umweltverluste (Stand → Vulkan → Steppe → Landungsunterlassung/Flieger), je Reich 1.2
2. Spielzüge ausführen Einheiten verschieben (inkl. Kontakt-Stopp) 2.1
Kämpfe auflösen 2.2
Status & Auflösung (inkl. Aufräumen der Vormerkungen) 2.3
Bauwerke & Einkommen 2.4
Sichtbereich neu aufbauen 2.5
3. Ausgabe Textbericht + Spielerkarten-Bild je Reich 3.1