Warum ich HeavyMach
neu aufgebaut habe

Ich wählte Entwicklung als meinen dritten Beruf. 2015 arbeitete ich als Journalist bei einem Zeitschriftenverlag, 2016 auf den Philippinen. Im Juli 2017 wechselte ich zur iOS-Entwicklung. Die Welt, die ich in Tätigkeiten fern von Software erlebt hatte, war für mich nichtdeterministisch und irrational. Es gab mehrere Gründe, dieses Leben abzuschließen und einen anderen Beruf zu wählen.

Die Ereignisse, die mich noch stärker als HeavyMach beeinflussten, erlebte ich beim Verlag. Die schwer ersetzbaren Fähigkeiten der Editorial-Designer ermöglichten es ihnen, sich gemeinsam gegen die Führung aufzulehnen. Danach verbesserten sich ihre Arbeitsbedingungen. Abgesehen von den beiden Tagen, an denen die Monatsausgabe fertiggestellt wurde, durften sie garantiert pünktlich gehen. Diese Erfahrung beschrieb ich auch in Ausgabe 9, „Der Preis des Ungehorsams“.

Einen Monat später platzte dem Chefredakteur bei einem Trinkabend der Kragen. Er sagte, es sei unmöglich, mit sechs Leuten jeden Monat drei Monatszeitschriften und eine Tageszeitung fertigzustellen und zusätzlich zu recherchieren, und alle machten jeden Tag Überstunden. Das Ergebnis fiel entgegengesetzt aus. Die gesamte Redaktion wurde angewiesen, einen Monat lang nicht vor zehn Uhr abends Feierabend zu machen. Es war eher eine Vergeltungsanweisung, weil man sich unbeliebt gemacht hatte, als eine formale Disziplinarmaßnahme.

Dazu kam, was ich bei Interviews mit Führungskräften von Unternehmen der Fabrikautomation wie Rockwell Automation, B&R und Yokogawa sah und hörte. Es ging um den Nutzen, den Automatisierung durch Ingenieurtechnik bringt. Auch diese journalistischen Erfahrungen beeinflussten meine Entscheidung für den Entwicklerberuf.

Wenn ich mit Bekannten Soju trinke, höre ich manchmal, ich hätte mein Leben mit einem Sprung in den Tod beendet, wenn ich die Arbeit von 2015 und 2016 weitergemacht hätte. Ich weiß immer noch nicht, ob sie recht haben.

Die beiden Schöpfer von HeavyMach haben mein Leben um neun Jahre und drei Monate verlängert.

In letzter Zeit habe ich das Gefühl, dass mir nicht viel Zeit bleibt. Das liegt weder an gesundheitlichen Problemen noch an extremer Antriebslosigkeit. Im Gegenteil: Mein Geist fühlt sich klarer an als vor einem Monat, zwei Monaten oder einem halben Jahr. Deshalb überlege ich, was ich jetzt versuchen und was ich hinterlassen möchte. Die Restaurierung von HeavyMach ist eine meiner Entscheidungen. Ein Spiel zeigte mir einst eine Richtung; nun bringe ich es, selbst Entwickler geworden, wieder zum Laufen. Für mich kehrt diese Verbindung am Ende zum Anfang zurück.

2026 baute ich ein 2009 erschienenes Spiel neu auf, das mir einen Weg gezeigt hatte. Es ist nicht mehr im App Store zu finden, und kaum jemand in meinem Umfeld erinnert sich daran. Ich wollte es auf meinem heutigen iPhone wieder ausführen. Ich ließ Codex den Quellcode neu schreiben und wies immer wieder auf Verhalten hin, das vom Original abwich, damit es korrigiert wurde.

Jemand namens mesabloo hatte ein ähnliches Projekt begonnen. Er beschaffte die Assets von HeavyMach Defense und schrieb den Quellcode von Grund auf neu. Es sah aus, als habe er bei der Implementierung der Kampfalgorithmen zwischen Einheiten aufgehört. Mein Ausgangspunkt war besser als seiner, weil er den Quellcode vollständig neu schreiben musste.

