Abenteuer Spieleentwicklung – Teil 5: Der Kampf mit der Kamera

Mit einem funktionierenden Kollisionssystem, ersten Plattformtypen und einem spielbaren Testlevel konnten Regina & Mac in die nächste Phase übergehen: Spiel- und Leveldesign. Da ich die Programmierung alleine angehen würde, mussten wir schnell einen Punkt finden, an dem mein Freund Tristan mit dem Leveldesign einsteigen konnte, damit wir nicht allzu viel Zeit verlören. Hauptproblem in der Sache: Das Leveldesign hängt natürlich stark an der Programmierung des Spiels und wenn sich entscheidend etwas am Spieldesign und der Programmierung ändert, kann das frappierende Auswirkungen auf das Leveldesign haben.

Daher haben wir in unserem ersten Treffen, nachdem die Kollisionsabfrage stand, mechanisch alles festzurren müssen. Die Grundmanöver des Spiels sollten nur Laufen und Springen (incl. Doppel- und Dreifachsprung) sein. In jedem Level sollte das Moveset allerdings um einen Move erweitert werden. Um einen sanften Einstieg in das Spiel zu ermöglichen einigten wir uns, das Design der ersten beiden Level hinten an zu stellen, ansonsten aber grob chronologisch zu arbeiten, damit wir stets die Fähigkeiten bereits parat haben, die wir in einem Level verwenden können. Dementsprechend haben wir, ohne irgendeinen weiteren Plan für Level 1 und 2 zu haben immerhin schon einmal die Fähigkeit festgelegt, die man in den ersten beiden Levels erhält. Eine Stampfattacke mit der man Schalter aktivieren kann und einen Rennmove, mit dem man doppelt so schnell rennen kann, im Gegenzug aber Momentum mitnimmt, so dass die Steuerung ein kleines bisschen weniger direkt ist. Im Gegensatz zu den meisten Jump & Runs hatten wir uns entschieden, bei normalen Spielgeschwindigkeiten dem Spieler volle Kontrolle über den Charakter zu lassen und keinerlei Momentum vorzusehen. Das ist eine etwas ungewöhnliche Entscheidung, die ich in 2D so auch nicht treffen würde, die aber in Anbetracht der schwierigeren Erkennbarkeit von Distanzen in 3D bei den vorgesehenen schwierigeren Sprungpassagen sinnvoll erschien.

Level 5 ist ein Schlosslevel das man in drei verschiedenen Größen spielen kann. Dieser Screenshot und die weiteren Screenshots zeigen, wie die Level während der Entwicklung bis Anfang 2019 (größtenteils) aussahen: Mit schlichten einfarbigen Texturen.

Eine weitere höchst ungewöhnliche Entscheidung war der komplette Verzicht auf Gegner. Im Zuge meiner 3D Jump & Run-Reihe habe ich einen Großteil der 3D Jump & Runs auf dem Markt gespielt und – abgesehen von einigen Sonic-Spielen wo Gegner als Plattformen oder Hindernisse dienen – ist es in den meisten Spielen so gewesen, dass Gegner entweder eine banale Nebentätigkeit darstellten (z. B. Super Mario 64, Banjo-Kazooie), das Spiel aus dem Genre gerissen haben (z. B. Ratchet & Clank, Kya: Dark Lineage) oder aber schlicht extrem nervig waren (der Großteil der Spiele). Obwohl ich im Code zu dem Zeitpunkt noch einen Angriff und eine rudimentäre Gegner-KI vorbereitet hatte, entschieden wir uns nach kurzer Diskussion dafür, auf Gegner vollständig zu verzichten. Positiver Nebeneffekt: Regina & Mac ist ein vollständig gewaltfreies Spiel. Ebenfalls nicht schlecht: Ein Knopf mehr steht für Jump & Run-Aktionen zur Verfügung.

