Abenteuer Spieleentwicklung – Teil 6: Auf der Zielgeraden

Zwar neige ich (genau wie mein Mitentwickler Tristan) dazu, Videospiele sehr auf ihr Gameplay zu reduzieren, Spieleentwicklung ist aber immer auch darauf ausgerichtet, anderen Freude zu bereiten. In den letzten beiden Ausgaben von Abenteuer Spieleentwicklung waren bereits einige Screenshots zu sehen, die zeigten, wie Regina & Mac in der Entwicklung über weite Teile aussah, doch einfarbige Blöcke mit schwarzen Konturen als einziges optisches Gestaltungsmerkmal hätte wohl nur den hartgesottensten Spielern gefallen.

Weder Tristan noch ich sind allerdings künstlerisch begabt, so dass wir für die künstlerische Gestaltung des Spiels auf Hilfe angewiesen waren. Meine Frau Tosha hat sich um die Gestaltung der Texturen gekümmert, wohingegen Tristans Cousin Christian als Komponist einen wesentlichen Beitrag zum Spiel geleistet hat. Im Hinblick auf die Texturen hatte Tosha einen besonders schwierigen Job, da Regina & Mac von Beginn an als unsere Interpretation eines Nintendo 64-Jump & Runs vorgesehen war. Zwar sollten Framerate-Probleme, Kameraprobleme und Nebelwände nicht künstlich in das Spiel integriert werden, der grundsätzliche Look des Spiels sollte aber einem Nintendo 64-Spiel nahekommen. In der Folge haben wir uns geeinigt, dass das Spiel (mit wenigen Ausnahmen) nur mit 64*64 Pixel-Texturen versehen werden sollte. Diese würden dann, wie auf dem Nintendo 64, auch über größere Plattformen gezogen werden und mit bilinearem Filter – dem auf dem Nintendo 64 üblichen Filter für Texturen – zu einem leicht ausgewaschenen, statt hart pixeligem Look geformt.

Dadurch musste Tosha bei der Gestaltung der Texturen nicht nur dafür sorgen, dass sie mit wenigen Pixeln etwas hinbekommt, was die jeweilige Struktur gut wiedergibt, sondern überdies im Blick behalten, wie sich die Texturen in einem gestreckten Zustand entwickeln würden. Zur Erstellung der Texturen hat Tosha ein Surface-Tablet erhalten und mit einem passenden Stift auf dem Touchscreen gezeichnet. Zum Glück hat Tosha aber meines Erachtens ein gutes Händchen für diese Aufgabe bewiesen und tatsächlich Texturen gemalt, die sowohl auf kleineren als auch auf größeren Blöcken passend aussehen und überdies einen starken Nintendo 64-Flair versprühen.

Musikalisch hat Christian sich grob an den Klängen von SNES- und Nintendo 64-Spielen orientiert und insgesamt sechs Stücke für den Soundtrack von Regina & Mac beigetragen. Aus Zeitgründen konnte er aber leider nicht den gesamten Soundtrack alleine schreiben, so dass er noch einen Freund, Bernhard, hinzugeholt hat, der drei weitere Stücke geschrieben hat. Die übrigen sechs Stücke des Soundtracks stammen von einem deutschen Musiker namens Badub, der Musik im Stil von Nintendo 64-Klassikern unter freier Lizenz komponiert hat. Auf Grund des großen Umfangs der Nutzung von Badubs Musik habe ich ihn aber vor der Nutzung dennoch auch persönlich gefragt, ob er mit dieser Nutzung einverstanden ist. Ursprünglich wollte Christian auch die Soundeffekte von Regina & Mac machen, aber aus besagten Zeitgründen habe ich stattdessen auf CC-0 und CC-By Soundeffekte von der Website Freesound.org zurückgegriffen, wo zahlreiche Nutzer selbst entworfene oder aufgenommene Soundeffekte bereitgestellt haben. Selbstverständlich werden auch die Macher von mit CC-0 lizenzierten Soundeffekte namentlich im Abspann erwähnt.