An einem Wochenende hatte ich im Schlaf einen Traum. Darin sah ich mich aus der Perspektive eines Dritten, wie ich zum ersten Mal mit iPod touch und Cydia in Berührung kam. Nach dem Aufwachen gab ich heavy Mach bei Google ein. Gemini in der Google-Suche nannte mir eine spezialisierte Webarchiv-Seite, von der ich das ursprüngliche HeavyMach bekommen konnte. Das war der Anfang dieses Restaurierungsprojekts. Ich begann die Restaurierung mit einem HeavyMach-1.13-Build aus der HeavyMach-Sammlung im Internet Archive (archive.org).

Deshalb glaube ich, dass ich fast nichts gemacht habe. Auch deshalb halte ich es für umso unangebrachter, damit Geld verdienen zu wollen. In meinen eigenen Worten: Ich habe Codex lediglich am Kragen gepackt und ihm eine Ohrfeige verpasst, wenn es vom ursprünglichen Quellcode und der ästhetischen Leistung der Schöpfer abwich und eigenmächtig etwas Falsches tat.

Falls ein ursprünglicher Urheber oder ein anderer Beteiligter verlangt, die Veröffentlichung zu beenden, werde ich dieses Repository ohne Bedauern löschen.

Ich weiß nicht, was der Entwickler der Reihe, Byun Hae-jun, und der Illustrator Park Jae-cheol von diesem Restaurierungsprojekt halten. Auf einem Messenger-Profil, das Park Jae-cheol selbst zu gehören schien, hinterließ ich eine Anfrage. Als ich darüber in der Entwicklererklärung schrieb, war noch keine Antwort eingegangen.

Zu Beginn kannte ich Byun Hae-jun und Park Jae-cheol als die Schöpfer. Deshalb notierte ich zunächst ihre Namen. Mesabloos Restaurierungsprojekt kannte ich, aber dass WeMade die IP von HeavyMach übernommen hatte, erfuhr ich erst, als ich diesmal die Credits zusammenstellte.

2011 erwarb WeMade Creative, eine Tochter von WeMade Entertainment, die Vermögenswerte von Indiapps einschließlich der IP von HeavyMach und HeavyMach 2. In den Credits sind ursprüngliche Entwicklung, Illustration und spätere Übernahme getrennt aufgeführt.

In der ersten Implementierung speicherte das Spiel jedes Mal eine Datei, wenn der Panzer schoss oder getroffen wurde. Meldungen über veränderte Munition oder Erfahrung führten direkt zu Dateischreibvorgängen. Ich fragte: „Bei jedem Schuss eine Datei speichern?“ Codex trennte Speicheraktualisierung und Dateispeicherung und änderte es so, dass beim Wählen eines Slots, beim nächsten Abschnitt, bei Game Over oder beim Zurückkehren ins Menü gespeichert wird. Danach verzeichnete der automatische Test null Speichervorgänge während 180 Frames Schießen und einen beim Zurückkehren ins Menü.

In der lauffähigen Fassung des Originals, deren korrektes Verhalten ich selbst geprüft hatte, gab es keine Frame-Einbrüche, in der frühen restaurierten App dagegen schon. Ich fragte, ob es überhaupt sinnvoll sei, Spielgrafik mit UIKit zu zeichnen, und verlangte den Vergleich mit dem bestehenden Pfad. Codex ersetzte die Bilderzeugung auf der CPU in jedem Frame durch OpenGL und bereitete Texturen zur Wiederverwendung vor.

Auch nach dem Wechsel des Renderverfahrens kam es beim Schießen zu Verzögerungen, deshalb untersuchte Codex die Ursache weiter. Codex maß die Aufrufe zum Neustart von Effekten und ermittelte den Aufwand für den Wiedergabestart mit AVAudioPlayer. Es änderte den Ablauf auf vorab vorbereitete Puffer und Quellen in OpenAL. Den fehlenden Ton beim Waffenwechsel behob es, indem es die ausgelassenen Aufrufe zur Wiedergabe der Soundeffekte ergänzte.

Ich fragte auch, warum eine aufsummierte Zeitberechnung eingebaut worden war. Bei Verzögerungen aktualisierte diese Implementierung den Spielzustand zwischen zwei Anzeigeaufrufen mehrfach. Dadurch änderte sich das ursprüngliche Bewegungs- und Schussgefühl. Codex änderte den Ablauf so, dass der Spielzustand bei jedem gezeichneten Bild einmal aktualisiert wird. Beim Sperren und Wechsel in den Hintergrund stoppen Spiel, Ton und gehaltene Eingaben; nach der Rückkehr setzt der Spieler selbst fort.

