Herausforderungen
Wie bei den meisten Projektarbeiten kommt am Ende doch vieles anders, als man denkt - auch unser Projekt blieb von unerwarteten Herausforderungen oder Hürden nicht verschont. Im Folgenden werden diese weiter ausgeführt um u.a. ein deutlicheres Bild unserer Arbeit an dem Projekt zu schaffen und zumindest teilweise unser Endergebnis zu begründen.
Online-Multiplayer
Dass sich die geplante Online-Komponente in unserem Projekt als Herausforderung entpuppen würde, war aufgrund der mangelnden Erfahrung zwar zu erwarten, jedoch war das Ausmaß dann doch umfangreicher als gedacht. Auch beim Multiplayer führen viele Wege zum Ziel und bei den ersten Online-Recherchen stößt man nicht direkt auf "die eine Lösung". Daher hatten wir es zuerst mit einer Dedicated Server Lösung versucht, die sich aber bald als zu komplex und umfangreich für unser Projekt entpuppte. Wie oben bereits erläutert, war es am Ende PUN (Photon Unity Networking), das bei uns nun zum Einsatz kommt. Mit PUN war es uns auch mit verhältnismäßig wenig Erfahrung möglich, ein Grundgerüst für den Online-Multiplayer zu schaffen. So hatten wir z.B. recht schnell die Funktion implementiert, Räume zu erstellen, sich gegenseitig zu finden und einem Raum beizutreten. Die eigentliche Herausforderung der Online-Komponente war jedoch, das eigentliche Gameplay über das Netzwerk zu synchronisieren. So kam es ständig zu Verzögerungen (Lags), Animationsrucklern oder Synchronisationsprobleme, bei denen z.B. einige Spieler nicht exakt das Gleiche im Spiel sahen wie andere. All diese Probleme mussten beim Implementieren von Gameplay-Features, Logiken und Funktionen beachtet und ständig neu angefasst werden, was im Großen und Ganzen einfach sehr viel Zeit in Anspruch nahm.
Unity Collaborate & Plastic SCM
Um gemeinsam an einem Unity-Projekt zu arbeiten, bedarf es im besten Fall einer Versionskontrolllösung, die Code von mehreren Personen zusammenführt (Merging) und verwaltet. Eine der bekanntesten Lösungen ist Git. Für unser Projekt hatten wir uns jedoch für Unity Collaborate entschieden, da diese Lösung zum einen noch direkter und komfortabler in den Unity Editor integriert ist und wir zum anderen als Studenten von Unity kostenlos mehrere Gigabyte an Cloudspeicher zur Verfügung gestellt bekamen, der direkt von Unity Collaborate genutzt werden konnte. Alles in allem eine sehr inuitive und leicht zu bediende "Rundum-sorglos-Lösung", die uns für viele Stunden in unserer Projektarbeit begleitete und sauber funktionierte. Da Collaborate jedoch Ende 2021/Anfang 2022 von Unity abgeschaltet wurde, waren wir plötzlich mittendrin gezwungen, unser Projekt auf die neue Lösung von Unity zu migrieren: Plastic SCM. Im Gegensatz zu Collaborate entpuppte sich Plastic SCM schnell als mächtiges, aber auch leider sehr komplexes Werkzeug. Aufgrund der mangelnden Erfahrung und zu dem Zeitpunkt auch sehr dürftigen Dokumentation war unser Migrationsprozess von etlichen Problem geplagt, u.a. mussten wir unser Projekt auf eine neuere Unity-Version anheben, da nur bestimmte LTS-Versionen (long term support) für eine Migration auf Plastic SCM kompatibel waren. Das Anheben der Unity-Version brachte dann, wie zu erwarten, weitere Probleme mit sich, z.B. mit unseren Assetpaketen und den Shadern. Mit viel Mühe haben wir es dann zwar geschafft, unser Projekt in der neuen Version sauber zu migrieren und anschließend die Fehler ausmerzen, jedoch war das Ganz ein zeitintensiver und nervenaufreibender Prozess, den wir niemandem wünschen wollen.
Movement, Physics & Kollisionen
Da es in unserem Spiel zum Großteil ums Laufen und Springen geht, müssen sich diese Dinge beim Spielen natürlich flüssig und "gut" anfühlen. Das ist jedoch leichter gesagt als getan. Rudimentäre Bewegungsabläufe wie Laufen, Springen, Rutschen oder Dashen in unsere Programmierlogik zu implementieren war zunächst keine wirklich große Herausforderung. Knifflig wird es erst dann, wenn man sich Gedanken darüber macht, ob sich all diese Dinge auch richtig anfühlen und gut aufeinander abgestimmt sind. Dazu gehören Parameter wie z.B. Trägheit, Beschleunigung, Bremsen und vor allem die Gravitation. Jeder, der schon einmal ein wirklich gutes Jump 'n' Run, wie z.B. ein Spiel aus der Super Mario Reihe, gespielt hat, wird bei seinem eigenen Spiel schnell merken, dass sich alle Bewegungen unsauber, zu träge oder schlichtweg "falsch" anfühlen. Und nach unserer Erfahrung dauert es wirklich sehr lange, bis man mit dem Finetuning an einem Punkt angekommen ist, an dem man mit seinem Movement auch nur halbwegs zufrieden ist. Die nächste Hürde, die sich uns dann wortwörtlich in den Weg stellte, waren die Kollisionen. Da unsere Level zum Großteil aus mehreren Plattformen bestehen, auf denen sich der Spieler bewegt bzw. die er durch Sprünge erreichen kann, muss auch die Kollision der Spielerfigur mit den Objekten sauber sein. Wenn ein Spieler z.B. auf eine Plattform springen möchte, den Sprung jedoch zu kurz setzt und mit der Kante der Plattform zusammenstößt, muss die Spielerfigur entsprechend gestoppt werden - auch das muss implementiert werden, denn ohne eine vernünftige Kollision wird die Spielerfigur nicht gestoppt, sondern rutscht mit der gleichen Geschwindigkeit über die Plattform hinweg. All diese Mechaniken zu implementieren mag dem einen oder anderen auf den ersten Blick vielleicht als einfach erscheinen, jedoch ist genau das Gegenteil der Fall. Da der Kern unseres Spiels eben aus genau diesen Mechaniken besteht, müssen sich diese so gut, flüssig, passend und schnittig anfühlen wie möglich - und das dauert.
Projektumfang/Scope
Im Laufe unserer Projektarbeit kristallisierte sich immer mehr heraus, dass wir uns mit dem Runner-Aspekt unseres Spiels vielleicht etwas zu viel vorgenommen hatten. Ein Spiel, bei dem man zusätzlich zum gegenseitigen Bekämpfen auch noch um die Wette läuft, braucht entsprechend lange Laufstrecken und damit auch umfangreichere Level. Schon bei unserem ersten Level ist uns klar geworden, dass dieses für ein gutes Spielerlebnis noch um ein vielfaches länger sein müsste - dabei war der Aufwand bis dahin schon nicht zu knapp gewesen. Die Herausforderung war also an dieser Stelle, gemeinsam die Entscheidung zu treffen, bei unserem Projekt sinngemäß die Reißleine zu ziehen. Nach vielen Diskussionen wurde letztendlich die Entscheidung getroffen, den Umfang bzw. "Scope" des Projekts zu verkleinern. Die Runner-Komponente wurde entfernt und es wurde ein zweites, neues Level gebaut, das eher einer Arena gleicht. Das Ziel des Spiels war es also nicht mehr, als erster im Ziel, sondern in der Arena der letzte Überlebende zu sein. Auch bei den Items bzw. Powerups haben wir uns von vielen Ideen erstmal nur auf den Raketenwerfer beschränkt, da uns wichtiger ist, ein Item sauber und gut zu implementieren, als mit vielen Ideen zu jonglieren, die alle angefangen, aber nicht beendet werden.
Ziele
In der folgenden Tabelle sind unsere ursprünglich geplanten Ziele in Form von Spielelementen aufgelistet und in "Must Have" bzw. "Nice To Have" unterteilt sowie mit der jeweiligen Priorität quantifiziert. Außerdem wurden der Status farblich markiert, sodass direkt ersichtlich ist, welche Ziele bisher erreicht wurden und welche nicht.
Prio (0-10) | Must Have | Nice To Have |
---|
8 | | Status |
---|
| |
---|
colour | Yellow |
---|
title | IN ARBEIT |
---|
|
Zwei oder mehr Level |
6 | | |
9 | |
|
6 | |
|
5 | Status |
---|
| |
---|
colour | Yellow |
---|
title | IN ARBEIT |
---|
|
Sounds & Musik |
|
10 | | |
6 | Status |
---|
| |
---|
colour | Yellow |
---|
title | IN ARBEIT |
---|
|
Hauptmenü / Multiplayer-Lobby |
|
6 | |
|
6 | Status |
---|
| |
---|
colour | Yellow |
---|
title | IN ARBEIT |
---|
|
Game-Over-Screen |
|
6 | Einstellungen bzw. Settings |
|
9 | | Movement: Slide bzw. Dash |
9 | | |
9 | |
|
9 | |
|
5 | Controller-Implementierung |
|
7 | Status |
---|
| |
---|
colour | Yellow |
---|
title | IN ARBEIT |
---|
|
Gameplay-Effekte | |
Zeitaufwand/Stundenrechnung
Info |
---|
Wird aktuell in einer separaten Excelliste gepflegt und zu einem späteren Zeitpunkt in das Wiki übertragen. |
Lessons Learned
Info |
---|
Wird gegen Ende der Projektarbeit ausformuliert. |
Tools
Im Folgenden noch eine vollständige Auflistung der verwendeten Tools, Unity-Plugins und Assets:
- Unity Version 2020.3.8f1 mit DX11 und HDRP (High Definition Render Pipeline)
- Unity Collab
- Plastic SCM
- Blender
- Audacity
- Discord
- ShareX
- Handbrake
- Instagiffer
- Microsoft Excel