Schließlich mussten wir uns auf eine Spielstruktur und Designgrundsätze einigen, damit das Spiel, das am Ende Leveldesigns von uns beiden beinhalten würde, ein weitgehend konsistentes Bild ergeben würde. Strukturell haben wir uns an dem Gold-Standard für Collectathon-Spiele orientiert: Banjo-Kazooie. Es sollte neun Level und eine Oberwelt geben, die jeweils zehn Hauptaufgaben enthalten sollten, die mit einem goldenen Glitzerobjekt (später als Diskette realisiert) entlohnt werden sollten. Die Wege zu den einzelnen Hauptattraktionspunkten in den Levels sollten über silberne Sammelobjekte markiert sein – später als Nonocubes realisiert – derer es hundert je Level geben sollte und die keinesfalls „fies“ versteckt werden sollten. Es war uns wichtig, zu verhindern, dass man am Ende eines Levels noch einmal langwierig durch die Level laufen muss, nur um ein einzelnes verstreutes Sammelobjekt aufzulesen.

Die silbernen Würfel – Nonocubes – weisen in den Levels den Weg.

Die dritte Sorte Sammelobjekte sind schließlich Relikte. In jedem Level gibt es fünf Relikte, die den Spieler bei vollständiger Sammlung mit einer Floppy entlohnen. Die Relikte sind thematisch jeweils an die Hauptsammelgegenstände von Klassikern in dem Genre angelehnt, beispielsweise gibt es in einem Level Relikte mit einem Puzzleteil, in einem anderen Relikte mit Sternen und in wieder anderen Relikte mit Energiezellen (Wer errät, an welche Spiele diese Relikte angelehnt sind?). Die Relikte sind die einzigen Sammelgegenstände, die grundsätzlich auch etwas fieser versteckt werden dürfen. Für das eigentliche Leveldesign haben wir einige Grundregeln aufgestellt:

– Jedes Level sollte ein Puzzle-Element enthalten, das mindestens eine, maximal zwei Disketten behütet.
– Jedes Element im Level soll eine Funktion haben, also entweder Hindernis oder Weg zu einem Sammelgegenstand sein, oder aber grundlegendes Strukturelement des Levels.
– Jede Floppy muss an eine individuell durchdachte Aufgabe geknüpft sein.
– Level müssen entweder sternförmig oder in Form von erkennbaren Arealen mit markanten optischen Fixpunkten gestaltet sein, um die Orientierung zu erleichtern.
– Jedes Level darf nur Fähigkeiten voraussetzen, die in einem vorherigen Level oder im aktuellen Level gelernt wurden. Es ist zwar stellenweise möglich, die Level in abweichender Reihenfolge zu spielen, das geschieht aber auf eigene Gefahr.
– Ein Aufgabentyp darf für maximal zwei Disketten in einem Level verwendet werden.

Level 2, ein Schneelevel, kann zu diesem Zeitpunkt noch ohne weiteres mit einer weißen Fläche verwechselt werden.

Nachdem diese Regeln einmal als grundlegender Designrahmen festgelegt waren, konnte Tristan beginnen, Level 3 zu designen, während ich weiter an der Programmierung der Spielmechanik und insbesondere der Fähigkeiten und speziellen Objekte für weitere Level arbeitete. Eine frühe Designentscheidung in der Programmierung, die mir zu diesem Zeitpunkt noch sinnvoll erschien, hat sich allerdings im weiteren Verlauf als unglücklich erwiesen – so sehr dass ich beinahe ein komplettes Refactoring in Erwägung gezogen hätte, wenn das nicht zu große Auswirkungen auf die bereits bestehenden Level gehabt hätte. Für alle Plattformen im Spiel gibt es eine einzige Klasse, die ihr Verhalten steuert, abhängig von gesetzten Variablen im Editor. So unterscheiden sich eine fahrende, eine rotierende, eine fallende oder eine die Sprungkraft verstärkende Plattform nur dadurch, welche Variablen im Unity-Editor gesetzt wurden. Das ist zwar relativ flexibel und erlaubt die freie Kombination aller möglichen Plattformtypen, wird aber auch nach einiger Zeit sehr unübersichtlich. Es wäre rückblickend eine bessere Idee gewesen, Plattformverhalten über Skripte ohne eigene Update-Methode hinzuzufügen und zu entfernen, die die notwendigen Eigenschaften wie z. B. Start- und Zielpunkt einer fahrenden Plattform kapseln.

Die wichtigste Programmieraufgabe abgesehen von der grundlegenden Spielmechanik in einem 3D Jump & Run ist meines Erachtens die Kamera-Steuerung, die notorisch für die frustrierendsten Situationen in 3D Jump & Runs führen. Grundsätzlich gibt es drei verschiedene Ansätze, eine vollautomatische Kamera, die in jeder Situation individuell entscheidet, welche Perspektive die beste ist, eine halbautomatische Kamera, die eine gewisse Autonomie besitzt und sich (in der Regel) verzögert hinter den Spieler-Charakter zentriert, aber auch manuell gesteuert werden kann, sowie eine komplett manuelle Kamera, die vollständig vom Spieler gesteuert wird.