Ich verlangte, eine breitere Welt zu zeigen, statt die Grafik zu vergrößern. Auf dem breiteren Bildschirm musste man auch in den neu sichtbaren Bereichen links und rechts an die berührte Stelle schießen können. Menühintergründe und Missionsergebnisse mussten ebenfalls den breiteren Bildschirm füllen. Ich sah mir die Bilder an und zeigte nicht zusammenpassende Grenzen und schwarze Linien. Auch den Menüübergang, bei dem alter und neuer Bereich getrennt öffneten und schlossen, ließ ich korrigieren. Codex änderte die vier Elemente, die sich wie Türen schließen, so, dass sie den gesamten Bildschirm bedecken.

In Mission 3-5 kam der Flugzeugboss zu schnell nach links und kehrte schlecht nach rechts zurück. Codex hielt den gemeinten Gegner zunächst für einen Hubschrauber. Erst nachdem ich es als Flugzeug richtiggestellt hatte, verglich es den betreffenden Boss. Der breitere Bildschirm erfüllte die Sichtbarkeits- und Kampfstartbedingungen zu früh. Codex trennte die Bedingungen und behob es so.

Es gab auch das Problem, dass Luftunterstützung hinter dem Panzer statt am berührten Punkt einschlug. Künstliche Koordinaten beim Loslassen flossen in die Berechnung der Angriffsposition ein. Codex trennte Eingabeende und Zielkoordinaten und behielt die letzte Angriffsposition bei. Ich verlangte außerdem einen Ablauf, der alle Waffen in der Cheat-App prüft. Selbst bei richtigen Kernberechnungen konnte tatsächliches Drücken und Loslassen ein anderes Ergebnis erzeugen.

Die Illustrationen nach Missionsende waren mir in Erinnerung geblieben. Als ich ihr Fehlen bemerkte, korrigierte Codex die Zuordnung von JPG- und PNG-Endungen in Ressourcennamen. Danach prüfte ich die Bilder auf dem echten Telefon. Als auf dem breiteren Bildschirm das Schlachtfeld außerhalb der Illustration sichtbar wurde, korrigierte Codex Hintergrund und Anzeigebereich, sodass die Ergebnisansicht den gesamten Bildschirm bedeckte.

Spielcode und Ressourcen sollten auf iPhone, iPad und Mac gemeinsam genutzt werden. Wenn Bewegung, Ballistik, Schaden und Gegnerplatzierungen für jedes Gerät kopiert werden, kann eine Korrektur auf einer Seite auf der anderen fehlen. Codex fasste gemeinsamen C++-Kern, Apple-Laufzeit und Ressourcenbundle in einem Workspace zusammen. Der Spielcode wird über statische Frameworks eingebunden; Bilder, Ton und Karten nutzen dasselbe Bundle. Die Mac-App wurde mit AppKit erstellt.

Auf iPhone kamen Querformatdrehung sowie Berührung, Neigung und Tastatur hinzu, auf iPad die gemeinsame Nutzung von Berührung, Neigung und Tastatur. Mac unterstützt Fenster- und Vollbildmodus. Bewegung, Springen, Rohrverstellung, Schießen, Waffenwahl und Menüs wurden der Tastatur zugeordnet; Shift ermöglicht feinere Winkeländerungen.

Reguläre und Cheat-Validierungs-App werden getrennt installiert. In der Cheat-App kann man Mission, Waffen, Bauteile und Verbesserungen vorgeben und muss nicht das Spiel von vorn wiederholen, um denselben Gegner zu sehen. Bewegung und Schießen laufen jedoch über dieselben Verarbeitungspfade. App-IDs und Speicherdaten sind ebenfalls getrennt.

Auf Mac beschrieb Codex einmal einen Fehler des Prüfwerkzeugs so, als gebe es ein Problem mit dem gesamten Spiel. Ich verlangte, zuerst die Tests des tatsächlichen Spiels abzuschließen. Als die Signierung über die CLI scheiterte, wies ich darauf hin, dass es zuvor über Xcode gelaufen war. Codex prüfte Team, Signierung und Gerätezustand der erfolgreichen und gescheiterten Wege getrennt und setzte danach die Installation fort.