Ein Punkt, den ich persönlich wohl tatsächlich komplett ignoriert hätte, ist die Geschichte des Spiels. Für meine Begriffe bedarf ein 3D Jump & Run wie Regina & Mac eigentlich kaum einer Geschichte. Allerdings habe ich bemerkt, dass jeder, mit dem ich über das Spiel gesprochen habe und nicht selbst in die Entwicklung involviert war, unmittelbar genau eine Sache wissen wollte: Worum geht es. Und „zwei Figuren springen und rennen durch bunte 3D Welten um Sammelobjekte zu sammeln“ hat dabei nahezu niemanden zufrieden gestellt. Schon nach kurzer Zeit habe ich deswegen auch eine kleine Geschichte geschrieben, die in Textboxen erzählt wird. Worum geht es also in dem Spiel? Regina und Mac erwachen eines Tages in einem verlassenen Forschungslabor und wollen so schnell wie möglich entkommen. Dazu benötigen sie die Hilfe des Laborcomputers U64, der allerdings seine Erinnerungen verloren hat. Diese Erinnerungen sind auf 100 Disketten im gesamten Labor und seinen Testgebieten verteilt.

Textboxen stellen allerdings ein ernsthaftes Problem dar, da man Textboxen in Unity normalweise mithilfe des GUI-Systems darstellen würde. Das funktioniert auch zunächst problemlos, leider hat Unity aber ein Speicherleck im GUI-System. Das bedeutet, dass mit jeder Textbox, die im Spiel dargestellt wird, ein kleines Stückchen des Arbeitsspeichers „weggefressen“ wird und nicht wieder freigegeben wird. Das Ergebnis? Nach etwas längerer Spielzeit ist der recht überschaubare Arbeitsspeicher der Wii U ausgeschöpft und die Framerate geht in die Knie, längerfristig würde dies gar zu einem Totalabsturz des Spiels führen. Da in den Unity-Versionen, die für Wii U zur Verfügung gestellt wurden, dieses Problem nie gelöst wurde, habe ich also einen Textbox-Generator programmiert, der aus dem Skript des Spiels automatisch die passenden Textboxen generiert. Diese Textboxen werden dann als Texturen in das Spiel eingebunden. In der Konsequenz umfasst der Projektordner nun weit über 100 Textboxen als Einzelbild, die im Spiel an den entsprechenden Stellen eingeblendet werden.

Abgesehen vom Text gab es aber natürlich noch viele weitere Optimierungsprobleme, die in Regina & Mac gelöst werden mussten, damit das Spiel die Zielframerate von 60 Bildern in der Sekunde auf der Wii U einhalten kann. Mehrere Level haben das Spiel nach ihrer Fertigstellung zunächst auf unter 30 Bilder in der Sekunde fallen lassen – man beachte hierbei, dass Optimierungen, die für das erste fertiggestellte Level vorgenommen wurden, beim zweiten Level dann bereits von vorneherein aktiv waren – Optimierung hat in der Designphase für mich im Ergebnis fast die Hälfte der Arbeit ausgemacht. Viele Entwickler optimieren erst gegen Ende, da die hohe Bildwiederholrate aber unbedingter Teil des Spielkonzepts ist, war es mir sehr wichtig, frühzeitig sicherzustellen, dass die Level auch tatsächlich so bleiben dürften.

Jede vorgenommene Optimierung zu erläutern würde den Rahmen dieses Artikels deutlich sprengen, aber einige interessante Punkte würde ich gerne kurz erläutern. Bei der Kollisionserkennung war es notwendig, einerseits mit einer möglichst simplen Vorabfrage Kollisionen weiter entfernter Objekte auszuschließen, zu diesem Zweck besitzt jedes Objekt im Spiel zwei Kollisionsboxen, eine genaue und eine Kugel, die die Kollisionsbox umschließt Da für die Kollisionsabfrage zwischen zwei Kugeln nur der Abstand zwischen zwei Punkten betrachtet werden muss, ist das als Vorabfrage geeignet. Ein kleiner Trick an der Stelle ist es dann noch, statt den Abstand das Quadrat des Abstandes zu betrachten, da man sich so eine teure Wurzeloperation spart. Darüber hinaus wird in jedem Frame bei der ersten Kollisionsabfrage – es kann je Frame bis zu ca. zehn Kollisionsabfragerunden geben – gecached, welche Objekte überhaupt in Frage kommen für eine Kollision, so dass selbst die Kugelapproximation nur einmal berechnet werden muss.