In späteren Levels werden die Konstruktionen durchaus ein wenig komplexer (hier: Level 7).

Auf Grund der freien Natur von Regina & Mac ist die erste Variante außer in Spezialsituationen von vorneherein ausgeschlossen, die Entscheidung ist also auf zwei Varianten eingeengt worden. Nach unserer Erfahrung mit einem recht freien System in Super Mario Sunshine und einer Vielzahl von halbautomatischen Systemen haben wir entschieden, dass das freie System für ein Collectathon-Spiel die beste Wahl zu sein scheint. In der Tat ist es so, dass die wenigen Kameraprobleme in Super Mario Sunshine gerade dadurch ausgelöst wurden, dass die Kamera in gewissen Situationen doch nicht automatisiert ist.

Allerdings kommt diese Entscheidung mit einer gewissen Einschränkung daher: Die Kamera wird mit dem rechten Stick gesteuert und mit B springt man. Das bedeutet, dass man nicht gleichzeitig springen und die Kamera drehen kann. In den meisten Situationen ist das kein Problem, aber in zeitkritischen Abschnitten, beispielsweise mit fallenden Plattformen, kann das zu hektischen Manövern führen. Wir haben ein wenig damit experimentiert, die Kamerasteuerung schlichter per Schultertasten zu gestalten, oder aber den Sprungknopf auf die Schultertasten zu verlegen, doch beide Varianten haben sich in normalen Spielsituationen deutlich schlechter angefühlt.

Das erste Level in einen Sumpf zu legen scheint eine ungewöhnliche Entscheidung zu sein, aber immerhin gibt es einen Baum!

Daher haben wir uns für eine zweischrittige Lösung entschieden. Für spezielle Szenen ist die Kamera automatisiert – das betrifft aber nur Boostsequenzen, wie sie ab dem fünften Level gelegentlich vorkommen, zusätzlich gibt es die Möglichkeit, die Kamera per Schultertaste hinter Macs Rücken zu zentrieren. Als zweiter Schritt allerdings mussten wir im Leveldesign darauf achtgeben, dass wir Szenen vermeiden, in denen keine Ruhephase zwischen zwei Abschnitten liegt, in denen man zwei verschiedene Kameraperspektiven benötigt, wobei die zweite nicht hinter dem Rücken von Mac ist.

Das zweite wesentliche Problem ist, wie die Kamera darauf reagiert, wenn zwischen Kamera und Hauptcharakter ein Hindernis ist, das die Sicht auf den Charakter blockiert. In den meisten Spielen gibt es zwei verschiedene Lösungen für dieses Problem: Die Kamera versucht, Hindernissen auszuweichen, oder der Spielcharakter wird als Schatten auf das obstruierende Objekt gezeichnet. Beide Lösungen sind für uns nicht ideal gewesen. Ausweichen kann in engen Spielsituationen für Ärger sorgen und Innenräume zu einer Qual machen, weil man die Kamera schlicht nicht in die Position gedreht bekommt, die für den jeweiligen Sprung ideal ist. Wenn man den Charakter nur als Silhouette zeichnet, hat das hingegen zur Folge, dass man zwar weiß, wo der eigene Charakter sich befindet, aber man keine optischen Informationen über seine unmittelbare Umgebung hat, so dass man um ein Ändern der Kameraperspektive nicht umhin kommt.

Dieser Screenshot aus Level 9 demonstriert den Halbtransparenz-Effekt, wenn die Sicht auf Regina und Mac verdeckt wird.

Daher haben wir uns für eine unkonventionelle Lösung entschieden: Levelobjekte, die die Sicht auf Regina und Mac verdecken (könnten – aus Performancegründen waren wir etwas großzügig in der Abschätzung wann das der Fall ist), werden halbtransparent gezeichnet, so dass man sowohl das Hindernis, das die Sicht blockiert hat, weiterhin sieht, als auch den Charakter und die unmittelbare Umgebung. Nach unserem Geschmack führt das zum besten Spielgefühl, da der Spieler niemals durch das Kamerasystem entmündigt werden muss, gleichzeitig aber kleine Kamerasteuerungsfehler sich nicht allzu schädlich auf die Spielbarkeit auswirken.