Ich gab Yak, Harrier und F35 vor und verlangte die Farben und Textur der bestehenden Einheiten. Von einer Neuinterpretation der Form war keine Rede. Dennoch ergänzte Codex in der ersten Generierungsanweisung selbst Bedingungen wie von realen Vorbildern inspirierte Maschinen, breite, flache Silhouetten und übertriebene Panzerplatten. Es nahm zwar die vorhandene Hubschraubergrafik als Referenz, aber keine Fotos oder Zeichnungen der tatsächlichen Flugzeuge.

Ich fragte, warum die Formen von den realen Modellen abwichen. Codex ergänzte Regeln zum Erhalt der realen Gestalt. Fotos und Zeichnungen sollten die Form bestimmen, die vorhandenen Spielbilder dagegen Farbe und Textur. Es verglich Lage und Proportionen von Nase, Flügeln, Leitwerk und Lufteinlässen. Nachdem ich die neuen Entwürfe geprüft hatte, verlangte ich dieses Verfahren auch für künftige reale Einheiten.

Was Ästhetik, visuelle Elemente und Ton angeht, verlässt sich Codex meiner Ansicht nach zu stark auf den Stil von OpenAIs Bildgenerierungsmodell, selbst wenn perfekt funktionierender Quellcode, Assets und visuelle Hinweise wie Sprites vorhanden sind. Lux Lunae war ein vergleichsweise glücklicher Fall. Bei Yak, Harrier und F35 nahm ich an, ein Mensch würde die Originaldesigns ansehen und etwas Ähnliches darstellen. Die Hinweise waren schließlich vollständig vorhanden. Stattdessen kamen Science-Fiction-Darstellungen in der entgegengesetzten Richtung, sogar Entwürfe, die meine Vorgaben ignorierten, und ich musste mich damit herumschlagen.

Nachdem ich 2025 meine letzte Firma verlassen hatte, fuhr ich mit dem Motorrad durch das ganze Land. Anders als in Seoul oder Gyeonggi fühlt sich eine Fahrt auf regionalen Nationalstraßen und menschenleeren Wegen zwischen Feldern, bei der man auf Mondlicht angewiesen ist, nicht wie bloßes Reisen oder ein Tapetenwechsel an. In einer Dunkelheit, in der ich nicht einmal meine eigene Hand sehe, die Straße nur anhand von Mondlicht und Scheinwerfer einzuschätzen, kann die Illusion erzeugen, es gebe auf der Welt nur mich und das Motorrad.

Wenn man auf einer schmalen, unbekannten Straße mit 120 Kilometern pro Stunde fährt, leert sich der Kopf automatisch, um zu überleben. Vielleicht kommt es einem extremen Meditationszustand nahe, in den der Körper angesichts des Todes instinktiv gerät. An einem Ort, den man noch nie besucht hat, sieht man vor sich nur Mondlicht; in diesem Licht in völliger innerer Versenkung zu fahren, verändert einen Menschen. Das Wort Mondlicht wurde zu einem eigenartigen Symbol in meinem Leben.

Meine Reise unter Mondlicht und Namcos Entscheidung, die Bossstaffel in 8 Lux Lunae zu nennen, sind wohl Zufälle: unabhängige Ereignisse mit null Zusammenhang. Dass einer der Hauptgegner und eines der visuell eindrucksvollen Symbole eines Spiels, auf das ich wartete, diesen Namen trägt, ist ebenfalls Zufall.

Vom Gameplay her war 8 ein gut gemachtes Werk, das meine Grundannahme „Ich sterbe ein bisschen später“ nicht zerstörte. Lux Lunae verband ein visuell gut gestaltetes Äußeres mit entsprechend mörderischem Können und Dialogen der Schauspieler, denen man gern zuhörte. Das gesamte Spiel zeigte eine umfassende Ausarbeitung, und Lux Lunae als eines seiner Symbole trug dazu bei.

Ich wollte die Bedrohung und Faszination nachbilden, die ich im direkten Kampf empfunden hatte. Wenn ich heutige Popkultur betrachte, glaube ich, dass verdrehte, mächtige und dennoch faszinierende Bösewichte länger im Gespräch bleiben als nur sympathische Hauptfiguren oder die Guten. Ich denke, Josh Brolin in Sicario und die F-22 in Transformers dienen ebenfalls dieser Absicht.

