Nach langer Pause möchte ich meinen Erfahrungsbericht zur Indie-Entwicklung gerne noch mit zwei weiteren Ausgaben über besondere Entwicklungen fortsetzen. In dieser Ausgabe würde ich gerne an meinen Bericht hinsichtlich der Zulassung als ID@Xbox-Entwickler anknüpfen. Damals wurden zwei Projekte genehmigt, eine Spielsammlung namens Regina & Macbat Collection und Commander Keen in Keen Dreams: Definitive Edition. Nunmehr sind zwei Jahre ins Land gegangen, bevor das erste der beiden, wenn auch unter neuem Namen – Toree’s 3D Platformer Collection – das Licht der Welt erblickt hat. Woran das liegt und wie sich meine Entwicklerzukunft neben den Nintendo-Systemen entwickelt, darüber möchte ich heute gerne sprechen.
Nachdem ich als ID@Xbox-Entwickler zugelassen wurde, wollte ich mich natürlich umgehend daran begeben, die Spiele, für die ich eine Projektzulassung erhalten hatte, für die Microsoft-Konsole umzusetzen. Leider hat sich das als sehr schwierig erwiesen, da Unity zu dem Zeitpunkt noch keine Dokumentation der Implementation des Export-Moduls für Xbox-Systeme angeboten hat. Das Problem hierbei ist, dass Xbox ein System ist, das eine Reihe von Funktionalitäten bietet, die nicht universell sind und daher einer korrekten Behandlung durch den Entwickler bedürfen. Insbesondere die Nutzerverwaltung, das Speichersystem und die Achievement als Pflicht-Funktionalität sind hier zu nennen. Zusätzlich hätte ich aber auch gerne Social Leaderboards für die Regina & Macbat Collection umgesetzt. Nach einigem Experimentieren kam ich daher leider zu dem Schluss, dass es mir nicht möglich ist, bei dem aktuellen Dokumentationsstand zuverlässige Software für Xbox zu schreiben, die alle Regeln Microsofts einhält und dem Spieler eine angemessen angenehme Spielerfahrung bietet. Daher habe ich die Xbox-Konversionen vorerst auf Eis gelegt und mich auf die Entwicklung weiterer Spiele für Nintendo Switch und die Portierung weiterer Spiele von Marcus konzentriert.
Im Laufe des vergangenen Jahres hat Unity dann endlich eine – wenngleich äußerst schlechte – Dokumentation des GameCore-Plug-Ins veröffentlicht, so dass ich mich im Frühsommer 2022 endlich daran begeben konnte, die begonnen Projekte abzuschließen und dabei auch die Xbox-Plattform in meinen Port-Tools zu integrieren, so dass ich künftig in der Lage sein würde, alle Spiele, die ich entwickle oder auf die Nintendo Switch portiere, zeitnah oder -gleich auch auf Xbox zu veröffentlichen. Leider ist es wieder einmal Unity gewesen, die mir einen Strich durch diese Rechnung gemacht haben.
Im Sommer 2021 hat Unity nämlich seine Politik geändert, was die Veröffentlichung von Videospielen auf Konsolen anbelangt. Bis dahin galt für Konsolen wie für alle anderen Plattformen, dass Kleinentwickler, die weniger als 100.000$ im Jahr mit Videospielen umsetzen – zu denen ich ganz klar gehöre – mit einer kostenfreien Unity Personal Lizenz arbeiten können. Für alle künftigen Projekte gilt aber seither: Nur wer ein aktives Unity Pro-Abo besitzt, darf weiter für die Konsolen entwickeln. Die einzige Alternative dazu ist, dass der Plattformanbieter eine so genannte Preferred Platform-Lizenz vergibt. Nintendo und Sony haben diesen Weg gewählt, Microsoft hingegen nicht, so dass neue Xbox-Projekte nur noch gegen eine jährliche Zahlung von 1800$ möglich sind. Eine Royalty-basierte Lösung oder eine Nutzung des günstigeren Abos für mittelgroße Unternehmen bietet Unity nicht an, nur das teuerste Einzelabo ermöglicht künftig noch die Entwicklung für Xbox. An dieser Stelle sollte ich erwähnen, dass diese Information nicht aus den NDA-beschränkten Entwickler-Informationen stammt, sondern beispielsweise in diesem Artikel der Kollegen von Game Informer und PureXbox nachgelesen werden kann.
Bereits bestehende Projekte können aber zum Glück noch mit der kostenfreien Personal-Lizenz abgeschlossen werden und so musste ich ein wenig umplanen. Auf Grund der Schwierigkeiten mit Javier Chavez ist Keen Dreams Definitive Edition auf der Xbox natürlich eine reine Pflichtübung: ich stelle den Port fertig, weil ich mich vertraglich dazu verpflichtet habe, jede weitere Anbindung an meine sonstigen Spiele oder qualitativen Verbesserungen im Vergleich zur Nintendo Switch-Version sind aber ausgeschlossen. Die Regina & Macbat Collection hingegen musste noch einmal überdacht werden, denn anderenfalls hätte Marcus‘ und mein größter Hit, die Toree-Spiele, wohl nie auf der Xbox erscheinen können. So kam es zu einem Namenswechsel und aus der Regina & Macbat Collection wurde Toree’s 3D Platformer Collection und die Toree-Spiele Toree 3D und Toree 2 mussten als Hauptspiele in die Collection integriert werden.
Nachdem eine rudimentäre Dokumentation des Xbox-Exportmoduls nun also vorlag, habe ich zunächst einmal Keen Dreams auf die Xbox portiert, da das als absolut reiner Port eine deutlich einfachere Angelegenheit zu werden versprach und mir die Möglichkeit gab, die Xbox-Funktionalitäten gekapselt in meine C#-Klasse zu übernehmen, die dazu dient, sämtliche Plattform-spezifische Besonderheiten zusammenzufassen und zu differenzieren. Die Anbindung an die Xbox-Services hat zum Glück nur circa eine Woche Arbeit in Anspruch genommen und da ich alle meine Ports bisher unter Berücksichtigung meiner zuvor beschriebenen Kapselungsstrategie vorgenommen habe, habe ich so eine Hilfsklasse erhalten, die mir bei jedem weiteren Xbox-Port viel Arbeit abnehmen kann.
Die Toree’s 3D Platformer Collection hingegen war noch immer ein gewaltiger Haufen Arbeit, wenngleich der Xbox-spezifische Anteil der Arbeit tatsächlich sehr überschaubar war. Aufbauend auf der Vorarbeit bei Keen Dreams waren die wesentlichen Schwierigkeiten die konsistente Limitierung auf 60 Bilder in der Sekunde für alle Xbox-Konsolen und die Implementation von Social Leaderboards, die ich bei der Collection nutzen wollte, um Bestenlisten für Speedrunner zur Verfügung zu stellen. Das viel größere Problem war die Integration der vier enthaltenen Spiele – Toree 3D, Toree 2, Macbat 64 und Regina & Mac – in ein zusammenhängendes Paket.
Diese Schwierigkeiten waren teilweise hausgemacht, denn Marcus und ich haben die Spiele nicht mit der Absicht entwickelt, sie später zu einem Paket zusammenzufügen, in dem man auch zwischen verschiedenen Spielen hin und her wechseln kann und wo ein einzelnes Spiel auch mehrfach hintereinander gestartet werden kann, ohne die Programmausführung insgesamt zu unterbrechen. Gerade beim mehrfach angewandten Singleton-Pattern und bei der Verwaltung von Speicherdaten ist das ein relevantes Problem, das teilweise relativ tiefe Eingriffe in die Spiele bedurfte.
Ein weiteres Problem ergibt sich daraus, dass es zahlreiche Klassen gleichen Namens zwischen den verschiedenen Spielen gab. Das hätte man natürlich im Vorfeld durch das Definieren von Paketen vermeiden können, aber ohne das vorab zu planen, haben wir auch keine Paketbindungen vorgenommen. Das an diesem Punkt nachzuholen wäre möglich, aber sehr viel Aufwand. Als praktikabler hat es sich erwiesen, kollidierende Namen durch Änderung der Namen im Originalprojekt zu beheben.
Noch viel größer ist aber das Problem der Identifier in Unity. Unity-Projekte werden anhand von Identifiern zusammengehalten, die zufällig erzeugt werden und in meta-Dateien abgelegt werden. Das hat einige Vorteile, denn so kann man beispielsweise eine Klasse umbenennen, aber das Objekt in einem Level weiß weiterhin, welche Klasse an es gebunden ist und welche Parameterwerte wie gesetzt werden. Da unsere Projekte aber teilweise aufeinander aufgebaut haben, gab es teilweise Skripte und Objekte, die den gleichen Identifier trugen, aber nicht identisch waren. Leider ermöglicht Unity beim Import zwar, den Identifier zu ändern, aber alle mit importierten Elemente wie Level verweisen dann weiterhin auf den alten Identifier. Daher musste ich ein eigenes Programm schreiben, das die Identifier in einem Projekt modifiziert und alle Referenzen auf diesen Identifier ebenfalls anpasst. Das ist an sich kein extrem schwierig zu schreibendes Programm, aber eines wo ein kleiner Fehler das ganze Projekt zerschießt.
Schließlich gab es noch ein weiteres Problem, das sehr eng mit Unity zusammenhängt. Unity hat nämlich im Laufe der Jahre immer wieder umfassende Änderungen an den angebotenen Softwarefeatures durchgeführt. Besonders relevant ist hier die Neugestaltung User Interface-Systems. Insgesamt gibt es drei UI-Systeme in Unity, das klassische UI-System, das OnGUI-System und das neue UI-System. Alle drei UI-Systeme sind über die vier Spiele hinweg verwendet worden; in Macbat 64 allerdings schwerpunktmäßig das klassische UI-System, das in Unity 2019.4 entfernt wurde. Leider war die älteste Unity-Version, die Xbox unterstützt, just eine, in der das klassische UI-System bereits entfernt wurde. In der Konsequenz sind unzählige Probleme entstanden. Zunächst einmal musste ich natürlich alle möglichen UI-Anzeigen neu implementieren, ohne, dass für den Spieler ein Unterschied sichtbar wird, aber noch viel problematischer ist der bestehende Verweis auf entfernte Klassen und Unity-Komponenten. Auf dem PC ist das ein vernachlässigbares Problem, weil solche fehlenden Komponenten nur Warnungen ergeben, auf Xbox hingegen blockieren sie die Kompilierung. Leider lassen sich fehlende Komponenten nicht komfortabel finden oder entfernen. Die vollständige Entfernung der fehlenden Komponenten bedeutete für mich viele Stunden Arbeit, in denen ich erst einmal alle Identifier der fehlenden Komponenten identifizieren musste und dann herausfinden musste, wie die Unity-Dateistruktur funktioniert, um diese Verweise sauber mit einem selbstgeschriebenen Programm zu entfernen.
Im Endeffekt hat sie das Zusammenführen der Spiele aber hinsichtlich des Endprodukts als lohnend erwiesen. Alle vier Spiele sind auf Xbox ohne mir bekannte Probleme spielbar, mit maximaler Auflösung von 4k (jedenfalls ab Xbox One X), konsistenten 60 Bildern in der Sekunde und einem neuen integrierten Time Attack-Modus für Speedrunner. Auch war es mir so möglich – natürlich mit freundlicher Genehmigung von Marcus – Regina & Mac mit einigen von Marcus für die anderen drei Spiele erstellten Partikeleffekten optisch aufzuwerten. Auf Xbox ist das zum Glück technisch keinerlei Problem.
Es ist schon sehr schade, dass ich nun für alle künftigen Spiele in sehr überschaubarer Zeit eine Xbox-Version erzeugen könnte, diese aber nicht veröffentlichen darf – oder nur gegen Zahlung einer jährlichen Gebühr, die potenziell meine Einnahmen überschreitet und daher schwer zu rechtfertigen wäre. Bei einem großen Erfolg der Toree’s 3D Platformer Collection und Keen Dreams würde ich mir das eventuell überlegen, aber nach momentanem Stand werde ich die Xbox in Zukunft wohl leider auslassen müssen, oder aber nachträglich mit größeren Mengen an Spielen versorgen, um wenigstens nur jedes zweite oder dritte Jahr die hohe Gebühr zahlen zu müssen. Immerhin habe ich aber mittlerweile die Zulassung als PlayStation-Entwickler erhalten, so dass es voraussichtlich auch in Zukunft noch nicht-Nintendo-Versionen meiner Spiele geben wird.