Ein wesentliches Problem war weiterhin die Zahl der unabhängigen 3D Objekte im Level (sogenannte Meshes). Die Unity-Standardlösung für dieses Problem, Occlusion Culling, hat sich leider als nicht praktikabel erwiesen, da diese Technik zu Lasten der CPU geht, die bei der Wii U und Unity aber ohnehin der Flaschenhals ist. Stattdessen musste ich auf eine Kombination zweier Techniken setzen: Ausschalten von verdeckter Geometrie anhand von groben Unterteilungen der Level in Quadranten und Kombination von entfernter Geometrie, die nicht verdeckt wird. Die Kombination kann leider nur bei größerer Entfernung verwendet werden, da anderenfalls das Transparenz-Feature für die Kamera nicht ordentlich funktionieren würde.

Weitere Optimierungen betrafen unter anderem das Caching möglichst vieler Werte, die von Fließpunktarithmetik abhängen, sowie das Vermeiden von Unity-API-Calls. Insbesondere die Abfrage von Komponenten eines Spielobjekts (beispielsweise des Kollisionsobjekts) hat sich als völlig unverhältnismäßiger Zeitfresser herausgestellt. Das Verwenden von Arrays statt Listen und von Zählschleifen statt foreach-Schleifen hat ebenfalls einen wichtigen Beitrag zur Performance-Optimierung geleistet. Eine eher geringere Rolle hat noch das Vermeiden der Update-Funktion von Unity gespielt. Diese Funktion wird von Unity verwaltet und einmal pro Frame aufgerufen. Es ist sinnvoll, bei vielen aktiven Komponenten, diese Verwaltung teilweise selbst zu übernehmen, da Unity in der Hinsicht leider nicht sehr effizient arbeitet.

Bestimmte Funktionen wie die Erkennung, dass ein Objekt semitransparent werden muss, müssen schließlich auch nicht jeden Frame stattfinden, da ich ohnehin großzügig überapproximiert habe, wann ein Objekt die Sicht auf den Charakter verdeckt. Nur jeden zehnten Frame zu überprüfen ob ein Objekt transparent werden muss, hat sich als völlig ausreichend erwiesen. Dabei war aber natürlich wichtig, dass man diesen Check gleichmäßig über alle Frames verteilt, da anderenfalls da Framepacing ruiniert würde. Daher verteilen sich die Levelobjekte automatisch bei Erstellung auf zehn Äquivalenzklassen, die dann jeweils gestaffelt nur einmal jeden zehnten Frame überprüfen dürfen, ob sie transparent sein müssen.

Ein Fehler, der das Spiel bis in die letzte Woche begleitet hat, war besonders ärgerlich, da er das Gameplay betraf. So war es Regina und Mac in manchen Levels nach einiger Zeit möglich, zu steile Abhänge scheinbar beliebig nach oben zu laufen. Variationen dieses Fehlers sind dem Kollegen Joshua schon zwei Jahre vor Launch aufgefallen, endgültig gelöst wurde das Problem aber erst in letzter Sekunde. Grund für das Problem war, dass ursprünglich vorgesehen war, dass Regina und Mac nachdem sie einen Booster berührt haben, länger über Schrägen laufen können. Diese Funktionalität ist aber schon früh wieder herausgefallen, dummerweise habe ich aber die Anpassung des entsprechenden Zählers beim Berühren eines Boosters nicht mit entfernt, so dass man viel zu lang über Schrägen laufen konnte, sobald man einmal in einem Level einen Booster berührt hat.