F-22, Su-57 und MiG-31 waren unter den Flugzeugen von Lux Lunae in 8 die Typen, die am stärksten nach Gegenspielern wirkten. Allerdings überlege ich manchmal, ob ich nicht einen anderen Entwurf wie F-16 oder Typhoon hätte aufnehmen sollen, um mehr Unterschied zu schaffen. Im Großen wirken die drei Designs auf mich ähnlich.

Im Original greifen eine recht schwierige Bosseinheit und gewöhnliche Einheiten aus anderen Abschnitten gemeinsam an. Ich fand diese Zusammenstellung etwas gewöhnlich. Bevor ich beim Zeitschriftenverlag, meinem ersten Arbeitgeber, anfing, bestand ich einmal die Vorauswahl der Bewerbungsunterlagen für eine Game-Planning-Stelle bei Netmarble. Auch diesmal dachte ich aus der Perspektive von Spielerfahrung und Spielplanung.

Mit möglichst wenig Eingriffen in Originalassets, Verhaltenscode und ursprüngliche Spielerfahrung wollte ich zwei Wirkungen erzielen. Ich wollte die Bosskämpfe schwieriger machen. Außerdem wollte ich während der Bosskämpfe und in den Abschnitten davor Spannung schaffen, indem Gegner erscheinen, die zwar die Designsprache der bisherigen Feinde teilen, in Erscheinung und Leistung aber fremdartig wirken und schwer zu töten sind.

Die drei Senkrechtstartertypen wurden zwischen Platzierungen eingefügt, ohne ursprüngliche Gegner zu ersetzen. Sie nutzen Bewegung und Bewaffnung der bestehenden Hubschrauber. Codex berechnete die Ergänzungen mit 113 Maschinen in 14 Teilmissionen. Die 1.182 bisherigen Gegnerplatzierungen blieben erhalten. Jäger in Lux-Lunae-Lackierung kamen als Verstärkung in Bosskämpfen und im letzten Bereich der jeweils vorherigen Mission hinzu.

Die Jäger verwenden die vorhandenen Hubschrauberraketen mit zusätzlichen Salven. Die Haltbarkeit wurde auf das 1,7-Fache des Maximums regulärer Hubschrauber und die Raketengeschwindigkeit auf 25% mehr festgelegt. Die Erhöhung der Feuerrate ließ ich von ursprünglich 25% auf 10% reduzieren. Nachdem ich in der regulären App sah, dass Maschinen plötzlich innerhalb des Bildschirms auftauchten, verlangte ich eine Korrektur. Jetzt fliegt das gesamte Flugzeug von außerhalb des rechten Bildschirmrands ein.

Unter dem Gesichtspunkt, den Originalquellcode möglichst wenig zu verändern oder abzustimmen und dessen Gefühl zu erhalten, gehen Lux Lunaes Bewegungs- und Waffenabläufe meiner Ansicht nach nicht über das Original hinaus. Die schnelle Anfluggeschwindigkeit von außerhalb des Bildschirms gab ich nicht vor. Sie erinnerte mich aber in gewissem Maß an Lux Lunaes schnelle Hit-and-run-Angriffe und bösartige Kurvenkämpfe in Ace Combat 8, deshalb ließ ich sie ohne Korrektur stehen. Die damals beim Einflug zusammengedrängte Formation wurde in v0.16 durch weiter auseinanderliegende Startpositionen und Einflugziele korrigiert. Nach Kampfbeginn können sich die Maschinen weiterhin um den Spieler sammeln.

Neben mehr Aufmerksamkeit für Bewegung und Ausweichen wollte ich bei Bossen, die zuvor mit Kontrolle, Standardbewaffnung und genügend Zeit zu schaffen waren, die Anspannung erzeugen: „Jetzt brauche ich wirklich eine Spezialattacke, oder ich muss einmal tief durchatmen und mich konzentrieren.“ Selbst ich, der Spezialattacken fast nie oder nur aus Bequemlichkeit einsetzte, nutzte sie gegen die zusätzlichen Gegner tatsächlich aktiv, um weiterzukommen.

Ich überlege, ob auch ungewöhnliche Verhaltensalgorithmen sinnvoll wären, etwa aus der Karte zu fliehen und wieder aufzutauchen. Derzeit ist der Einflug von außerhalb des Bildschirms korrigiert; das Verlassen und Zurückkehren ist eine Idee für später.

