Entwicklertagebuch

Interlock: Sector Command

Ein Echtzeit-Weltraumstrategiespiel für den Amiga 1200

Autor und Entwickler: Matthias Gentzsch
Dokumentierter Projektbeginn: 12. Mai 2026 (Vorüberlegungen im Frühjahr 2026)
Stand des Spiels: in Entwicklung, Konzeptphase abgeschlossen, erste Prototypen laufen

Warum es dieses Tagebuch gibt

Dieses Tagebuch dokumentiert, wie ein vollständiges Strategiespiel für einen über dreißig Jahre alten Computer entsteht – von der ersten Grafikidee bis zur fertigen Version auf echter Hardware.

Es richtet sich an zwei Leser. An Außenstehende, die später nachvollziehen wollen, wie so ein Projekt wirklich abläuft: nicht als glatte Erfolgsgeschichte, sondern mit Irrwegen, Streichungen und Entscheidungen, die dreimal umgeworfen wurden, bevor sie saßen. Und an mich selbst, damit ich in einem Jahr noch weiß, warum eine Regel so lautet, wie sie lautet – und welche Alternativen geprüft und verworfen wurden.

Eine Besonderheit dieses Projekts gehört gleich in die Einleitung, weil sie die gesamte Arbeitsweise prägt: Das Spiel entsteht in Zusammenarbeit mit mehreren KI-Systemen, die unterschiedliche Rollen haben. Das Konzept wurde über Monate mit ChatGPT entwickelt und in einer zentralen Master-Datei gepflegt. Claude übernahm ab Ende Juli die Gegenprüfung des gesamten Konzepts, die Bereinigung von Widersprüchen und die Ausarbeitung der Beschlussdokumente. Gemini diente als zweite, unabhängige Prüfinstanz für kritische Entscheidungen. Und Codex schreibt den Code der ersten Prototypen. Die Entscheidungen treffe ich als Entwickler des Spiels, Matthias Gentzsch – aber jede wichtige Regel durchläuft inzwischen mindestens zwei unabhängige Prüfungen, bevor sie verbindlich wird. Dass sich die KIs dabei gegenseitig korrigieren (und korrigiert werden müssen), ist selbst Teil der Geschichte, und das Tagebuch hält solche Fälle ausdrücklich fest.

Die jeweils neueste Master-Datei bleibt die verbindliche Source of Truth für das Spieldesign. Dieses Tagebuch erzählt den Weg dorthin – einschließlich der Sackgassen.

Teil I – Der Ursprung (Frühjahr bis 15. Mai 2026)

Vor dem ersten Bild – Die Browserspiel-Überlegung

Die allererste Idee war deutlich simpler als alles, was danach kam – und sie begann nicht mit dem Amiga, sondern mit einer Machbarkeitsüberlegung.

Der Ausgangspunkt war ein Blick auf Weltraum-Browserspiele. Die Logik dahinter: Was ein Browserspiel leisten kann, muss technisch auf jeden Fall auch auf einem Amiga umsetzbar sein. Browserspiele dieser Art kommen ohne aufwendige Grafik, ohne Echtzeitdarstellung und ohne komplexe Simulation aus – Ressourcenzähler, Bau-Timer, Flotten als Zahlenlisten, Kämpfe als errechnete Berichte. Wenn so etwas im Browser funktioniert, funktioniert es erst recht auf einem Amiga 1200. Als Machbarkeitsnachweis war das beruhigend: Die Grundidee „Weltraumstrategie auf dem Amiga" war keine Utopie.

Aber je länger die Beschäftigung mit diesen Spielen dauerte, desto klarer wurde das Gegenteil einer Vorlage: Diese Spiele waren zu simpel. Sie bestehen im Kern aus Tabellen und Wartezeiten. Man sieht seine Schiffe nicht fliegen, man erlebt keine Kämpfe, man erkundet keine Karte – man klickt Zahlen an und wartet. Genau das sollte das eigene Spiel nicht sein. Die Browserspiele wurden damit zum Negativ-Vorbild.