Ein Easteregg, das wahrscheinlich nicht viele Spieler verstehen werden, ist der Titelbildschirm, denn er ist eine Anspielung auf den ersten Ankündigungstrailer von Banjo-Kazooie: Schraube locker. Zunächst zeigt der Titelbildschirm das Testgebiet des Spiels, was traditionell eines der Datenrelikte ist, das Hacker unbedingt betreten wollen. Sobald man sich aber bewegt, fällt eine Wand herunter, die die drei Speicherstände des Spiels beinhaltet und verhindert, dass Regina und Mac durch das Testgebiet laufen können.

Neben der Entwicklung des Spiels ist aber auch die Veröffentlichung eine wichtige Angelegenheit und natürlich war mir schon nach kurzer Zeit der Entwicklung klar, dass die Spielerschaft auf der Wii U äußerst beschränkt sein würde. Daher habe ich mich bemüht, eine Zulassung als Entwickler für Xbox One via ID@Xbox und für die Nintendo Switch zu erhalten. Während Microsoft sehr zügig reagiert hat und mich auf angenehme Weise durch den Prozess begleitet hat, hat Nintendo auf meine Anfrage erst nach deutlich mehr als einem Jahr – mit einer Absage in Standarform – reagiert. Leider war auch die Bewerbung bei ID@Xbox nicht erfolgreich, allerdings hat mir mein Kontaktmann bei Microsoft zumindest eine kostenfreie Lizenz für die Xbox Creators Collection gegeben. Nachdem ich Regina & Mac im November 2019 also bei Nintendo für die Wii U eingereicht habe, habe ich das Spiel auch für die Xbox One kompiliert und über ein relativ simples Publishing-Verfahren im Xbox-Store veröffentlicht. Auf gutes Zureden von Foren-Urgesteinen Bufko und Imur habe ich zudem auch eine PC-Version veröffentlicht, auch wenn ich davor eigentlich stark zurückgeschreckt bin, da ich keine Performance-Garantien auf dem PC geben kann. Anders als bei Nintendo steht es mir frei, über die Verkaufszahlen auf Xbox und PC zu reden, die sind aber Stand heute tatsächlich kaum der Rede wert: Vierzehn Personen haben Regina & Mac auf der Xbox One gekauft und fünf auf itch.io.

Auf itch.io hat das Spiel aber auch einen Kunden gefunden, der zufällig auf das Spiel gestoßen ist und das Spiel ausführlich auf Twitch gespielt, es für einen Speedrun-Wettbewerb angemeldet und zudem sogar ein kleines Fanart gemacht hat, das Regina & Mac als Nintendo 64-Modul zeigt. Sehr glücklich hat mich auf jeden Fall gemacht, dass das Spiel zumindest bei diesem einen mir vorher nicht bekannten Kunden den gewünschten Effekt hatte, im Gespräch in dem ich ihn fragte, ob ich sein Material in dieser Artikelreihe verlinken darf, hat er mir gesagt, dass er sich beim Spielen in seine N64-Jugend zurückversetzt fühlt und viel Spaß mit dem Spiel hatte.

Im Januar erschien Regina & Mac nun endlich auch für die ursprüngliche Zielplattform Wii U und auch wenn das finanzielle Ziel, die Ausgaben für das Devkit wieder einzuspielen, mit diesem Spiel wohl leider nicht erfüllbar ist, bin ich derzeit guter Dinge, dass das Hauptziel, dass einige Spieler Freude mit dem Spiel haben, erfüllt wird. Für den Ausgleich der Ausgaben könnte dann durchaus das nächste Spieleprojekt, ebenfalls für die Wii U, sorgen, das als Auftragsarbeit entsteht. Zum Abschluss der Artikelreihe Abenteuer Spieleentwicklung sei dieses Spiel mit einem Screenshot vom aktuellen Entwicklungsstand angedeutet. Ich hoffe, dass ihr beim Lesen der Reihe so viel Spaß hattet wie ich beim Schreiben.