Wie genau kann ein Design entstehen, wenn ich ausschließlich per Text Regie führe? Kann vorhandener Quellcode für funktionierende neue Funktionen wiederverwendet werden? Können vorhandene Assets für funktionierende visuelle Effekte eingesetzt werden? Welcher Prozentsatz der Elemente, vom Design bis zum Verhalten der Einheiten, ignoriert meine Anweisungen? Das waren die technischen Punkte, die ich untersuchen wollte.

Anders als bei meinen übrigen Projekten wollte ich zudem sehen, wie weit allein Modellleistung und vorhandener Quellcode reichen, ohne gesonderte Harness- oder Agenteneinstellungen. Tatsächlich gelangten Gegner ins Spiel, die Waffen und Bewegungen vorhandener Hubschrauber wiederverwenden. Gleichzeitig musste ich Entwürfe neu erstellen lassen, die meine Vorgaben zur Flugzeugform und zu Farben und Texturen des Originals missachtet hatten.

Auch bei einer Arbeit mit großer persönlicher Bedeutung prüfte ich ständig, wie genau Codex meine Anweisungen befolgte. Ob es bestehenden Code und Bilder richtig gelesen und wiederverwendet hatte und ob es die gewünschte Erscheinung und Bewegung umsetzte, beurteilte ich direkt am Ergebnis. Falsche Entwürfe ließ ich neu erstellen; den schnellen Einflug der Jäger behielt ich bei.

Der Abstand beim Einflug ist korrigiert, doch das Zusammendrängen im Kampf bleibt bestehen. Ich überlege weiterhin, Verhalten zum Verlassen des Bildschirms und erneuten Angreifen hinzuzufügen. Beide Spiele haben auch die Kämpfe in HeavyMach beeinflusst. Ich spiele selbst weiter, um zu entscheiden, was ich als Nächstes ändere.

Die hier behandelte öffentliche Fassung ist v0.16 mit Stand vom 29. Oktober 2026. Sie enthält die Bodeneinheiten, den HUD-Editor, das neue Symbol und korrigierte Abstände beim Formationseinflug. Codex aktualisierte reguläre und Cheat-Apps auf iPhone und iPad drahtlos und erhielt bestehende Spielstände und HUD-Layouts. Beim eigenen Spielen auf beiden Geräten bemerkte ich keine Auffälligkeiten.

Während der früheren Restaurierung bestand Codex auf Mac 33 Prüfungen für Kampf, Eingabe, Anzeige, Ton und Vollbild. In Apps mit Entwicklungszertifikat wurden keine Lecks gefunden. Am 27. Oktober bestanden automatische iPhone- und iPad-Prüfungen jeweils 84 von 85 Fällen; ein Vergleich der Anzeigezeit scheiterte. Auch die spätere Messung vom 29. Oktober ergab beim Formationseinflug auf dem iPad ein p95 der Frame-Aufrufabstände von 21,39ms, über dem Grenzwert von 20ms. Ein Vergleich mit dem Stand vor der Änderung unter gleichen Bedingungen steht noch aus.

Eine spätere Messung nach Einführung des HUD-Editors verwendete lokale Ad-hoc-Signierung. Drei von sechs Bedingungen überschritten den Grenzwert von 16,67ms für die Verarbeitungszeit; vor der Änderung waren es fünf gewesen. Eine Wiederholungsmessung unter den früheren Bedingungen mit Entwicklungszertifikat und die Untersuchung von Verzögerungen bei der Fensteranzeige stehen noch aus.

Noch offen sind Tests mit tatsächlich angeschlossenen Bluetooth- und USB-Tastaturen, Wärme- und Speicherveränderungen über längere Zeit sowie die Schwierigkeit der ganzen Kampagne mit zusätzlichen Gegnern. Ich meldete außerdem ein neues Problem: Nach Nutzung der Wecker-App und Rückkehr fällt der Spielton aus. Die Ursache muss untersucht werden.

Hinweise zum automatischen Zielen und die Tutorials 0-0 bis 0-4 sind noch nicht umgesetzt. Für Android ist das Symbol vorbereitet und die Nutzung des gemeinsamen C++-Kerns geplant. Eine Android-App oder ein APK gibt es nicht. Die Formation hat jetzt Abstand beim Einflug; eine KI zum Halten der Formation während des gesamten Kampfes wurde nicht ergänzt.