Ein größeres optisches Problem ergibt sich aber noch dadurch, dass die Kamera innerhalb von Objekten sein kann. Wenn das geschieht, sieht man die entsprechenden Objekte einfach gar nicht mehr, da standardmäßig jedes 3D-Objekt nur einen äußern Mesh hat, das heißt, dass beispielsweise ein Würfel nur aus Polygonen besteht, die von außerhalb des Würfels sichtbar sind. Befindet sich die Kamera im Würfel, scheint dieser komplett verschwunden zu sein. Die einfachste Lösung hierfür wäre natürlich, bei jedem Objekt auch den inneren Mesh zu generieren und immer mit zu berechnen, das ist aber mit der Framerate-Zielvorgabe von 60fps auf der Wii U nicht zu vereinen gewesen. Daher haben wir die folgende Lösung gewählt: Wenn die Kamera sich im Inneren eines Objekts befindet, wird der Mesh durch einen inneren Mesh ausgetauscht, sobald die Kamera das Objekt verlässt, wird der Mesh wieder zurückgetauscht.

Einer der Moves, die man im Laufe des Spiels freischaltet: Grinden.

In den allermeisten Spielsituationen ergibt sich so ein konsistentes Bild, das alle Informationen, die der Spieler benötigt, enthält. Einzig, wenn die Kamera exakt parallel zu einem Objekt steht und man sich unmittelbar neben das Objekt stellt, und das Objekt so groß ist, dass man die (aus Sicht der Kamera) Vorderseite des Objekts nicht im Bild hat, kann es passieren, dass man ein Objekt nicht sieht. Das würde durch die dauerhafte Anzeige des inneren Meshs allerdings auch nur teilweise korrigiert werden, da man dann die Wand, die direkt neben dem Spieler ist, weiterhin nicht sehen könnte. Eine mögliche Lösung des Problems wäre es, dass Wände die Kamera, wenn sie direkt neben der Wand ist und exakt parallel ist, einen minimalen Stoß weg von der Wand gibt, das würde aber zu einer nicht-stetigen Kamerabewegung führen – wenn man den rechten Stick nur leicht drückt, würde es sogar zu einem hin- und herspringen der Kamera führen – daher haben wir uns dafür entschieden, diesen Schwachpunkt zu tolerieren, da er ohnehin sehr speziell ist und im Spiel nur selten vorkommen sollte.

Natürlich gab es noch viele weitere Programmier-Herausforderungen zu lösen, doch die wesentlichen Punkte abseits der Optimierung sind nun abgearbeitet. Natürlich habe ich aber nicht nur programmiert, sondern parallel zu Tristan auch langsam selbst mit Leveldesign begonnen. Mein eigenes erstes Level ist das vierte Level des Spiels, eine Bergregion, die auf ein Design mit Regionen und markanten Fixpunkten setzt. Die Grundidee des Levels ist, dass man einen Berg erklimmen soll, auf dem man die Flugfähigkeit lernt und mit ihr den angrenzenden Vulkan erreichen kann. Entlang dieser Grundstruktur gibt es einige Aufgaben zu entdecken, die unabhängig von dieser linearen Grundstruktur erledigt werden können. Das Leveldesign – inklusive der vielen Feinabstimmungen für den Schwierigkeitsgrad, Lesbarkeit des Designs und Balance des Umfangs der einzelnen Aufgaben – hat sich wenig überraschend als die umfangreichste Aufgabe herausgestellt und leider haben wir es nicht geschafft, das Spiel vor Tristans Umzug fertigzustellen. Tristan hat es aber immerhin noch geschafft, Level 3 und 6 vor seinem Umzug fertigzustellen und hat den allergrößten Teil der Oberwelt dann aus der Ferne designt. Die übrigen Level – 1, 2, 4, 5, 7, 8, und 9, sowie zwei lineare Extralevel habe derweil ich designt. Wir standen aber im stetigen Austausch über alle Level, so dass alle Level durch uns beide geprägt wurden.

In der nächsten Ausgabe von Abenteuer Spieleentwicklung sprechen wir über Optimierungsarbeiten, die Präsentation und den Veröffentlichungsprozess.