Idee
Als wir gegen Ende des dritten Semesters unsere Minors wählen mussten, stellte ich mit grosser Freude fest, dass es ein Minor zur «Unity Game Engine» gab. Ich wollte schon immer mal versuchen, ein eigenes Videospiel zu erstellen, jedoch wusste ich nie wirklich, wo ich am besten anfangen sollte. Leider ist das Minor nicht zu Stande gekommen, da sich wahrscheinlich zu wenig Studenten dafür interessiert haben. Die Idee, mich mit Unity zu vertiefen, war aber bereits eingesickert und ich entschloss mich, mein erstes Videospiel eigenhändig zu produzieren.
Unity vs. HTML
Den Entschluss, Unity anstatt z.B. einfaches HTML zu verwenden, fällte ich bereits relativ früh. Obwohl der Aspekt, das bestmögliche aus HTML herauszuholen, ebenfalls interessant war, interessierte mich Unity trotzdem mehr, da die Möglichkeiten endlos sind. Ich wusste, dass sowohl viele professionelle Spiele als auch viele Indie- oder E-Learning Spiele auf Unity basieren. Wieviel Arbeit dahinter steckt, etwas komplett Fremdes zu lernen, mit Programmiersprachen, die ich überhaupt nicht kannte, war mir anfangs noch nicht bewusst.
C# - “Object Oriented Programming”
Die Programmiersprache, die ich in den Skripts verwenden musste, nennt sich C#. Als ich mit den ersten Tests anfing und ein paar Tutorials folgte, war alles sehr verwirrend. Es kamen viele Wörter vor, die ich noch nie gesehen hatte und die Art und Weise, wie das ganze funktionierte, war mir fremd. Meine bescheidenen HTML-, CSS- und PHP-Kenntnisse halfen mir nur bedingt weiter. Die grundlegenden Theorien, wie die Arten von Variablen etc. jedoch um einiges mehr. Um meinen eigenen Code meines «Testprojekts» besser verstehen- und in einem weiteren Schritt diesen auch meinen Bedürfnissen anzupassen und erweitern zu können, habe ich eine ganze Tutorial-Serie zu C# durchgemacht. Dies half auf jeden Fall, das Projekt schneller voranzutreiben. Die grösste Schwierigkeit lag darin, dass einige Skripts für sich alleinstehen und andere Zugriff auf andere haben. Dies führte zu grossen Verwirrungen, was die Schreibweise des Codes angeht. Abschliessend zur Programmiersprache kann ich sagen, dass es am ähnlichsten zu Javascript ist.
Vorgehen
In einem ersten Schritt wollte ich wissen, ob das Projekt überhaupt machbar ist. Deshalb fing ich schon sehr früh mit den ersten Tests an. Ich orientierte mich an einer Tutorial-Serie, die ich auf YouTube fand und machte diese komplett durch. Leider musste ich feststellen, dass das ganze Projekt ein riesen Gebastel war, wo nach und nach nichts mehr funktionierte. Ich hatte einen Charakter der zwar springen, ducken und eine Waffe schwingen konnte, jedoch war es für mich fast nicht möglich etwas hinzuzufügen, ohne alles andere wieder kaputt zu machen. Gewisse Teile des Tutorials funktionierten auch nicht mehr, da meine Unity-Version neuer war als diejenige, die in den Videos benutzt wurde. Mein grosser Schwachpunkt war sicherlich auch das Fehlen von Programmierwissen in C#, weshalb ich mich danach zuerst mit der Programmiersprache beschäftigte.
Der zweite Schritt war es, komplett neu anzufangen. Ich hatte ein Tutorial gefunden, welches fast alle Grundbausteine behandelte und mit meinem neu angeeigneten Wissen und den Learnings vom ersten Durchlauf lief es bereits um einiges besser. Ich habe auch nur an einem Level gearbeitet, um alle Spielmechaniken zu testen und zu implementieren. Der Game-Over-Screen, End-Screen oder mehrere Levels folgten erst zu einem späteren Zeitpunkt.
Nachdem die Grundbausteine vorhanden waren, habe ich eine grosse Liste mit Spielmechaniken, Bugs und anderen generellen Sachen erstellt und diese nach Priorität geordnet. Dies gab mir eine gute Übersicht um zu sehen, an was ich als nächstes arbeiten sollte.
Game Design
Es war mir von Anfang an klar, dass ich ein Jump ’n’ Run machen wollte. Ein Klassiker, der dank Mario fast jeder versteht und von den Spielmechaniken her auch am realistischsten erscheint, um als «Ein-Mann-Studio» ohne jegliche Erfahrung zu produzieren zu können.
Bezüglich Game Design war die grösste Herausforderung das Level-Design. Ich endschied mich für fünf Level, die nach und nach schwieriger werden sollten. Um den Wiederspielwert zu erhöhen und die stundenlange Arbeit nicht innert zwei Minuten zunichte zu machen, wollte ich schon erreichen, dass das Spiel für die meisten nicht beim ersten Versuch durchzuspielen ist. Ebenfalls habe ich auf jedem Level einen Diamanten versteckt, sodass man immer noch etwas zu tun hat, wenn man die fünf Level langsam in den Griff bekommt. Ganz am Schluss habe ich noch einen Timer hinzugefügt, der den Spieler anspornen soll, das Spiel möglichst schnell durchzuspielen oder den persönlichen Highscore zu brechen.
Artstyle
Die Sprites stammen allesamt vom Unity Asset Store. Als ich die ersten Tests durchführte, hatte ich versucht, selbst Pixel-Art zu machen, da es relativ einfach aussah. Jedoch musste ich sehr schnell feststellen, dass dies alles andere als einfach ist und ich dafür definitiv kein Talent habe. Ich habe nur kleine Veränderungen vorgenommen, wie z.B. den «Health-Icons» einen schwarzen Rahmen gegeben, damit es besser zu den anderen Sprites passt.
Sound Design
Die Musik habe ich in Cubase 10 produziert. Es dauerte eine Weile, um die richtige Stimmung zu finden. Zuerst experimentierte ich ausschliesslich mit 8-bit/Retro Sounds, empfand dies jedoch als äusserst limitierend. In weiteren Versuchen und auch bei genauerem Betrachten der Sprites kam mir die Idee, die Retro-Sounds mit einer Gitarre und anderen modernen Synthesizern zu vermischen. Dies resultierte in einem, meiner Meinung nach, sehr einzigartigen Soundtrack, den ich für das ganze Spiel verwendet habe.
Die meisten Soundeffekte im Spiel, wie z.B. die Explosionen, Jump-Sounds, etc. stammen von Libraries und dem Unity Asset Store. Ich habe sie lediglich meinen Bedürfnissen angepasst, indem ich sie vom Pitch oder in der Länge verändert habe.
Bug Fixing
«Compiler Error». Nach jedem neuen Feature, welches ich implementiert hatte, kriegte ich in der Regel diese Nachricht. Diese Fehler im Code waren zwar nervig, jedoch stand immer ganz genau, wo der Fehler liegen sollte, was das Beheben um einiges erleichterte. Viel schwieriger zu beheben waren die Bugs, die keinen fatalen Fehler gaben und einfach das Spielerlebnis stark beeinträchtigten. Hier einige Beispiele, die ich in dieser Zeit (hoffentlich) beseitigt habe:
- Unendliches Springen nach dem Töten eines Gegners
- Wenn man auf einen Gegner fiel ohne vorher zu springen, erlitt man Schaden
- Nach dem Runterfallen sprang die Kamera in alle Ecken
- Nach dem Neustarten hatte man auf einmal zwei Charaktere
Learnings
Mit diesem Projekt habe ich sehr viel dazu gelernt. Die wichtigsten Learnings sind für mich:
- Prioritäten von Anfang an zu setzen, da jedes noch so kleine Feature oft ein Haufen Arbeit mit sich bringt (und wahrscheinlich das ganze Spiel wieder kaputt macht)
- Den Code sauber halten
- Ein tieferes Verständnis für «Object Oriented Programming» (wobei gewisse Stellen des Codes nach einem halben Jahr schon wieder ziemlich unverständlich sind, obwohl ich versucht habe, fleissig zu kommentieren)
- Das Spiel zu testen macht sehr viel weniger Spass als gedacht, jedoch ist es ein gutes Gefühl, endlich fertig zu sein und ein funktionierendes Spiel zu haben
- Wir haben im Unterricht ab und zu gehört, dass man nicht Hardcoden sollte. Bis anhin war dies jedoch nie wirklich ein Problem. Bei diesem Projekt aber, wo mehrere Skripte für verschiedene Sachen zuständig sind, war es sehr mühsam, Änderungen vorzunehmen. Nachdem ich den Fehler ein paar Mal gemacht hatte, versuchte ich weiteres Hardcoding so gut wie möglich zu vermeiden
- Es war mir von Anfang an klar, dass das Projekt ein grosses Unterfangen war, jedoch hatte ich den Arbeitsaufwand doch ein wenig unterschätzt. Es hat mir sehr geholfen, dass ich schon während den Semesterferien viel daran gearbeitet hatte, sonst wäre es mit der Deadline knapp geworden