Wir konzentrierten uns darauf, das Original wiederherzustellen und spielbar zu machen. Build-Warnungen wurden deshalb nicht vollständig untersucht und behoben. Einige Warnungen betreffen vermutlich APIs, deren Verwendung nicht mehr empfohlen wird. Die genaue Ursache muss noch untersucht werden. Ich möchte außerdem ein Skript, das Download, Ressourcenvorbereitung, Build und Start verbindet. Es soll zwischen Mac-Ausführung und iPhone/iPad-Installation wählen lassen und bei Werkzeugen, Entwicklungsteam und Signierung helfen.

Ich fragte Codex, ob auch andere das Repository herunterladen und bauen können. Selbst mit Quellcode lässt es sich nicht starten, wenn Bilder, Ton und Karten nur auf meinem Rechner liegen. Codex legte die nötigen Ressourcen in Git und LFS ab und dokumentierte Dateilisten und Hashes. Nach einem frischen Clone des öffentlichen main prüfte es Build und Simulatorstart mit gesperrtem Zugriff auf den bestehenden Arbeitsordner und das Originalpaket.

Auf einem Apple-Silicon-Mac benötigt man Xcode, CMake ab 3.20, Python 3 und Git LFS. Man kann das Repository klonen oder das Quellcode-und-Ressourcen-Archiv von v0.16 Releases herunterladen. Nach dem Laden der LFS-Ressourcen und der Ressourcenprüfung öffnet man den Workspace und wählt das eigene Entwicklungsteam und das Ausführungsziel. Reguläre und Cheat-App haben eigene Run-Konfigurationen. Die Befehle und vier Konfigurationen stehen in der Installationsbeschreibung im Apps-Text.

Auch die Versionsgeschichte von v0.9 bis v0.16 steht in GitHub Releases. Nach v0.16 ergänzte Codex in main ein Werkzeug, das Code und Ressourcen eines Tags bündelt und Versionshinweise sowie Hashes vorbereitet. Paket und Wiederaufnahme nach Fehlern wurden geprüft. Eine neue Version tatsächlich mit diesem Werkzeug zu veröffentlichen steht für die nächste Version an. Ein Werkzeug, mit dem andere vom Download bis zu Build und Ausführung alles in einem Ablauf erledigen können, gibt es noch nicht.

Spielcode, Bilder, Audio und Karten liegen zusammen. Ich dokumentierte, was restauriert wurde und welche Probleme wir fanden und behoben. Arbeitsbranches werden in develop, develop in main gemergt; der Release-Tag wird auf den Merge-Commit von main gesetzt. Dadurch lässt sich die jeweilige Fassung aus ihrem Tag erneut bauen.

Hinzu kommen acht Bilder, zwei GIFs und drei MP4s mit Ton aus meinen Spielaufnahmen. Die GIFs laufen in Originalgeschwindigkeit. So sind der ursprüngliche Ablauf aus Springen, Waffenwahl und Verbesserungen sowie neue Jäger und automatisches Zielen als tatsächliche Spielbilder festgehalten.

Die Bilder der Bodeneinheiten und des HUD-Editors wurden danach separat in Cheat-Apps auf echten Geräten aufgenommen.

Ich habe nicht vor, mit dieser Restaurierung Geld zu verdienen. In meiner Entwicklererklärung schrieb ich: „Ich möchte Code und Assets zusammen veröffentlichen, damit andere selbst bauen und spielen können. Auch wie das Spiel restauriert wurde und was wir korrigiert haben, möchte ich festhalten.“

Für neu geschriebenen Code gilt MIT. Der Geltungsbereich für Material aus dem Original sowie externen Code und Dokumentation ist getrennt. Originalgrafiken, Audio, Spieldaten und ergänzende Bilder folgen den Nutzungsbedingungen für Ressourcen; OpenAL Soft, stb und andere Komponenten den Drittanbieterhinweisen. Die Credits unterscheiden ebenfalls Entwicklung und Grafik der ursprünglichen Schöpfer von den Arbeiten, deren Ergänzung ich geplant habe.

Sollte ich später ein App-Store-Konto für sass.studio anlegen und sollten die ursprünglichen Urheber und Beteiligten einer Verbreitung zustimmen, werde ich es auch dann kostenlos anbieten.

Mir bleibt nicht viel Zeit, und Geld braucht man nur in dieser Welt.