Diese Absetzbewegung hatte eine Konsequenz. Aus einer simplen Idee wurde so eine Kaskade von Einzelentschei-dungen, dutzende, später Hunderte. Die Kapitel dieses Tagebuchs sind im Grunde nichts anderes als das Protokoll, wie diese Fragen eine nach der anderen beantwortet wurden: die Rohstofffrage (Titan, Helium-3, Credits, Forschungspunkte; Abbau über Sonden und verwundbare Transportketten), die Fraktionsfrage (Menschen und Maschinen mit dem Leitsatz „Menschen handeln, Maschinen plündern"), die Modulfrage (der 26-Modul-Katalog mit Zonen, Energiekosten und sichtbaren Schäden). Dass so viele Entscheidungen nötig wurden, war kein Planungsfehler – es war der Preis dafür, kein Browserspiel zu bauen.

Das zweite Motiv – Dem Amiga geben, was der PC längst hat

Neben der Absetzung von den Browserspielen stand von Anfang an ein zweiter Antrieb, der die Richtung mindestens genauso stark bestimmte: Spielmechaniken, die PC-Spieler seit Jahren für selbstverständlich halten, sollten endlich auf dem Amiga ankommen.

Gemeint waren vor allem die sozialen und dynamischen Mechaniken moderner Strategiespiele: Teams bilden. Allianzen schmieden und brechen. In Echtzeit gegeneinander und miteinander spielen. Mehrspielerpartien über das Netzwerk. Auf dem PC ist das seit den Neunzigern Standardrepertoire. Auf dem Amiga sind diese Dinge einzeln selten und in Kombination schlicht neu. Es gab Echtzeitstrategie auf dem Amiga (Dune II wurde portiert), es gab Nullmodem-Duelle zu zweit; aber ein Echtzeit-Strategiespiel, in dem bis zu vier Teilnehmer über TCP/IP spielen, Allianzen bilden und wieder auflösen können und in dem menschliche Spieler und Computergegner in denselben Bündnisstrukturen agieren – ist auf dem Amiga in dieser Kombination bislang nicht bekannt.

Dieses Motiv erklärt mehrere Grundsatzentscheidungen, die sonst übertrieben ambitioniert wirken könnten: warum Multiplayer von Tag eins Teil der Vision war statt ein „vielleicht später"; warum die Diplomatie mit ihren Beziehungszuständen und der Siegbedingung über gegnerische Allianzen (nicht nur einzelne Fraktionen) früh feststand; warum Echtzeit trotz rundenbasierter Vorbilder gesetzt war; und warum die deterministische Lockstep-Architektur so viel Gewicht bekam – sie ist der technische Preis dafür, dass diese PC-Mechaniken auf einem 68020 überhaupt funktionieren können. Der Anspruch war nie, den PC zu imitieren. Der Anspruch war zu zeigen, dass der Amiga diese Spielideen tragen kann, wenn man sie für ihn baut statt sie zu portieren.

12. Mai – Ein Bild vor dem Spiel

Aus der noch vagen Idee wurde am 12. Mai die erste konkrete Spur – und zwar kein Designdokument, sondern eine Grafikfrage: Welche Auflösung hatte eigentlich die Amiga-Version von SimCity 2000 und wie würde ein eigenes, komplexes Amiga-Spiel in dieser Größenordnung aussehen?

Aus der Frage wurde ein erster Auftrag an mich selbst: ein Raumschiff im Amiga-Stil, 640 × 480 Pixel, 256 Farben. Und dieses Schiff sollte von Anfang an keine anonyme Einheit sein, sondern erkennbare Funktionsbereiche besitzen – ein Waffenmodul, ein Kommunikationsmodul, ein Solarmodul, zwei Lagermodule.

Die ersten Ergebnisse überzeugten nicht. Sie wirkten beliebig, wie moderne Pixelgrafik mit Retro-Etikett, nicht wie ein echtes Amiga-Spiel. Als Bezugspunkte kamen die Benutzeroberfläche von Colonization und die Schiffe aus US-Serie Battlestar Galactica hinzu und die Entwürfe wurden mehrfach verworfen und neu angesetzt.

Rückblickend ist an diesem ersten Tag dreierlei bemerkenswert. Erstens: Die Kernidee des späteren Spiels Schiffe, deren Fähigkeiten aus sichtbaren Modulen entstehen war vor jedem Regeltext da, als Bild. Zweitens: Fast alles Konkrete von diesem Tag wurde später gestrichen. Das Solarmodul existiert im heutigen Modulkatalog nicht mehr. Das Spannungsfeld, das an diesem Tag zum ersten Mal auftauchte, wurde zum Leitmotiv des ganzen Projekts – das Spiel soll mehr leisten als historische Amiga-Spiele, darf aber nie so tun, als wäre der Amiga ein moderner PC.

14. Mai – Aus der Grafik wird ein Projekt

Zwei Tage später wurde aus der Bildidee ein strukturiertes Vorhaben: ein Echtzeit-Weltraumstrategiespiel für den Amiga 1200 mit AGA-Chipsatz. Der Spieler erkundet eine große Karte, verwaltet Energie und Ressourcen, konstruiert Schiffe aus Modulen, erforscht Technologien, errichtet Außenposten und tritt gegen menschliche oder computergesteuerte Gegner an.

Die frühe Vision war dabei noch breiter als das heutige Spiel. Handel stand in den ersten Beschreibungen gleichberechtigt neben Exploration und Flottenbau – das Spiel wurde als Mischung aus Erkundung, Handel, modularen Flotten und Echtzeit-Action beschrieben, und Die Patrizier tauchte als Vergleich auf. Diese Gewichtung hielt nicht lange: Schon in den Folgetagen wurde festgelegt, dass Handel Nebenmechanik bleibt. Der Spieler sollte seine Zeit nicht mit Preisvergleichen und Handelsrouten verbringen, sondern mit Erkundung, Forschung, Aufbau und Konflikt. Kein Elite, keine Wirtschaftssimulation im Weltraum.

Die Inspirationsquellen erfüllten jeweils eine klar umrissene Aufgabe: Pirates! stand für die frei befahrbare Welt, Civilization und Colonization für Kartenbedienung und Fensterlogik, Reunion für Weltraumaufbau und Atmosphäre, Dune II für Echtzeitsteuerung und unmittelbaren Konflikt, Battlestar Galactica für die Maschinenfraktion und den Ton eines existenziellen Kriegs. Ausdrücklich festgehalten wurde, dass keines dieser Spiele allein das Vorbild ist.

Zwei Grundsatzentscheidungen dieses Tages tragen bis heute:

Echtzeit statt Runden. Obwohl mehrere Vorbilder Rundenstrategien sind, läuft das Spiel vollständig in Echtzeit. Schiffe bewegen sich sichtbar, Forschung und Produktion laufen weiter, mehrere Gefechte können gleichzeitig stattfinden. Im Einzelspieler gibt es eine Pause, im Mehrspieler nicht. Diese eine Entscheidung zog fast alle technischen Anforderungen nach sich, die das Projekt später beschäftigten: deterministische Berechnung, reproduzierbare Synchronisation für Netzwerkpartien, und die Frage, wie ein Amiga 1200 das alles gleichzeitig stemmt.

Die Karte als Zentrum, Fenster statt Vollbildmenüs. Nach dem Vorbild von Workbench und Colonization öffnen sich Informations-, Bau- und Kampffenster über der weiterlaufenden Hauptkarte, statt sie zu ersetzen. Aus den 640 × 480 der ersten Grafikversuche wurde dabei ein realistisches Ziel: primär 320 × 256 in PAL Lowres, optional 640 × 256 in Hires.

Multiplayer war von Beginn an Teil der Vision, nicht nachträglich angeflanscht: zwei menschliche Spieler über Nullmodem, bis zu vier Teilnehmer über TCP/IP, menschliche Spieler und Computergegner zusammen höchstens vier – getragen von einer tickbasierten, reproduzierbaren Simulation.

Ein früher Plan dieses Tages wurde später revidiert und gehört deshalb hierher: Ursprünglich sollten Kämpfe ohne getrennten Kampfmodus direkt auf der Weltkarte ablaufen. Erst als das Kampfsystem detaillierter wurde – Modulschäden, Zielwahl, Rückzug, mehrere parallele Gefechte –, zeigte sich, dass das auf der Hauptkarte allein nicht verständlich darstellbar ist. Das heutige Konzept eines separaten, interaktiven Kampffensters bei weiterlaufender Welt war also keine Ursprungsidee, sondern die Antwort auf ein Problem, das erst durch die Ausarbeitung sichtbar wurde.

Am selben Tag wurde das Projekt in thematische Chats gegliedert – Kernfeatures, Game Design, Technik, Grafik, Lore, Roadmap, Audio und mehr. Das machte die Arbeit übersichtlich und erzeugte zugleich das Problem, das zwei Monate später die größte Baustelle des Projekts werden sollte: Entscheidungen verteilten sich über viele Gespräche und begannen, sich zu widersprechen.

15. Mai – Energie, Schäden, Information, Maschinen

Der dritte Konzepttag legte drei Systeme an, die sich später als das Rückgrat des Spiels erwiesen.

Energie als verbindendes System. Bewegung kostet Energie, stillstehende Schiffe laden auf, bei leerem Konto tritt ein Notstromzustand ein, in dem Schilde und Forschung pausieren. Damit war ein stark bewaffnetes Schiff nicht automatisch ein gutes Schiff – sein Energiehaushalt musste tragen. Wie viel Bewegung genau kostet, blieb an diesem Tag offen; die endgültige Antwort ließ über zwei Monate auf sich warten und wurde eine der elegantesten Regeln des Spiels (siehe 26. Juli).

Module werden wirklich beschädigt. Treffer reduzieren nicht nur einen Hüllenwert. Ein beschädigter Scanner macht blind, ein beschädigter Antrieb macht langsam, beschädigte Waffen fallen aus. Der Zustand eines Schiffs sollte an seiner Funktion und möglichst auch an seinem Aussehen ablesbar sein – eine Forderung, die erst im Juli mit dem Sockelsystem des Schiffseditors technisch eingelöst wurde.

Informationskrieg als prägende, aber nicht dominante Mechanik. Begrenzte Sicht, Scanner, Satelliten, verborgene Bewegungen, Überraschungsangriffe. Der Spieler entscheidet auf unvollständiger Karteninformation, und gute Aufklärung ist ein echter Vorteil – ohne dass das Spiel zur Spionagesimulation wird.

Parallel entstand das Maschinenkollektiv als zweite spielbare Fraktion. Von Anfang an galt: Die Maschinen dürfen keine umlackierten Menschen sein. Sie reparieren schneller, schießen härter, verbrauchen deutlich mehr Energie und haben andere Ressourcenbedürfnisse. Im ersten Konzeptstand sollten sie ausdrücklich keine bessere Sensorik besitzen. Diese Festlegung wurde später revidiert: In der aktuellen Alpha-Regel sehen Maschinen mit Reichweite 5 ein Feld weiter als Menschen mit Reichweite 4. Dadurch können sie bestimmte Langstreckenwaffen selbstständiger einsetzen, während Menschen stärker auf Scouts und Verbundflotten angewiesen sind. Die Zylonen aus Battlestar Galactica standen erkennbar Pate, ohne dass deren Welt übernommen wird. Wie tief diese Asymmetrie wirklich reicht, stellte sich erst bei der großen Balance-Prüfung im Juli heraus.

Teil II – Der Konzeptsommer und das Dokumentationsproblem (Mai bis Juli 2026)

Über die folgenden Wochen wuchsen die Systeme: Planeten als Bauplätze, Asteroiden als endliche Abbauorte in drei Größen (zwei, vier oder sechs Sondenleerungen, dann erschöpft – mit Transportern, die die kleinen Sondenlager leeren müssen und dabei angreifbare Logistikwege erzeugen), der Schiffseditor mit speicherbaren Entwürfen und Bau-Timer, drei Siegwege (Zeitlimit, Vernichtung, Forschungsziel), ein Technologiebaum, Außenposten, Torpedos mit EMP-Modus, Satelliten.

Und mit jedem System wuchs das Problem. Regeln existierten in einem Chat als Idee, in einem anderen als Beschluss, in einem dritten in einer bereits überholten Fassung. Alte Dateien enthielten weiterhin gestrichene Mechaniken. Wer eine Frage beantworten wollte, musste erst klären, welcher von mehreren widersprüchlichen Ständen der gültige war.

Die Antwort darauf war die wichtigste organisatorische Entscheidung des Projekts: eine zentrale Master-Datei als Source of Truth. Am 5. Juli 2026 wurden die verstreuten Dokumente erstmals umfassend konsolidiert (v22); ältere Satellitendokumente wurden zu historischen Quellen erklärt, die nicht mehr ungeprüft in die aktuelle Fassung zurückfließen dürfen. Die Master-Datei archiviert nicht jede Diskussion – sie enthält den jeweils verbindlichen Stand, und nur den.

Wie nötig das war, zeigte sich unmittelbar danach.

Teil III – Die Gegenprüfung (22. bis 23. Juli 2026)

Mitte Juli lag der Master in Version 21/22 vor: über zweitausend Zeilen, dazu acht Begleitdokumente. Zeit für einen Schritt, den viele Hobbyprojekte auslassen – das gesamte Konzept wurde einer unabhängigen Prüfung unterzogen. Claude bekam alle Dateien mit dem Auftrag: Plausibilität prüfen, Widersprüche finden, Verbesserungen vorschlagen.

Das Urteil: Amiga-gerecht gedacht – aber mit Dokumenten-Drift

Der Kernbefund war ermutigend: Das Konzept beschreibt kein PC-Spiel mit Amiga-Etikett, sondern hat die Hardware-Grenzen als Designprinzip verinnerlicht. Die Schwächen lagen woanders: im Drift zwischen den Dokumenten (mehrere Dateien widersprachen dem Master), in einer ungeklärten Schild-Schadenspipeline, die mit dem Kampfcode kollidieren würde und in einem Konflikt um die vier Audio-Kanäle des Paula-Chips. Der wichtigste Verfahrensvorschlag aus dieser Prüfung wurde später Programm: ein Headless-Balance-Simulator, der ohne Grafik tausende Duelle pro Waffen- und Rumpfpaarung durchrechnet und Siegquoten als Zahlen liefert – der billigste Realitätscheck für ein Design, dessen Werte bis dahin am Reißbrett entstanden waren.

Die Balance-Prüfung: Die Zahlen erzählten eine andere Geschichte als der Text

Die folgenreichste Entdeckung der Gegenprüfung betraf die Fraktionsbalance. Das Designdokument beschrieb die Maschinen als strukturell überlegene Kriegsfraktion und die Menschen als improvisierenden Underdog. Die Alpha-Zahlen sagten das Gegenteil.

Maschinen zahlten 150 % Titan für 30 % mehr Waffenschaden – pro investierter Titan-Einheit lieferte ein Maschinenschiff also nur rund 87 % der menschlichen Feuerkraft. Ihre Vorteile (doppelte Reparaturgeschwindigkeit, größere Energiepools) wirkten vor allem zwischen den Gefechten; in der Entscheidungsschlacht selbst kaufte der Mensch pro Titan schlicht mehr Schaden. Die Fraktion, die den Abnutzungskrieg gewinnen sollte, verlor ihn ökonomisch.

Noch kritischer war die Helium-3-Todesspirale: Maschinen hatten doppelten Helium-3-Bedarf und doppelten Reaktorverbrauch – aber keinen Rettungsmechanismus. Der Handel, im Konzept ausdrücklich als Rettungsmechanik bei Produktionsblockaden definiert, existierte praktisch nur für die Menschen, also für die Fraktion, die ihn am wenigsten brauchte. Eine Maschinenfraktion in Ressourcennot konnte sich nur durch militärische Eroberung retten – mit Schiffen, die doppelte Bewegungsenergie kosten. Eine positive Rückkopplung Richtung unaufhaltsamer Niederlage.

Die Lösung ist inzwischen eines der Markenzeichen des Spiels: Assimilation. Maschinen bergen die Wracks zerstörter Schiffe – eigene wie feindliche – und gewinnen daraus Titan und Helium-3 zurück

Aus derselben Prüfrunde stammen zwei Streichungen, die das Spiel einfacher und besser machten: Das Gewichtssystem für Module wurde ersatzlos gestrichen (1 Modul = 1 Slot, Geschwindigkeit kommt allein vom Triebwerkstyp – der Slot-Zwang liefert das gewünschte Gefühl bereits, ohne eine komplette zusätzliche Balance-Achse), und das Solarmodul aus den allerersten Grafikentwürfen verschwand endgültig aus dem Katalog.

Das Prüfverfahren wird zur Methode

Aus der Balance-Runde entstand eine Entscheidungsvorlage mit 17 Punkten – Modulkatalog, Techbaum-Befüllung, offene Regeln. Und hier etablierte sich der Arbeitsmodus, der seither gilt: Die Vorlage ging zusätzlich an Gemini zur unabhängigen Zweitprüfung. Gemini bestätigte, präzisierte an mehreren Stellen (etwa die Reparatur-Kampfsperre als exakte Formel: Reparatur erst, wenn seit dem letzten erlittenen oder ausgeteilten Schaden zehn Ticks vergangen sind – simpel, deterministisch, ohne Sonderfälle) – und irrte an einer Stelle, die fast unbemerkt durchgerutscht wäre: Gemini schrieb den Menschen Ressourcen- und Blaupausen-Erträge aus Wrack-Scans zu, die es laut Beschlusslage nicht gibt. Der Altwrack-Scan liefert Menschen ausschließlich Forschungspunkte; Ressourcen aus Wracks sind exklusiv maschinell. Die Korrektur wurde explizit festgeschrieben, bevor sich der Fehler festsetzen konnte.

Solche Momente sind der Grund, warum dieses Tagebuch die Arbeitsweise dokumentiert: Keine der beteiligten KIs ist eine Autorität. Die Beschlusslage ist die Autorität und sie muss verteidigt werden, auch gegen plausibel klingende Abweichungen.

Teil IV – Die Revisionswoche (23. bis 26. Juli 2026)

Auf die Gegenprüfung folgte die dichteste Phase des Projekts: In vier Tagen wurden fast alle offenen Grundsatzfragen entschieden. Die Master-Datei sprang von v25 auf v35.

Die Rumpfgrößen. Der dritte Anlauf

Kaum eine Zahl wurde so oft geändert wie die Slot-Staffelung der Schiffsrümpfe. Der Weg:

Wichtig an der entgültigen Fassung: Der 4-Slot-Rumpf ist ein regulärer Rumpf, kein Sonderobjekt. Pflicht sind nur Reaktor und Antrieb; Sensor und Kommunikation sind Entwurfsentscheidungen. Ein 4-Slot-Schiff ist als Scout, Kurier oder bewaffneter Kleinstjäger vollwertig. Der größte Rumpf heißt seither offiziell „Flaggschiff-Rumpf".

Diese Revision ist das Paradebeispiel dafür, warum das Tagebuch verworfene Stände festhält: Die heutige Lösung wirkt selbstverständlich – sie war das Ergebnis von drei Anläufen, das Flottengefühl mit Bildschirm, Speicher und Bedienung zu versöhnen.

25. Juli – Das Sockelsystem: Wie ein Bild-Mockup zur Editorarchitektur wurde

KI-generierte Bildreferenzen für den Schiffseditor zeigten ein Prinzip, das sofort überzeugte: ein Schiffs-Skelett mit benannten Zonen (Bug, Systeme, Kern, Antrieb, Fracht), in das die Module glaubwürdig hineingezeichnet sind – mit Rohrverbindungen, gemeinsamer Schattierung, durchgehendem Rumpfumriss. Keine schwebenden Inventar-Icons.

Aus dem Bild wurde ein Beschluss mit drei Kernregeln. Erstens: Jede Rumpfklasse hat ein festes Skelett; die Zonennamen dienen der Lesbarkeit, nicht der Regellogik – die Platzierung bleibt frei. Zweitens: Jeder Sockel kennt genau drei Zustände – leer (rumpfklassenspezifische Abdeckplatte, damit ein halbleeres Frühspiel-Schiff keine Löcher in der Silhouette hat; fiktional eine Verkleidung, kein Defekt), belegt (Modulgrafik) und beschädigt (verrußte, aufgerissene Variante). Mit dem dritten Zustand sind die seit Mai geforderten sichtbaren Modulschäden eingelöst – ohne ein einziges neues System, nur durch eine dritte Bildvariante pro Sockel. Drittens, und das ist der Amiga-entscheidende Teil: Die Zusammensetzung geschieht beim Speichern des Entwurfs im Editor, nicht zur Laufzeit. Auf der Karte und im Kampf ist jedes Schiff ein fertig vorkomponiertes Bob wie jedes andere Objekt – null Compositing-Kosten im Spielbetrieb; ein Modulschaden ist ein simpler Grafiktausch.

Die Übernahme aus den Mockups war dabei ausdrücklich selektiv: Das Skelettprinzip ja – die Slotzahlen der Bilder (4/8/12/16, ein veralteter Stand) und die erfundenen Modulnamen der KI-Kataloge („Holevernetter") nein. Verbindlich blieb der konsolidierte 26-Modul-Katalog. Auch das ist Methode: Bildgeneratoren liefern Ideen, die Beschlusslage liefert die Fakten.

23.–25. Juli – Entdeckungen: Die Galaxis lernt, Geschichten zu erzählen

Mit laufender Programmierung galt eine klare Ansage: keine neuen Systeme mehr – aber mehr Inhalt aus den vorhandenen Bausteinen. Die Erkenntnis dahinter: Das Konzept enthielt bereits alles, was ein Entdeckungssystem braucht – Kartenobjekte, Nebel des Krieges, Sensorik, Funkmeldungen, Wracks, den synchronisierten Zufallsgenerator und vier Währungen. Eine Entdeckung ist dann nichts weiter als ein unbekannter Sensorkontakt, dessen Auflösung in einen vorhandenen Zähler einzahlt oder einen Risiko-Spawn erzeugt.

So entstand der Anhang „Entdeckungen und Anomalien": Versorgungscaches, Altwracks und ganze Friedhofssektoren eines nie erklärten Vorgängerkriegs (Maschinen bergen sie, Menschen scannen sie für Forschungspunkte – dieselbe Entdeckung fühlt sich je Fraktion anders an), zwölf nummerierte Logbuch-Fragmente, eine vierstufige Alien-Spurenleiter, Hinterhalte, Datenkerne, Signalgeber, Strahlungsasteroiden, ein neutraler Konzern mit Rettungs- und Verteidigungsereignissen – und echte Wettrennen zwischen den Spielern, mit einer bis ins Detail deterministischen Regel: Die Belohnung geht exklusiv an den Sieger, Verlierer verlieren nichts (sonst fliegt nach zwei verlorenen Rennen niemand mehr los), und Gleichstände im selben Tick werden ohne Zufallswurf aufgelöst – erst über die geringere Distanz, dann über die Spieler-ID. Wer die notleidende Station lieber überfällt statt beliefert, darf das – verliert aber über eine Neutralitätsmaske dauerhaft den kompletten Konzern-Belohnungsstrang.

Die Geschichte des Prototyp-Wracks – eingebaut und wieder gestrichen

Ein Lehrstück aus dieser Phase verdient einen eigenen Abschnitt, weil es zeigt, wie im Projekt entschieden wird.

Gemini schlug als Entdeckung ein Prototyp-Wrack vor: ein beschädigtes Gratis-Kampfschiff als Fund. Die Idee war reizvoll und wurde – nach ausdrücklicher Warnung – mit harten Leitplanken eingebaut: niedrigstes Tabellengewicht, Tick-Sperre gegen den Frühspiel-Schneeball, fester vordefinierter Entwurf mit 40 % Hülle, plus ein eigener Simulator-Testpunkt, der den Fundwert gegen eine gleichwertige Titan-Investition deckelt.

Einen Tag später wurde es komplett wieder entfernt. Die Begründung steht seither als Grundsatz in der Abgrenzung des Anhangs: keine Entdeckungen mit direktem Militärwert. Alle anderen Funde zahlen in Wirtschaft, Forschung oder Aufklärung ein – in Vorteile, die der Spieler erst in Kampfkraft umwandeln muss. Ein fertiges Kampfschiff überspringt diese Umwandlung: Schneeball-Risiko im Frühspiel, Kartenglück statt Können im Multiplayer, und ein doppelter Maschinenvorteil, weil Maschinen den Fund dank Reparatur billiger flottmachen oder alternativ sofort gewinnbringend bergen können – für sie wäre er nie ein Fehlfund gewesen.

Der Ausschluss wurde ausdrücklich dokumentiert, „damit spätere KI-Sessions das Prototyp-Wrack nicht wieder einführen". Ein Satz, der die Realität dieses Projekts gut zusammenfasst: Verworfene Ideen müssen schriftlich beerdigt werden, sonst stehen sie wieder auf.

25. Juli – Diplomatie ohne Vertragsbürokratie

Für die Diplomatie wurden drei Beziehungszustände und zwei Beendigungswege festgelegt – und eine lange Liste bewusster Verzichte: keine befristeten Verträge, keine Tribute, keine Geschenke, keine Vertragsverwaltung. Dieselbe Grundlinie wie beim Handel: Systeme sollen strategische Konsequenzen haben (dynamische Fronten, belohnte Aufklärung), aber den Kern aus Exploration, Flottenbau, Forschung und Konflikt nicht verdrängen.

25.–26. Juli – Die KI: Charaktere statt Schwierigkeitsregler

Die Computergegner bekamen eine eigene Architektur – und zwei Grundsatzbeschlüsse, die vor allem definieren, was die KI nicht darf.

Kein Schummelwissen. Die KI unterliegt exakt denselben Sichtregeln wie der Spieler: Nebel des Krieges, Sensorreichweiten, Tarnung – kein Wallhack, keine Ausnahme für die Strategieebene. Eine KI ohne Sicht auf lohnende Ziele expandiert und klärt auf, statt zu wissen. Und das ist keine Absichtserklärung, sondern eine prüfbare Eigenschaft: Ein automatisierter Fairness-Nachweis kontrolliert im Simulator, dass die KI nie ein Ziel gewählt hat, das sie zum Entscheidungszeitpunkt nicht sehen konnte.

Keine Schwierigkeit über Boni. Ausdrücklich ausgeschlossen sind Sichtvorteile, Einkommensmodifikatoren, Rabatte und Würfelvorteile – die klassischen Tricks, mit denen Strategiespiele „schwere" Gegner bauen.

Stattdessen: eine gemeinsame, fraktionsneutrale Zustandsmaschine (Expansion, Tech-Ausbau, Aggression, Krise) mit fraktionsspezifischen Krisenantworten (Menschen handeln, Maschinen plündern – der Leitsatz wieder), vier Doktrinen (Vernichtung, Expansion, Forschung, Ausgeglichen) als reine Datentabellen – und darüber, nach dem Vorbild von Siedler und Anno, ein Charaktermodell: Der Spieler wählt keinen Schwierigkeitsgrad, sondern einen benannten Gegner. Acht Charaktere, vier je Fraktion, jeder eine Kombination aus Doktrin und Spielstärke (Schwächling, Solide, Meister). Der Schwächling macht lesbare Fehler und denkt langsamer; der Meister hat optimale Tabellen – und keinerlei Vorteil. Wer „Unbekannt" wählt, muss den Charakter des Gegners erst erkennen: an seinem Funkstil und durch Aufklärung seines Kernsektors. Damit bekommt der Informationskrieg im Einzelspieler dieselbe Rolle wie im Mehrspielerspiel.

Technisch ist die KI Teil der Simulationsarchitektur: Strategieauswertung nur alle 32 Ticks, mehrere KI-Spieler um je 8 Ticks versetzt gegen Lastspitzen, deterministische Zielbewertung nach Gewicht und Distanz. Weil die KI eine reine Funktion aus Spielzustand und synchronisiertem Zufallsgenerator ist, läuft sie auf allen Rechnern identisch – KI-Spieler erzeugen im Multiplayer null Netzwerkverkehr. Und damit keine Partie im Patt zweier passiver Gegner versandet, gibt es die Siegweg-Panik: Erreicht irgendein Gegner 85 % eines Siegwegs, wechselt jede KI in den Alarmmodus und jagt die siegtragenden Objekte.

26. Juli – Ereignisbilder: Der Amiga zeigt, was er kann

Für die zwanzig Ereignisbilder (Wrackfund, Alien-Ruine, Notruf, Konzern-Kontakt …) wurde ein Verfahren festgelegt, das typische Amiga-Stärken nutzt, statt moderne Effekte zu imitieren: 160 × 100 Pixel bei 6 Bitplanes (12 KB pro Bild), eine eigene 64-Farben-Palette, auf die der Copper exakt am Fensterrand umschaltet, und Animation per Color Cycling statt Einzelbildern – vier rotierende Palettenindizes genügen für rotierende Radarstrahlen, blinkende Warnlichter, laufende Datenströme. Null zusätzlicher Speicher, null CPU-Last.

Zwei Regeln daraus sind übertragbar aufs ganze Projekt: Die Bildmotive dürfen frei (auch KI-) generiert werden, laufen danach aber zwingend durch eine Skript-Pipeline auf die gemeinsame Palette – Konvertierung ist Pipeline-Arbeit, keine Handarbeit. Und: kein eingebrannter Text in Bildern. Bei fünf Textsprachen wäre jeder generierte Schriftzug in vier davon falsch; alle Beschriftung kommt aus dem Textsystem.

Master v34 – Fünf Sprachen als Architekturentscheidung

Das fertige Spiel erhält fünf Textsprachen – Deutsch, Englisch, Französisch, Spanisch, Italienisch – sowie Sprachausgabe auf Deutsch und Englisch, getrennt wählbar. (Ein älterer Planungsstand führte noch Polnisch; er wurde durch diese Auswahl ersetzt.) Entscheidend ist weniger die Liste als der Zeitpunkt: Lokalisierung wird nicht am Ende übergestülpt, sondern ist Architektur. Alle Texte und Samples hängen an stabilen IDs, nichts Lokalisiertes steckt in Grafiken oder Spiellogik, der Bitmap-Zeichensatz muss die Sonderzeichen können, und die notorisch längeren romanischen Texte werden ausdrücklich in den kleinen Amiga-Fenstern getestet. Sprachoptionen sind rein lokal – sie dürfen Netzwerk-Synchronisation und Prüfsummen nicht berühren.

26. Juli – Master v35: Die Bewegungsfrage wird nach zwei Monaten beantwortet

Seit dem 15. Mai war offen, was Bewegung genau kostet. Zwei Modelle standen zur Wahl. Modell A, flach: jedes Schiff zahlt denselben Preis pro Feld – einfach, aber ein Flaggschiff flöge energetisch so billig wie ein Kurier, und Größe hätte keinen Bewegungspreis, ausgerechnet nachdem das Gewichtssystem gestrichen worden war. Modell B, Rumpfskalierung: die Kosten wachsen mit der Rumpfklasse – Menschen zahlen 1/2/3/4 Energie pro Feld für die vier Rumpfgrößen, Maschinen fraktionsbedingt das Doppelte: 2/4/6/8.

Modell B gewann, und zwar aus einem Grund, der beim Durchrechnen sichtbar wurde: Die Zahlen rasten mit den bestehenden Reaktorwerten fast perfekt ein. Ein mittlerer Rumpf mit Start-Reaktor fährt bei Netto null, also nur aus der Reserve – die spürbare Aufforderung, den besseren Reaktor zu erforschen. Das Flaggschiff ist ohne Spitzenreaktor praktisch unbeweglich. Damit liefert das Energiegesetz genau die Fortschrittskopplung, die das gestrichene Gewichtssystem hätte liefern sollen – ohne neue Balance-Achse, über ein System, das es schon gab. Vor jedem einzelnen Feld wird geprüft, ob die Energie reicht; das Konto wird nie negativ. Ein Schiff ohne Energie stoppt, lädt, fährt weiter – kein Schuldenkonto.

Gleichzeitig entschieden: Mehrere Antriebe sind reine Redundanz. Der beste funktionsfähige Antrieb bestimmt Geschwindigkeit und Kosten; zusätzliche Antriebe geben keinen Geschwindigkeits-, Reichweiten- oder Kostenbonus. Fällt der aktive Antrieb aus, wechselt das Schiff deterministisch zum nächstbesten. Damit wird der zweite Antrieb auf dem Flaggschiff zur echten Konstruktionsfrage: Er steigert keine Kampfkraft, aber er sichert die Heimkehr gegen gezielten Triebwerksbeschuss. Der Editor belohnt nicht nur Maximalwerte, sondern auch fehlertolerante Entwürfe. (Und zwei Klarstellungen, damit kein Programmierer raten muss: Richtungswechsel kosten nichts – die 16 Darstellungsrichtungen sind reine Optik –, und ein Ionenantrieb mit zwei Feldern pro Tick prüft und bezahlt beide Schritte einzeln.)

26. Juli – Master v36: Echte Hardware wird Teil der Definition

Mit Master v36 wurde aus dem vorhandenen Amiga 1200 mehr als ein späteres Vorführgerät. Er wurde zur verbindlichen Referenzhardware des Projekts.

Nach jedem technischen Meilenstein soll derselbe Build zunächst im Emulator und anschließend auf dem echten Rechner geprüft werden. Dokumentiert werden dabei mindestens Buildstand, Hardwarekonfiguration, Speicherbedarf, Bildaufbau, Eingabeverhalten, Audio, Stabilität und erkennbare Unterschiede zwischen Emulator und Originalhardware.

Der aktuelle Masterstand korrigierte außerdem mehrere Zwischenstände, die im Tagebuch als Entwicklungsschritte erhalten bleiben müssen: Die KI umfasst elf benannte Charaktere statt des früheren Acht-Charaktere-Modells – verbindlich sind zwei Schwächlinge, ein ausgeglichener Referenzgegner, sieben Spezialisten mit einer messbaren Stärke und einer ausnutzbaren Schwäche sowie ein Endgegner, der keine Boni und kein Schummelwissen erhält, sondern die vorhandenen Regeln lediglich besonders konsequent ausführt. Die Charaktere unterscheiden sich außerdem nicht nur beim Bauen und Kämpfen: Sie besitzen eigene diplomatische Grundsätze, Sympathien, Feindschaften und unterschiedliche Zuverlässigkeit – ein Bündnis mit einem Computergegner ist deshalb eine strategische Entscheidung und keine bloße Waffenruhe. Weiter gilt: Maschinen besitzen in der Alpha-Regel eine Sichtweite von 5 gegenüber 4 bei Menschen. Und der separate interaktive Kampfbereich bleibt ein Favorit, aber noch kein endgültiger Beschluss – Prototypen und Hardwaretests entscheiden über Darstellung, Bedienung und Synchronisation.

Damit wurde festgeschrieben, dass eine Funktion nicht allein deshalb als fertig gilt, weil sie unter Linux oder im Emulator funktioniert.

Teil V – Vom Papier zum Code (Juli 2026)

Die Programmierung beginnt und der erste Code-Review

Parallel zur Revisionswoche begann Codex mit der Implementierung eines ersten textbasierten Logik-Prototyps unter Linux: Karte, Schiffe, Wegpunkte, Energie, ein simpler Kampf. Der Stand wurde – natürlich – gegengeprüft, und der Review fiel lehrreich aus, in beide Richtungen.

Auf der Habenseite: reine Integer-Arithmetik, Wegpunkte als festes Array statt verketteter Liste (Amiga-gerecht, kein malloc), eine config.h als gelebtes Konstantenregister. Und ein vermutlich unbeabsichtigter Glücksfall: Die Bewegung schritt x und y gleichzeitig fort – das ist exakt Chebyshev-Bewegung und damit konsistent zur Chebyshev-Waffenreichweite aus dem Master. Ausdrückliche Review-Anweisung: nicht „reparieren". Auch der Kampf machte das Wichtigste richtig: Beide Schadenswerte werden vor dem Anwenden berechnet – simultaner, reihenfolgeunabhängiger Schlagabtausch, genau die Eigenschaft, die der spätere Determinismus braucht.

Auf der Sollseite drei Architekturprobleme, alle vor dem Weiterbau zu beheben: Deutsche Statustexte („wartet", „lädt") steckten mitten in der Spiellogik – Darstellung leckt in die Simulation, tödlich für Mehrsprachigkeit und Headless-Tests; Lösung: ein Status-Enum, die Renderschicht übersetzt. Es fehlte ein zentraler GameState mit reiner simulate_tick()-Funktion – diese eine Struktur ist später Savegame, Netzwerk-Sync-Objekt und Simulator-Input zugleich. Und die Energie-Logik widersprach dem Master (Lade-Entlade-Oszillator statt des kontinuierlichen Energiegesetzes „Energie plus Regeneration minus Verbrauch, jeden Tick").

Der Review förderte außerdem eine Diskrepanz zwischen Repo-Stand und Statusdokument zutage – der committete Code war älter als das, was das Dokument als fertig beschrieb. Seither gilt: Der Commit-Stand ist die Wahrheit über den Code, so wie der Master die Wahrheit über das Design ist.

SDL3, Emulator, echte Hardware

Ende Juli wurde die technische Umgebung festgezurrt. Unter Linux dient SDL3 für schnelle Grafik- und Layoutprototypen; der SDL3-Prototyp wurde selbstständig baubar gemacht (Commit 86dd8d83 – fix: make SDL3 prototype self-contained), nachdem ein Fehler behoben war, bei dem visuelle Demoereignisse verloren gingen (visual_dropped=0). Normale Builds hängen nicht von SDL3 ab. FS-UAE 3.2.35 ist als Emulator installiert.

Und – die vielleicht wichtigste Nachricht dieser Tage: Ein echter Amiga 1200 steht als Referenzhardware bereit. Ladezeiten, Bildaufbau, Eingabeverhalten, Speicherbedarf, Audio, Stabilität langer Partien und vor allem die Unterschiede zwischen Emulator und Originalhardware werden am realen Gerät gemessen, nicht geschätzt. Die Hardwarekonfiguration wird dokumentiert, damit Testergebnisse reproduzierbar bleiben.

Die festgelegte Entwicklungs- und Testkette: Mechanik plattformneutral präzisieren → schnelle Linux/SDL3-Prototypen → Übertragung in Amiga-gerechte Sprache und Architektur → Emulatortest → Test unter Workbench-realistischen Bedingungen → echte Hardware → Abweichungen dokumentieren.

Lehren aus fremden Fehlern

Eine ausgewertete Keynote von Richard Löwenstein über moderne Amiga-Spieleentwicklung lieferte Leitplanken, die sich mit den eigenen Befunden deckten:

1. keine Diskettenversion als unnötige Fessel
2. Audio früh planen
3. Sprachausgabe nur gezielt
4. Effekte nur mit spielerischem Nutzen
5. Emulatoren nie mit echter Hardware gleichsetzen
6. eine feste Testmatrix
7. technische Risiken nicht ans Projektende verschieben

Der historische Kardinalfehler, den dieses Projekt nicht wiederholen will: eine Architektur von einer stärkeren Plattform übernehmen (z.B. SimCity 2000) und erst spät merken, dass sie auf dem Amiga nicht schnell genug läuft. Genau dagegen stehen der frühe echte A1200, der Headless-Simulator und die Prüfaufträge im Master.

Teil VI – Was dieses Spiel besonders macht

Was auf dem Amiga selten war oder in dieser Kombination nicht bekannt ist

Der Amiga hatte in seiner kommerziellen Blütezeit eine der besten Spielebibliotheken seiner Ära. Und trotzdem gibt es eine Reihe von Dingen, die dieses Spiel haben wird und die auf dieser Plattform in dreißig Jahren nie erschienen sind – teils, weil die Technik zu spät kam, teils, weil die Ära endete, bevor der PC diese Ideen etablierte. Das ist der Kern des Vorhabens: kein Nostalgieprodukt, sondern das Amiga-Spiel, das es 1994 hätte geben müssen und nie gab.

Netzwerk-Mehrspieler über TCP/IP in einem Strategiespiel. Amiga-Spiele der Neunziger kannten Mehrspieler als Nullmodem- oder Modem-Duell zu zweit oder als Hotseat. TCP/IP-Stacks wie AmiTCP erschienen ab 1993 – zu spät, als dass je ein kommerzielles Strategiespiel sie genutzt hätte. Eine Echtzeitpartie mit vier Teilnehmern über das Netzwerk hat es auf dem Amiga schlicht nie gegeben.

Teams und dynamische Allianzen. Bündnisse schmieden, gemeinsam kämpfen, Allianzen brechen, gegen gegnerische Allianzen statt nur gegen einzelne Gegner gewinnen – das Herzstück moderner Mehrspieler-Strategie ist in der Amiga-Bibliothek zumindest äußerst selten. Hier ist es Siegbedingung.

Replays und geprüfte Synchronisation. Aus veröffentlichten Amiga-Strategiespielen ist bislang kein vergleichbares System bekannt, das eine vollständige Partie deterministisch als Replay speichert und identisch wieder abspielt. Die deterministische Tick-Architektur dieses Spiels macht genau das möglich – dieselbe Eigenschaft, die Netzwerkpartien mit minimalem Datenverkehr und Prüfsummen gegen Desyncs erlaubt.

Nachweislich faire Computergegner. In den Neunzigern war Schummel-KI Industriestandard: versteckte Rabatte, Karteneinsicht, Ressourcenboni auf hohen Schwierigkeitsgraden – auf dem PC wie auf dem Amiga. Eine KI, die denselben Sichtregeln unterliegt wie der Spieler, und deren Fairness ein automatisierter Test beweist, war schon historisch ungewöhnlich und ist auf dem Amiga in dieser nachweisbaren Form nicht bekannt.

Benannte Gegner-Charaktere statt Schwierigkeitsregler. Gegner mit Namen, eigener Doktrin, eigenem Funkstil und eigener Spielstärke, deren Strategie man durch Aufklärung erst herausfinden muss – dieses Prinzip machten Siedler-Nachfolger und Anno erst nach der Amiga-Ära populär. Auf dem Amiga ist dieses Modell in vergleichbarer Form nicht bekannt.

Sichtbare Modulschäden am selbst entworfenen Schiff. Vorläufer der Schiffskonstruktion gab es auf dem Amiga durchaus – K240 etwa ließ Schiffe ausrüsten, und das Tagebuch soll fair bleiben: Die Idee ist nicht vom Himmel gefallen. Aber dort war ein Schiff eine Menüzeile und Schaden ein schrumpfender Balken. Ein Schiff, dessen Module sichtbar in die Hülle integriert sind, einzeln getroffen werden können und deren Ausfall man dem Schiff ansieht (leer, belegt, beschädigt) – ist auf dieser Plattform in dieser Verbindung zumindest außergewöhnlich.

Fünf Sprachen in einem Spiel, Sprachausgabe getrennt wählbar. Lokalisierung hieß damals: getrennte Verkaufsversionen je Land, häufig nur die Anleitung übersetzt. Fünf wählbare Textsprachen plus zwei wählbare Sprachausgaben in einer einzigen Version, sauber über Text-IDs von der Spiellogik getrennt – ein Konzept aus einer späteren Zeit, hier für AGA gebaut.

Und hinter den Kulissen: eine Testkultur, die es damals nicht gab. Ein Headless-Simulator, der tausende Partien ohne Grafik durchrechnet, bevor ein Pixel gezeichnet wird; automatisierte Determinismus- und Fairness-Prüfungen; eine dokumentierte Emulator- und Hardware-Testmatrix. Kein Spielfeature – aber der Grund, warum die Features oben eine realistische Chance haben, auf einem 68020 tatsächlich zu funktionieren, statt an denselben Performanceproblemen zu scheitern wie manche historische Portierung.

Acht Merkmale im Zusammenspiel

Ehrlichkeit zuerst: Kaum ein Einzelbestandteil ist für sich genommen neu erfunden. Modulare Schiffe, Forschung, Nebel des Krieges, asymmetrische Fraktionen – all das gibt es anderswo, meist auf dem PC. Die Besonderheit liegt in der Kombination, ihrer konsequenten Verzahnung und der Umsetzung für einen echten Amiga 1200. Acht Merkmale tragen diese Position:

1. Modularität mit echten Konsequenzen. Der Spieler entwirft kein Datenblatt, sondern ein sichtbares Schiff. Jedes Modul braucht Energie, kann gezielt beschädigt werden, fällt sichtbar aus (drei Sockelzustände) und bestimmt die taktische Rolle. Was man einbaut, kann im Gefecht zum Problem werden: Ein Kampfschiff kann erblinden, ein Aufklärer stranden. Und Redundanz ist eine echte Entwurfsentscheidung – der zweite Antrieb macht nicht schneller, er bringt das Schiff nach Hause.

2. Eine durchgehend laufende Welt. Forschung, Logistik, Aufklärung, Produktion und mehrere interaktive Gefechte laufen gleichzeitig, in einer klassischen Fensteroberfläche über der immer sichtbaren Karte. Es gibt keine isolierten Spielmodi – selbst das Kampffenster hält die Welt nicht an.

3. Energie als universelles Bindeglied. Ein einziges System verbindet Rumpfgröße, Reichweite, Modulbetrieb, Notstrom, Kampfbereitschaft, Forschungstempo, Technologiefortschritt (größerer Rumpf erzwingt besseren Reaktor) und Fraktionsbalance. Die Bewegungskosten 1/2/3/4 gegen 2/4/6/8 sind die kürzeste Zusammenfassung des Mensch-Maschine-Konflikts.

4. Echte Asymmetrie mit Leitsatz. Menschen handeln, Maschinen plündern. Maschinen gewinnen den offenen Abnutzungskrieg über Waffenstärke, Reparatur und Assimilation; Menschen gewinnen über Tempo, Wirtschaft, Aufklärung und Technologie. Der Satz ist kein Marketingtext, sondern das Prüfkriterium, an dem jede Zahlenentscheidung gemessen wird.

5. Faire Gegner mit Persönlichkeit. Keine Schummel-KI, per automatisiertem Test nachweisbar. Keine Boni-Schwierigkeitsgrade, sondern benannte Charaktere mit Doktrin und Spielstärke, deren Strategie man erst durch Aufklärung erkennt. Unsicherheit gilt für Mensch und Maschine nach denselben Regeln.

6. Technische Authentizität plus moderne Simulationsdisziplin. PAL-Lowres, AGA, Bobs, Copper-Palettenumschaltung, Color Cycling, Bitmap-Fonts, Integer-Mathematik – und zugleich deterministische Ticks, Lockstep, Prüfsummen, Replays, ein Headless-Balance-Simulator und ein echter A1200 als Referenz. Kein Retro-Look auf moderner Technik, sondern ein echtes Amiga-Spiel mit einer Testkultur, die es damals nicht gab.

7. PC-Mehrspielermechaniken, die es auf dem Amiga nie gab. Teams und Allianzen, die geschmiedet und gebrochen werden, Echtzeit-Partien mit bis zu vier Teilnehmern, Nullmodem und TCP/IP als Varianten derselben deterministischen Architektur, KI-Spieler ohne Netzwerkverkehr in denselben Bündnisstrukturen wie Menschen – auf dem PC seit Jahrzehnten Standard, auf dem Amiga in dieser Kombination eine Premiere. Dazu Lokalisierung ab Werk: fünf Textsprachen und zwei Sprachausgaben als Teil der Architektur statt als nachträgliche Übersetzung.

8. Fraktion, Spieler und Bündnis sind drei verschiedene Ebenen. Menschen und Maschinen sind Regelprofile, keine fest vorgegebenen Mannschaften. Zwei menschliche Spieler können Gegner sein, zwei Maschinenkollektive können konkurrieren, und unterschiedliche Fraktionen können sich zeitweise verbünden. player_id und faction_id bleiben technisch getrennt; Diplomatie bestimmt die tatsächlichen Fronten. Dadurch entsteht keine starre Geschichte von „Menschen gegen Maschinen", sondern eine politische Galaxis mit wechselnden Bündnissen und Interessen.

Weitere Merkmale, die diese Identität stützen

Freies Spiel und Kampagne verfolgen unterschiedliche Dramaturgien. Das freie Spiel ist ein strategischer Wettbewerb um Dominanz, Forschung oder die beste Wertung innerhalb eines Zeitlimits. Die Kampagne legt den Schwerpunkt stärker auf Überleben, Exploration, das Aliengeheimnis, Eskalation und einen möglichen Exodus. Aliens sind dabei keine gewöhnliche spielbare Fraktion, sondern Geheimnis, Bedrohung, Artefaktquelle und Teil der Handlung.

Die Lore entsteht aus Spielobjekten. Wrackfelder, Logbuchfragmente, Datenkerne, Alien-Spuren und verlassene Einrichtungen erzählen die Vorgeschichte der Galaxis indirekt. Der Spieler setzt die Zusammenhänge selbst zusammen, statt sie hauptsächlich in langen Zwischensequenzen erklärt zu bekommen.

Grafik erklärt Gameplay. Ein Modul verändert nicht nur Werte, sondern die sichtbare Konstruktion des Schiffs. Ein beschädigter Sockel zeigt einen tatsächlichen Funktionsverlust. Menschen und Maschinen sollen an Form, Material und Aufbau erkennbar sein, nicht nur an einer Spielerfarbe.

Der erste Prototyp prüft bewusst nur die technische Wirbelsäule. P0 enthält mehrere Spieler und Schiffe, Wegpunkte, gleichzeitige Bewegung, Energieverbrauch, Reichweitenkampf, Waffen-Cooldowns, Zerstörung und Debug-Ausgaben. Forschung, Handel, Außenposten, Tarnung, Kampagne, Audio und Netzwerk werden nicht gleichzeitig hineingezwungen. Erst wenn die Basis deterministisch auf Emulator und echter Hardware funktioniert, wachsen die nächsten Systeme darauf.

In einem Satz: Ein tiefes Echtzeit-Weltraumstrategiespiel für den echten Amiga 1200, in dem selbst konstruierte modulare Schiffe, Energiehaushalt, sichtbare Modulschäden, faire Aufklärung, parallele interaktive Gefechte und asymmetrische Fraktionen ein einziges, durchgehend verzahntes System bilden.

Zwischenstand am 27. Juli 2026

Vorhanden: eine konsolidierte Master-Datei (v36) mit definierter Kernvision; zwei asymmetrische Fraktionen mit Balance-Leitsatz; vier Rumpfklassen und ein 26-Modul-Katalog; Sockelsystem des Schiffseditors; Energie-, Bewegungs- und Schadensregeln; 25 Technologien; Planeten, Asteroiden, Außenposten; der Entdeckungs- und Anomalien-Anhang samt Konzern und Wettrennen; Diplomatie; drei Siegwege; Multiplayer-Grundregeln; KI-Architektur mit Charaktermodell und Fairness-Nachweis; Ereignisbild-Pipeline; Fünf-Sprachen-Architektur; laufende Codex-Implementierung mit Review-Schleife; SDL3-Prototypumgebung; FS-UAE; ein echter Amiga 1200.

Offen: der vollständige spielbare Prototyp; die endgültige Kampfdarstellung (Favorit: interaktives Kampffenster – ausdrücklich noch nicht final, Prototypen entscheiden); die Schild-Schadenspipeline; Netzwerk- und Lockstep-Tests auf echter Hardware; das numerische Balancing über den Headless-Simulator; Audio- und Speicherbudgets samt Paula-Kanalplanung; die eigentliche Amiga-Implementierung; Kampagne und Missionen; Alpha, Beta, Veröffentlichung.

Das Tagebuch endet hier nicht – es fängt hier an. Die Konzeptphase ist erzählt; ab jetzt wird chronologisch dokumentiert, wie aus v36 ein Spiel wird.

Erste Spielmechanismen werden getestet

Der Mix zwischen aus Englisch und Deutsch wird auch gleich behoben.

Funktioniert das Verschieben der Fenster? Öffnen sie sich, wenn man auf Info klickt?
Und dabei fällt gleich ein Bug auf. Das Objektinfo-Fenster und das Schiffsinfo-Fenster zeigen den gleichen Inhalt an.

S1 ist hier ein Schiff und A1 ein Asteroid. K1 steht für Kampfgebiet.

Laufende Einträge

27. Juli 2026 – Das Spiel bekommt einen Namen: Interlock: Sector Command

Ausgangslage. Das Projekt hatte bis heute keinen Namen, nur den spontanen Arbeitstitel „Nova Fulcrum". Für die Entscheidung wurden zunächst Kriterien festgelegt: Der Titel muss in allen fünf Textsprachen aussprechbar sein, auf einen 320×256-Titelbildschirm mit Bitmap-Font passen, in Suchmaschinen auffindbar und markenrechtlich unauffällig sein – und idealerweise etwas vom Spielkern tragen statt nur generisch nach Weltraum zu klingen.

Entscheidung. Das Spiel heißt Interlock: Sector Command. Hauptname und Untertitel folgen dem klassischen Muster von Frontier: Elite II und UFO: Enemy Unknown: Der Hauptname ist eigenständig und trägt die Identität, der Untertitel signalisiert Genre und Ton.

Begründung. „Interlock" (Verzahnung) benennt das Prinzip, das in Teil VI dieses Tagebuchs als eigentliches Alleinstellungsmerkmal herausgearbeitet wurde: Module greifen zu Schiffen ineinander, Schiffe zu Flotten, Flotten, Außenposten und Logistik zu Strategie; Sensoren und Kommunikation verbinden Einheiten, Allianzen verbinden Spieler durch gemeinsame Sicht – und fällt ein Teil aus, verändert sich das gesamte System. Dazu kommt die technische Zweitbedeutung: Ein Interlock ist im Maschinenbau eine Sicherheitsverriegelung, die eine Maschine nur laufen lässt, wenn alle Bedingungen erfüllt sind – exakt die Logik des Energiegesetzes, das vor jedem Feld prüft, ob genug Energie vorhanden ist. „Sector Command" liefert im Untertitel das klassische Strategie-Signal (kurz, verständlich, sofort als Kommandospiel erkennbar) und darf dort generisch sein, weil Generik im Untertitel eine Stärke ist. Sprachlich funktioniert die Kombination in allen fünf Sprachen: „Inter-" und „Sektor" sind universelle Wortbestandteile.

Verworfene Alternativen. Der Weg zur Entscheidung war eine systematische Ausschlusskette. Nova Fulcrum scheiterte an einer für die Zielgruppe fatalen Assoziation: „MiG-29 Fulcrum" erschien 1990/91 gleich zweimal auf dem Amiga – Retro-Veteranen denken bei „Fulcrum" an einen Kampfjet. Aus einer Liste von 24 ChatGPT-Vorschlägen fielen unter anderem: Dark Signal (belegt durch ein Steam-Weltraum-Horrorspiel), Red Directive (durch Star Trek: Discovery besetzt), Iron Horizon (World-of-Tanks-Season plus zwei Tabletop-Wargames), Helion (Steam-Shooter plus das Fusionsunternehmen Helion Energy – bedauerlich, denn „Helion" ist der physikalische Fachbegriff für den Helium-3-Kern und wäre die perfekte Ein-Wort-Zusammenfassung des Energiesystems gewesen). Sector Command allein war zu generisch: Der Begriff gehört kulturell Star Wars, und mit „Sector Command 4400" existiert bereits ein Weltraum-Strategiespiel ähnlichen Namens. Die Finalisten Sectorfall (sauberstes Kunstwort, maximal auffindbar) und Cold Alliance (benennt die Allianz-Premiere) unterlagen inhaltlich: Nur „Interlock" fasst das Spielprinzip selbst in ein Wort. Eine wichtige Nebenerkenntnis der Suche: Praktisch jedes existierende, schöne Einzelwort ist nach vierzig Jahren Spieleindustrie vergeben – die Amiga-Klassiker (Xenon, Deuteros) lösten dasselbe Problem bereits mit Kunstwörtern und Prägungen.

Technischer Stand. Kollisionsprüfung per Websuche am 27. Juli 2026: kein kommerzielles Videospiel namens „Interlock"; bekannte Nachbarn sind das „Interlock System" (das Tabletop-Regelwerk hinter Cyberpunk 2020) und die Puzzlespiele „Interlocked" – beides andere Kategorien. Die Wortkombination „Interlock: Sector Command" ist unbelegt. Ein erster Titelbild-Entwurf in Pixeloptik (Blockschrift, Copper-Balken) wurde skizziert.

Ergebnis. Das Projekt hat einen verbindlichen Namen, der in die Master-Datei übernommen werden kann. Präsentationen, Logo-Entwürfe und der Titelbildschirm können darauf aufbauen.

Offene Punkte. Die bisherige Prüfung war eine Websuche, keine Markenrecherche – vor einer Veröffentlichung sollten die einschlägigen Markenregister (DPMA, EUIPO) geprüft werden. Außerdem offen: der Schriftzug im echten Bitmap-Font auf 320×256, die Frage, ob der Untertitel pro Sprache lokalisiert wird oder englisch bleibt, und die Übernahme des Titels in Master-Datei und Repository.

Format künftiger Einträge

Datum – Titel des Entwicklungsschritts

Ausgangslage – Welches Problem oder Ziel bestand? Entscheidung oder Umsetzung – Was wurde beschlossen, gebaut oder geändert? Begründung – Warum diese Lösung? Verworfene Alternative – Was wurde geprüft und weshalb nicht übernommen? Technischer Stand – Dateien, Master-Version, Commits, Tests. Ergebnis – Was funktioniert nach diesem Schritt? Offene Punkte – Was ist als Nächstes zu klären oder zu testen?

Anhang: Chronik der wichtigsten Stationen

Teil VII – Der Sommer wird technisch (30. Juli – 9. August 2026)

30.–31. Juli – Eine Konzeptdatei wird zur Dokumentenarchitektur

Mit wachsendem Umfang zeigte die Master-Datei ein Problem, das ihr eigener Erfolg verursacht hatte: Sie war auf 138 KB und beinahe 3.000 Zeilen angewachsen – Spielregeln, Technik, Oberfläche, KI, Missionen, Roadmap und Änderungsverlauf, alles in einer einzigen Datei. Zwei Schritte lösten das.

Der erste: Master und Balancing wurden getrennt, nach dem bewährten Vorbild aus dem Landwirtschaftsprojekt. Die Master-Datei behält Mechanik, Architektur und verbindliche Ausschlüsse; eine eigene Balancing-Datei übernimmt alles, was reine Zahl ist – Kosten, Schäden, Reichweiten, Energiewerte. Die Vorrangregel ist seither so einfach wie wirksam: Mechanik kommt aus dem Master, Zahlen aus dem Balancing. Das allein macht das spätere Zahlen-Tuning über Simulator und Hardware ungefährlich, weil ein verstellter Wert nie mehr aus Versehen zur Regeländerung wird.

Der zweite, radikalere Schritt folgte einen Tag später: Master v42 löste die verbliebene Datei komplett auf. Übrig blieb eine schlanke Leitdatei von nur noch 119 Zeilen, die lediglich die Vorrangordnung regelt; die eigentlichen Inhalte verteilen sich seither auf eigene Dokumente für Design, Technik, Oberfläche, Missionen, KI, Balancing und Roadmap. Aus einer wachsenden Konzeptdatei wurde damit endgültig eine geführte Softwaredokumentation – derselbe Reflex, der zwei Monate zuvor schon zur ersten Konsolidierung (v22) und zur Balance-Gegenprüfung geführt hatte, jetzt konsequent zu Ende gedacht.

Ende Juli bis Anfang August – Der Prototyp lernt laufen

Parallel zur Aufräumarbeit an den Dokumenten wuchs der SDL3-Prototyp von einer statischen Fensterdemonstration zu etwas, das sich zunehmend wie das eigentliche Spiel anfühlte: eine Hauptkarte mit Auswahlzuständen, ein Ereignisfenster, ein eigenständiges Kampffenster – und, ganz wichtig, kein zweiter Simulationskern nur für die Anzeige. Der Kampfbereich reicht Aktionen an denselben Kern weiter, der auch für Headless-Tests und spätere Netzwerkpartien vorgesehen ist; sichtbarer Kampf und tatsächliche Regeln können dadurch strukturell nicht auseinanderlaufen.

Mit derselben Ausbaustufe kamen erste sichtbare Abläufe für Abbau und Entladen hinzu, und die Auswahl wurde technisch dreigeteilt: das eigene Befehlsschiff, das aktuelle Befehlsziel, und – neu – ein Objekt, das man nur betrachtet. Diese dritte Kategorie erlaubt es, ein fremdes Ressourcenfeld zu inspizieren, ohne dabei versehentlich den eigenen Auftrag zu verändern. Ausdrücklich festgehalten wurde dabei, was diese Wirtschaftselemente nicht sind: keine stille Erweiterung des bewusst kleinen P0-Simulationsumfangs, sondern reine Bedienprototypen für die Oberfläche.

2. August – Ein Screenshot deckt eine überholte Doppelstruktur auf

Die Fenster selbst bekamen an diesem Tag eine spürbar Amiga-ähnlichere Gestalt: hellere Rahmen, klassischere Titelleisten, deutlicher erkennbare Schließgadgets, eine ruhigere Farbwirkung insgesamt – näher an Intuition als je zuvor.

Der eigentlich interessante Fund kam aus der Betrachtung des Screenshots selbst, nicht aus geplanter Codearbeit: Die Fenster „Objektinfo" und „Schiffsinfo" zeigten identischen Inhalt. Die erste Vermutung – beide Fenster müssten klarer getrennt werden – erwies sich als falsch gestellte Frage. Die Codeprüfung zeigte etwas Grundsätzlicheres: „Schiffsinfo" war eine ältere Spezialansicht aus der Zeit vor dem allgemeinen Objektadapter, technisch längst ein Fossil. Beide Fenster liefen über denselben Zustand, denselben Datenadapter, denselben Renderpfad – „Schiffsinfo" hatte keine eigene Existenzberechtigung mehr.

Die Lösung war deshalb keine Trennung, sondern eine Streichung. Übrig blieb ausschließlich „Objektinfo", gespeist über info_type und info_id, zuständig für eigene, fremde und zerstörte Schiffe, Ressourcenfelder, Außenposten und Gefechtsorte. Die Auswahl des eigenen Befehlsschiffs (command_ship_id) und das aktuelle Befehlsziel (target_type/target_id) bleiben davon strikt getrennt – wer ein Objekt nur betrachtet, verändert nie versehentlich Auswahl oder Auftrag.

Der Vorfall ist ein kleines Lehrstück für sich: Ein Screenshot, eigentlich zur Kontrolle der neuen Fensteroptik gedacht, deckte eine überholte Codestruktur auf, die niemand aktiv gesucht hatte. Die Bereinigung machte die Oberfläche nicht komplizierter, sondern einfacher – eine historische Doppelstruktur verschwand, ohne dass irgendetwas Neues dafür entstehen musste.

Direkt sichtbar wurden dabei zwei neue, kleinere Probleme: Ein geöffnetes Objektinfofenster verschwindet noch fälschlich bei jedem Kartenklick, statt bis zum expliziten Schließen offen zu bleiben. Und in bestimmten Fenstergrößen läuft Text über den Innenbereich hinaus – gerade die neue, klarere Rahmengestaltung macht sichtbar, dass Textlayout und Innenabstände robuster werden müssen. Beide Punkte bleiben offene Korrekturaufgaben.

Bis 6. August – Die Technik zieht nach, der Kern bleibt stabil

Parallel zur Modularisierung wurde die technische Fachdatei weiter ausgebaut: Architektur, Datenmodelle, Umsetzungsreihenfolge, Build- und Teststrategie. Der Stand ist fortgeschritten, aber noch nicht abgeschlossen. Verbindlich bleibt dabei die technische Grundrichtung, die sich seit Mai kaum verändert hat, nur präzisiert wurde: deterministische Echtzeitsimulation im Ein-Sekunden-Tick, der A1200 als Referenzhardware, Nullmodem für zwei und TCP/IP für bis zu vier Teilnehmer, vollständige Weltsimulation auf jedem Rechner statt eines Servers, Befehlsübertragung statt Weltzustands-Synchronisation, explizite Big-Endian-Serialisierung, semantische Prüfsummen und Replays, sowie Emulator- und Hardwaretests nach jedem technischen Meilenstein.

Projektstand am 6. August 2026. Erreicht: ein verbindlicher Titel, eine modulare Source of Truth (Master v42 plus Fachdateien), getrennte Balancing-Datei, ein spielnaher SDL3-Prototyp mit Amiga-ähnlicher Optik, ein bereinigtes einheitliches Objektinfofenster, erste systematische UI-Prüfung anhand echter Screenshots. Offen: das Fensterverhalten bei Klicks, überlaufender Text, die noch nicht abgeschlossene technische Fachdatei, Determinismus-, Savegame-, Replay- und Netzwerkprüfungen, Emulator- und Hardwareabnahmen für die nächsten Meilensteine, und die endgültige Form des Kampffensters, die weiterhin von echten Bedientests abhängt.

Der eigentliche Fortschritt dieser Wochen ist kein einzelnes Feature. Es ist eine belastbare Dokumentenordnung, ein zunehmend spielbares Gefühl im Prototyp, und eine Arbeitsweise, bei der jedes sichtbare Ergebnis sofort gegen Bedienlogik, Architektur und die Grenzen des Amiga geprüft wird.

9. August – Der erste Savegame-Test besteht auf echtem Amiga-Terrain

Ein technischer Meilenstein, der sich von allem zuvor unterscheidet: Zum ersten Mal lief das Savegame-System nicht nur auf dem Host, sondern sichtbar in einer Amiga-Umgebung – im Emulator FS-UAE, auf einem emulierten Amiga 1200, mit dem Testlauf INTERLOCK:amiga_savegame_test.

Der Testlauf bestand sieben Teilprüfungen nacheinander: Speichern und Laden liefern denselben semantischen Zustand (ROUNDTRIP), ein bestehender Spielstand lässt sich kontrolliert ersetzen (REPLACE), die Integritätsprüfung des Containers funktioniert (CRC), abgeschnittene Daten werden erkannt (TRUNCATED), die Dateikennung wird korrekt geprüft (MAGIC), der Nutzdatenblock wird gültig verarbeitet (PAYLOAD), und der Ladevorgang bleibt robust, ohne einen unvollständigen Zustand zu übernehmen (ATOMIC LOAD). Am Ende: ALL TESTS PASS.

Was diesen Moment über eine bloße grüne Statuszeile hinaushebt: Er bestätigt zum ersten Mal praktisch, was seit Mai nur Architekturentscheidung war. Die explizite Big-Endian-Serialisierung, die semantischen Prüfsummen, der Verzicht auf rohe C-Struktur-Speicherung – all das war bisher Papier. Jetzt funktioniert es sichtbar im Amiga-Kontext, nicht nur auf dem Host. Für ein deterministisches Strategiespiel, das Plattformgleichheit zwischen Host und Amiga anstrebt, ist das der bisher konkreteste Nachweis, dass diese Wette aufgeht.

Die bekannte Einschränkung bleibt: FS-UAE ist nicht die reale Hardware. Aber der Weg von der konzipierten Serialisierung zur sichtbaren Plattformvalidierung ist damit ein gutes Stück kürzer geworden – und die drei-stufige Testkette Linux → Emulator → echter A1200 hat ihren zweiten Schritt zum ersten Mal tatsächlich bestanden, nicht nur geplant.