Nach der Einreichung von Regina & Mac und Commander Keen in Keen Dreams: Definitive Edition für die Nintendo Switch habe ich mir überlegt, dass es sinnvoll wäre, bis zur Geburt meines zweiten Sohns nur an einem kleinen Projekt zu arbeiten, denn die Unterbrechung des Designprozesses um möglicherweise mehrere Monate wäre eine ziemlich unglückliche Situation. Daher habe ich auf Twitter den Entwickler eines der frühen 3D Indie-Jump & Runs, Marcus Horn von Siactro, angeschrieben, ob er an einer gemeinsamen Umsetzung seines 2017 erschienen Spiels Macbat 64 interessiert wäre. Zu meiner großen Freude war Marcus von der Idee sehr angetan und nach kurzer Vorbesprechung konnte ich mit der Portierung beginnen.
Die Hürden für die Portierung von Macbat 64 lagen zunächst einmal offensichtlich in zwei Punkten: Macbat 64 ist mit der veralteten Version Unity 4 entwickelt worden und verwendet darüber hinaus die nicht mehr unterstützte Unity-eigene Sprache Unityscript für seine Programmierung. Es ist daher zunächst einmal notwendig, das Spiel auf eine neue Unity-Version zu portieren, was leider technisch eher knifflig ist. Hinzu kommt, dass Marcus das Spiel nicht mit einer Multiplattform-Entwicklung im Hinterkopf entwickelt hat und somit gewisse Funktionen, die zwischen den verschiedenen Plattformen unterschiedlich implementiert werden müssen, nicht gekapselt hat. Der gesamte Quellcode musste also so umgebaut werden, dass diese Funktionen ausgegliedert und von meinen bereits für Regina & Mac und Keen Dreams vorbereiteten Port-freundlichen Klassen übernommen werden konnten.
Ein erster Versuch, das Projekt einfach in einem Rutsch in Unity 2019 zu öffnen, endete erwartungsgemäß wenig erfolgreich: Die gesamte Programmierung war für Unity 2019 unverständlich und alle Shader wurden durch einfarbige pinke Shader ersetzt. Es musste also ein kleinschrittigerer Ansatz her. Für die Wii U habe ich Unity 5 verwendet, ein erster Portierungsschritt, der bereits mit einigen Inkompatibilitäten einherging, die ich händisch beseitigen musste. Als nächstes folgte der Schritt auf Unity 2018.2, was den wichtigsten Schritt überhaupt darstellte: Diese Version ist die letzte, die Unityscript unterstützt. Just für diese Version gibt es auch ein Konvertierungstool, das Skripte von Unityscript in C# übersetzt. Das hätte man zwar durchaus auch von Hand tun können, doch behält das Konvertierungstool auch die Verknüpfungen mit den GameObjects in den Szenen bei und das ist enorm wichtig, denn sonst hätte man von Hand jedes Prefab und jedes Einzelobjekt im gesamten Spiel neu konfigurieren müssen. Natürlich ist das Konvertierungstool nicht perfekt und hat einige Fehler in einigen Skripten hervorgerufen, die sich aber größtenteils relativ einfach beseitigen ließen.
Der Schritt zu Unity 2019 war danach komplett unfallfrei möglich und nun konnte die eigentliche Switch-Umsetzung beginnen. Die wichtigsten Schritte hierzu waren, das Speichersystem auf die Begebenheiten der Nintendo Switch anzupassen und vor allem für zukünftige Ports zu kapseln und die Steuerung gleichfalls an die Switch anzupassen und zu kapseln. Diese Kapselung ist eine ganz entscheidende Strategie für Portierungen, die man idealerweise bereits bei der Entwicklung auf nur einer Plattform umsetzt: Statt direkt die API anzusprechen, wenn man Steuerungsinformationen benötigt oder speichern möchte, sollte man eine Interface-Klasse ansprechen und nur in dieser einen Klasse die Plattform-spezifischen Aufrufe vornehmen. Durch Compilerdirektiven der Form #if UNITY_EDITOR kann man dann nur in dieser einen Klasse die API-Aufrufe plattformabhängig differenzieren. Für Macbat 64 habe ich daher auch die API-Klasse in zwei verschiedenen Versionen vorliegen: Einmal in der Form, die für den Switch-Port notwendig ist und einmal in einer Form, die ich problemlos an Marcus zurückgeben kann, da sie keine unter NDA stehenden Informationen enthält. Das ist vor allem wichtig, damit Marcus die Möglichkeit hat, künftig Verbesserungen, die wir an Macbat 64 vornehmen, auch beispielsweise in der PC-Version anzubieten.
Neben einem einfachen Port des bestehenden Macbat 64 wollten wir aber auch das Prequel-Spiel Kiwi 64 in Macbat 64 integrieren. Das Problem ist hier nur, dass Kiwi 64 auf einer noch älteren Unity-Version (wir wissen nicht genau welcher) basiert und dass der oben beschriebene Portierungsprozess bei Kiwi 64 nicht funktioniert hat. Zum Glück hatte ich noch eine Version von Unity 4 aus meinen ersten Entwicklungstagen auf der Wii U, so dass mit einem zusätzlichen Schritt zu Unity 4 das Ursprungsprojekt auf die neue Unity-Version gezogen werden konnte. Allerdings ist es damit nicht getan, denn um Kiwi 64 in Macbat zu integrieren, muss man zwei verschiedene Unity-Projekte verschmelzen – eine Operation, die Unity nicht standardmäßig vorsieht. Zwar kann man Inhalt eines Unity-Projekts als Assetbundle in ein anderes importieren, aber dabei dürfen keine Namen für Klassen doppelt vorkommen. Dass Kiwi 64 und Macbat 64 aber durchaus einige Klassen geteilt haben, die den gleichen Namen trugen (aber nicht identisch waren), ist wenig erstaunlich. Zum Glück ist die sehr riskante Operation, die Klassen von Kiwi schrittweise umzubenennen, bei fast jeder Klasse geglückt – nur bei einer Klasse musste ich die Objektkonfiguration wiederherstellen.
Nachdem die erste vollständig spielbare Version des Switch-Ports existierte, habe ich Marcus das Projekt für den PC kompiliert und zugesendet, um die kleinen Abweichungen vom Original herauszuarbeiten und zu beheben. Bei der Gelegenheit hat Marcus auch noch ein neues Extralevel designt, um Kennern des Originals einen kleinen Bonus zu geben. Zum Glück gab es aber nur eine recht kleine Anzahl an Fehlern, die meines Wissens auch alle korrigiert werden konnten, bevor wir Macbat 64 schlussendlich für die Nintendo Switch veröffentlichen konnten.
Die Zusammenarbeit mit Marcus war äußerst angenehm und vor allem der Kontrast zu der Zusammenarbeit mit Chavez, dem Besitzer von Keen Dreams, ist gewaltig. Marcus war durchweg ein sehr angenehmer und kooperativer Partner, mit dem ich auch in Zukunft sehr gerne weiter zusammenarbeiten werde. Mit Chavez hingegen werde ich künftig nicht weiter zusammenarbeiten. Der vorrangige Grund hierfür ist eklatantes Fehlverhalten Chavez‘ auf Twitter, in dem er – schon vor unserer Zusammenarbeit, aber ohne dass ich es wusste – andere Menschen rassistisch und antisemitisch beleidigt hat, diverse eindeutig neonazistische Aussagen getätigt hat und zu allem Überfluss ein Spiel, das einen Krieg gegen Migranten thematisiert bei Steam veröffentlicht.
Das zu dem Zeitpunkt in der Planungsphase befindliche Keen Dreams 2 und der Keen Dreams Maker habe ich umgehend abgebrochen und mit Chavez eine Vereinbarung getroffen um unseren Kontakt zeitlich zu beschränken. Im Gegenzug hat er alle Rechte an meinen Arbeiten der Keen Dreams Definitive Edition für zukünftige Arbeiten an der Marke oder weitere Plattformen erhalten. Meine Ideen für Keen Dreams 2 sind allerdings nicht komplett verloren, denn mittlerweile habe ich mich entschieden, ein von Keen unabhängiges Spiel zu entwickeln, in dem ich die Designideen verarbeiten kann.