Entwicklung eines Jump'n'Run Spiels und Bewertung des Ein usses von Erfolgssystemen - OPUS
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Fachbereich 4: Informatik
Entwicklung eines Jump'n'Run
Spiels und Bewertung des Ein usses
von Erfolgssystemen
Bachelorarbeit
zur Erlangung des Grades Bachelor of Science (B.Sc.)
im Studiengang Computervisualistik
vorgelegt von
Anthea Weiler
Erstgutachter: Prof. Dr.-Ing. Stefan Müller
Institut für Computervisualistik, AG Computergraphik
Zweitgutachter: Bastian Krayer, M. Sc.
Institut für Computervisualistik, AG Computergraphik
Koblenz, im November 2019
Erklärung
Ich versichere, dass ich die vorliegende Arbeit selbständig verfasst und keine
anderen als die angegebenen Quellen und Hilfsmittel benutzt habe.
Ja Nein
Mit der Einstellung der Arbeit in die Bibliothek bin ich einverstanden.
.................................................................................
(Ort, Datum) (Unterschrift)
Zusammenfassung
Diese Bachelorarbeit befasst sich mit der Konzeption, Implementierung und
Evaluation eines Jump'n'Run Spiels und der Betrachtung des Ein usses von
Erfolgssystemen auf Spieler. Im Spiel Age of Tunes spielt man Bardur, den
bartlosen Barden und muss versuchen, die ver uchten magischen Geschöpfe
in der Welt Harmonica zu befreien. Der Schwerpunkt der Arbeit lag bei der
sauberen Konzeption und schrittweisen Entwicklung des Spiels, ansprechen-
der graphischer Qualität, Einbindung von Gegnern, einem Minispiel und der
Betrachtung von Auswirkungen eines Erfolgssystems auf Spieler. In einer ab-
schlieÿenden Evaluation konnten das Spiel und das Verhalten bezüglich der
Erfolge bewertet werden.
Abstract
This bachelor thesis deals with the conception, implementation and evalua-
tion of a Jump'n'Run game and the consideration of the in uence of achiev-
ment systems on players. In the game Age of Tunes you play Bardur, the
beardless bard and have to try to free the cursed magical creatures in the
world Harmonica. The emphasis of the thesis was the clean conception and
gradual development of the game, appealing graphic quality, integration of
opponents, a mini-game and the consideration of eects of an achievment
system on players. In a nal evaluation the game and the behavior could be
evaluated regarding the achievments.
Inhaltsverzeichnis
1 Einleitung 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Struktur der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Grundlagen 2
2.1 Jump'n'Run Spiele . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Erfolgssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Spielengine: Unity . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1 Bausteine . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Verwendete Werkzeuge . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1 Unity Anima 2D . . . . . . . . . . . . . . . . . . . . . 10
2.4.2 Krita . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.3 Inkscape . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Konzeption 11
3.1 Spielkonzept und Spielmechanik . . . . . . . . . . . . . . . . . 11
3.2 Erfolge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Story . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4 Implementierung 12
4.1 Aufbau des Spiels . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Leveldesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Charakterdesign . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.1 Erstellung und Kon guration des Charakters . . . . . 14
4.3.2 Animation des Charakters . . . . . . . . . . . . . . . . 17
4.3.3 Nutzung der Animationen im Spiel . . . . . . . . . . . 18
4.4 Gegnerdesign . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5 Weitere GameObjects . . . . . . . . . . . . . . . . . . . . . . 22
4.6 Erstellung von Benutzerober ächen . . . . . . . . . . . . . . . 23
4.6.1 Haupt- und Pausenmenü . . . . . . . . . . . . . . . . . 23
4.6.2 Zählanzeigen . . . . . . . . . . . . . . . . . . . . . . . 23
4.6.3 Erfolgssystem . . . . . . . . . . . . . . . . . . . . . . . 24
4.7 Spielobjekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.7.1 Spieler . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.7.2 Gegner . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.7.3 Plattformen . . . . . . . . . . . . . . . . . . . . . . . . 26
4.7.4 Bewegende Plattformen . . . . . . . . . . . . . . . . . 26
4.7.5 Fallende Plattformen . . . . . . . . . . . . . . . . . . . 26
4.7.6 Sammelbare Runen . . . . . . . . . . . . . . . . . . . . 26
4.7.7 Checkpoints . . . . . . . . . . . . . . . . . . . . . . . . 27
4.7.8 Hintergrundmusik . . . . . . . . . . . . . . . . . . . . 27
i
4.7.9 Levelende . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.7.10 Killbox . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.7.11 Spawnpunkte . . . . . . . . . . . . . . . . . . . . . . . 28
4.8 Levelaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.8.1 Level 1 und 2 . . . . . . . . . . . . . . . . . . . . . . . 28
4.8.2 Minispiel . . . . . . . . . . . . . . . . . . . . . . . . . 30
5 Evaluation 31
5.1 Zielsetzung der Studie . . . . . . . . . . . . . . . . . . . . . . 31
5.2 Planung und Durchführung . . . . . . . . . . . . . . . . . . . 31
5.3 Auswertung der Testergebnisse . . . . . . . . . . . . . . . . . 32
6 Ausblick und Fazit 37
6.1 Ausblick für das Spiel . . . . . . . . . . . . . . . . . . . . . . 37
6.2 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7 Anhang 41
7.1 Informationsblatt . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.2 Fragebogen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.3 Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
ii
1 Einleitung
Um dem Leser einen Überblick über meine Arbeit zur Verfügung zu stellen,
beginne ich zuerst mit meiner dahinterliegenden Motivation, fahre fort mit
der dazugehörigen Aufgabenstellung und beende mit einer Übersicht über
die Struktur der Arbeit.
1.1 Motivation
Im Bereich der Computergra k haben sich in der letzten Jahren eine Rei-
he von Entwicklungswerkzeugen gebildet, die einerseits eine Vertiefung von
Programmierkenntnissen und andererseits die Konzeption und Implementie-
rung von Spielen auf eine unkomplizierte Art und Weise ermöglicht. Hin-
zukommend sind heutzutage in vielen Spielen Erfolgssysteme enthalten, die
Spieler anspornen sollen, ihre Leistung zu verbessern. Da ich dieses Spielkon-
zept sehr interessant nde, wollte ich dieses Verhalten selbst analysieren. Ich
habe mich für ein Jump'n'Run Spiel entschieden, weil dies die ersten Spiele
waren, die ich in meiner Kindheit gespielt habe. Jill of the Jungle war mein
erstes Computerspiel, das mich in seinen Bann gezogen hat. So erlebte ich
meine ersten Abenteuer in der digitalen Welt, sammelte Diamanten, Äpfel
und Schlüssel, kämpfte gegen unterschiedliche Gegner und überwand zahl-
reiche Hindernisse, um Level für Level zu absolvieren. Deswegen war es mein
Wunsch, für meine Bachelorarbeit ein Spiel aus dem Genre zu entwickeln,
dass mich bereits als Kind verzaubert hat.
1.2 Aufgabenstellung
Ziel dieser Arbeit ist die Konzeption und die prototypische Implementierung
eines Jump'n'Run Spiels. Die Schwerpunkte sind dabei die Recherche und
Einarbeitung in die, für die Entwicklung eines Spiels, relevanten Grundla-
gen. Hierzu gehören auch das Ermitteln einer geeigneten Spielengine und
Werkzeuge, um ein Spiel zu realisieren. Mit dem angeeigneten Wissen ist der
nächste Schritt die Konzeption und die prototypische Implementierung des
Spiels. Dazu gehört eine ansprechende gra sche Qualität, Einbindung von
Gegnern, einem Minispiel und ein Erfolgssystem. Abschlieÿend wird eine
Studie über das Spiel und dem Verlangen von Spielern Erfolge zu erreichen
durchgeführt und interpretiert.
1.3 Struktur der Arbeit
Diese Arbeit beginnt in Kapitel 2 mit einer Erläuterung der jeweiligen Grund-
lagen, die zum Verständnis dieser Arbeit von Bedeutung sind. Hierzu gehört
die De nition des Computerspielgenres Jump'n'Run. Es wird erklärt, was ge-
nau Unity ist und welche Bausteine von Unity es zu verstehen gilt. Es werden
verwendete Assets und die beiden Gra kprogramme Krita und Inkscape
1
kurz vorgestellt. In Kapitel 3 geht es um die Konzeption des Spiels. Hier
werden das Spielkonzept und die Spielmechanik erläutert und die Geschich-
te hinter dem Spiel erzählt. Kapitel 4 beschäftigt sich mit der Implemen-
tierung des Spiels. Hierbei gebe ich zuerst eine Übersicht des Spielaufbaus.
Als Nächstes wird die Gestaltung der einzelnen Szenen erläutert und das
Erfolgssystem vorgestellt. Auch wird die Erstellung des Spielcharakters, der
Gegner und der Gegenstände im Spiel erläutert. In Kapitel 5 werde ich mei-
ne Evaluation zu dem Spiel vorstellen. Im letzten Kapitel schlieÿe ich mit
einem, aus der Studie resultierendem, Fazit und Ausblicken für das Spiel ab.
2 Grundlagen
In diesem Kapitel erkläre ich, was genau Jump'n'Run Spiele sind, stelle die
Spielengine Unity vor inklusive genutzter Komponenten. Weiterhin gebe ich
einen kurzen Einblick in verwendete Unity Assets und ansonsten verwendete
Software.
2.1 Jump'n'Run Spiele
Jump'n'Run (im Deutschen Springen und Rennen) ist sowohl eine Bezeich-
nung des Genres als auch des Spielprinzips. Man steuert einen Charakter
und muss durch Laufen und Springen zum Ende eines Levels gelangen. Den
Ursprung von Jump'n'Run Spielen ndet man im Arcade-Bereich. Als eines
der ersten Spiele gilt hier die Spielhallen-Version von Donkey Kong (siehe
1
Abbildung 1 )aus dem Jahre 1981.
Abbildung 1: Donkey Kong aus dem Jahre 1981
In diesem Spiel steuert man den Charakter Jumpman, später bekannt als
Super Mario. Diesen navigiert man durch Springen und Klettern durch die
1
Bildquelle: https://www.imdb.com/title/tt0176664/mediaviewer/rm1168400128
(aufgerufen am 24.10.2019)
2
einzelnen Level, um schlussendlich eine Prinzessin aus den Fängen eines rie-
sigen Gorillas zu befreien. Dieses Spielprinzip ermöglichte es dem Nintendo
Konzern in den 1980er Jahren, mit ihrer ersten Heimkonsole NES (Nintendo
Entertainment System), einen riesigen Erfolg zu erzielen. Der Titel Super
Mario Bros. , der ab 1985 der Konsole beilag, gilt bis heute als eines der
meistverkauften Videospiele aller Zeiten [3]. Auf Grund des Erfolges seitens
Nintendo sind mit der Zeit viele weitere Jump'n'Run Spiele entstanden.
Ein anderes Beispiel ist Jill of the Jungle aus dem Jahre 1992, welches von
Epic MegaGames veröentlicht wurde.
Abbildung 2: Screenshot aus dem Spiel Jill of the Jungle
Die Protagonistin des Spiels ist die Amazone Jill, welche man durch 16 unter-
schiedlich gestaltete Level begleitet. Das Spiel beinhaltet zusätzlich zu den
klassischen Jump'n'Run Inhalten noch Rätsel. So muss man geheime Räume
nden oder die Gestalt des Charakters verändern, um bestimmte Orte errei-
chen zu können. Als Fisch kann man beispielsweise durch Wasser schwimmen
oder als Vogel iegen, um bestimmte Stellen zu erreichen.
Die ersten 3D Jump'n'Run Spiele gibt es seit 1996. Der Vorreiter ist Crash
2
Bandicoot (siehe Abbildung 3 ) von dem Entwicklerstudio Naughty Dogs.
Abbildung 3: Crash Bandicoot aus dem Jahre 1996
Das Prinzip des Spiels hat sich nicht verändert, weiterhin muss man die
2
Bildquelle: http://www.hardcoregaming101.net/crash-bandicoot/ (aufgerufen am
24.10.2019)
3
Spiel gur meist durch Hüpfen und Laufen zum Ende des Levels geleiten.
Auf dem Weg gibt es Gegenstände zum Einsammeln und Speicherpunkte,
um das Level nicht von vorne beginnen zu müssen. Zusätzlich konfrontieren
die Spiel gur Gegner, die sie mit einer Wirbelattacke bezwingen muss.
Zwar sind Jump'n'Run Spiele in der heutigen Zeit nicht mehr so populär wie
zu ihren Ursprüngen, doch ist das Genre nach wie vor noch lebendig und
ndet auch heute noch neue Spielanwendungen.
Als Beispiel wäre unter anderem Ori and the Blind Forest (siehe Abbildung
3
4 .)aus dem Jahre 2015, welches Anfang 2020 einen zweiten Teil erhalten
wird.
Abbildung 4: Ausschnitt aus Ori and the Blind Forest
In einer malerischen Welt spielt man den kleinen Ori und versucht, den
Wald Nibel zu retten. Auch dieses Spiel ist kein reines Geschicklichkeits-
spiel, sondern bietet auch Rätsel, um bestimmte Orte zu erreichen. Um die
Fähigkeiten des Protagonisten zu verstärken, muss man Erfahrungspunkte
sammeln, um in einem Fähigkeitenbaum neue Fähigkeiten zu erlangen oder
zu verbessern.
2.2 Erfolgssysteme
Die erste Möglichkeit, sich in Spielen mit anderen zu messen oder sich selbst
zu übertreen, ist die Highscore -Tabelle. Dies ist eine Übersicht über die
besten Spieler. Veranschaulicht wird die Punktzahl, welche in einer abstei-
genden Reihenfolge sortiert ist. Im Jahr 2005 führte Microsoft zusätzlich zu
den etablierten Highscores einen Game Score ein, welcher es Spielern ermög-
licht, durch das Abschlieÿen bestimmter Bedingungen, Erfolge freizuschalten
[2]. Dies gewährt dem Spieler neue Möglichkeiten das Spielerlebnis wahrzu-
nehmen. Ein Beispiel für solch ein Erfolgssystem ndet sich in Abbildung
4
5 .
3
Bildquelle: https://store.steampowered.com/ (aufgerufen am 27.10.2019)
4
Bildquelle: https://www.bued.de/World-of-Warcraft-Cataclysm-Spiel-
42972/News/WoW-Spieler-Erfolge-pro-Account-statt-pro-Charakter-vorerst-nicht-in-
Sicht-813289/galerie/1481629/?fullsize (aufgerufen am 27.10.2019)
4
Abbildung 5: Darstellung der Erfolge in World of Warcraft
Zusätzlich ist noch zu erwähnen, dass das Abschlieÿen von Erfolgen nicht
zwingend notwendig für den ursprünglichen Spielverlauf ist. Der Grund,
warum Erfolge unter Spielern sehr beliebt sind, hat unterschiedliche An-
sätze. Ein Punkt, ist die Möglichkeit Erfolge mit denen anderer Spieler zu
vergleichen. Eine Reihe von Spielen oder Plattformen bieten sogar einen di-
rekten Vergleich mit anderen Spielern an. Einen weiteren Punkt stellt der
Sammeltrieb dar, welcher das Bedürfnis in einem Spieler erweckt, die Er-
folge zu komplettieren. Um alle Möglichkeiten auszuschöpfen, die ein Spiel
bietet, kann man je nach Anzahl der Erfolge langzeitig beschäftigt sein. Der
Nachteil dabei ist allerdings, dass Erfolge auch eine gewisse Form der Frus-
tration verursachen können. Zum einen, weil nicht jeder Erfolg einfach zu
bewältigen ist und somit viele Versuche erfordern kann. Zum anderen kann
die Menge der zu erreichenden Erfolge sehr zeitintensiv sein. Immer mehr
Plattformen haben dieses Erfolgssystem über die Zeit implementiert. Aller-
dings wird nicht überall das Abschlieÿen eines Erfolges durch Erhalten einer
virtuellen Trophäe repräsentiert. In Spielen wie World of Warcraft kann
man dadurch Belohnungen wie Reittiere freischalten. Auch ist es möglich,
in Multiplayer -Spielen durch Erfolge nachweisen zu können, dass man einen
bestimmten Spielabschnitt bereits abgeschlossen hat.
2.3 Spielengine: Unity
Der Unity Editor ist die Spielentwicklungsumgebung für Windows- und Mac
OS X-Systeme und wird von der aus Dänemark stammenden Firma Unity
Technologies entwickelt [1]. Für Unity werden unterschiedliche Abonnements
für Privatpersonen und Unternehmen angeboten. In der Basisvariante Per-
5sonal ist die Nutzung von Unity kostenlos, solange der Jahresumsatz oder
jährliche Zuwendungen einen Betrag von 100.000$ nicht übersteigen.
Im Unity Editor kann man sowohl 2D als auch 3D Projekte erstellen. Zu
Beginn verfügt man nach der Erstellung über eine Musterszene, die in 2D nur
eine Kamera enthält und in 3D zusätzlich eine Lichtquelle. Auf die einzelnen
Bausteine um ein Spiel zu entwickeln, werde ich im Abschnitt 2.3.1 genauer
eingehen.
Über das integrierte UI-System (in deutsch System für Benutzerschnittstel-
len ) wird es dem Entwickler ermöglicht, schnell und intuitiv Benutzerober-
ächen, wie beispielsweise das Hauptmenü, zu erstellen.
Mit Hilfe des Play -Modus ist es während der Spielentwicklung jederzeit mög-
lich, das eigene Spiel zu testen. Ist der Play -Modus aktiv, kann man Ände-
rungen an seinem Spiel vornehmen, um beispielsweise die Sprunghöhe der
Spiel gur leichter anzupassen. Allerdings werden Änderungen während des
Play -Modus nicht übernommen, sondern müssen nach dessen Beendigung
angepasst werden.
Einer der gröÿten Vorteile bei Unity ist der Multiplattform-Support. Dieser
ermöglicht es, ein Spiel zu entwickeln und mit einem Klick auf über 25 ver-
schiedene Plattformen wie Mobilgeräte, Desktops, Konsolen, TV, VR, AR
und in Web-Anwendungen zu exportieren.
Im folgendem Abschnitt werde ich die von Unity bereitgestellten Komponen-
ten und Elemente vorstellen, welche in die Entwicklung des Spiels einge os-
sen sind.
2.3.1 Bausteine
Die Erläuterungen zu den jeweiligen Komponenten und Elementen sind mit
Hilfe der Unity Dokumentation [7] entstanden.
Inspector Window
Über den Inspector erhält man detailreiche Informationen über die Game-
Objects. Zu Beginn verfügt ein GameObject nur über eine Transform Kom-
ponente, welche die Position, Rotation und Skalierung des Objektes enthält.
Mit Add Component kann man über das Inspector Window (siehe Abbildung
GameObjects erweitern. Unity bietet ein breites
6) die Eigenschaften eines
Arsenal an Komponenten, von denen ein paar im Verlauf dieses Abschnitts
vorgestellt werden. Auch kann man eigene Skripte über den Inspector hin-
zufügen.
6Abbildung 6: Darstellung des Inspector Window
Assets
Als Assets werden die digitalen Inhalte bezeichnet, welche sich im Projekt-
ordner be nden. Dazu gehören beispielsweise Texturen, Audiodateien und
Skripte. Zugri auf die Assets hat man im Unity Editor über das Fenster
Project, siehe dazu Abbildung 7.
Scenes
Über das Fenster Scene GameObjects in
(siehe Abbildung 7) kann man die
Game-
einer Szene interaktiv positionieren oder verändern. Möchte man ein
Object der Szene hinzufügen, wählt man eines aus dem Fenster Project aus
und fügt dieses durch Ziehen und Ablegen der Szene hinzu. Jede erstellte
Szene wird als eine eindeutige Ebene betrachtet und erhält einen Index.
Abbildung 7: Darstellung der Szenenübersicht
7GameObject
Das GameObject ist das wichtigste Konzept im Unity Editor. Jedes Objekt
im Spiel ist ein GameObject und verfügt zu Beginn nur über eine Position
in der Szene. Um beispielsweise einen Spielcharakter zu entwickeln, benötigt
das GameObject bestimmte Eigenschaften (Komponenten), die ihm über den
Inspector hinzugefügt werden können.
Sprites
Sprites sind 2D Gra k-Objekte, welche gra sche Texturen beinhalten.
SpriteRenderer
Die SpriteRenderer -Komponente Sprite und steuert, wie es vi-
rendert das
suell in einer Szene erscheint. Über den SpriteRenderer ist es möglich, dem
GameObject eine Textur zuzuweisen.
Collider 2D
Collider haben unterschiedliche Einsatzmöglichkeiten. So können sie zum
einen dazu verwendet werden, den Boden im Spiel zu kennzeichnen, damit
die Spiel gur nicht durch die Textur hindurchfällt. Zum anderen können sie
als Auslöser für unterschiedliche Aktionen verwendet werden. Markiert man
imInspector den Collider als Trigger (Auslöser), kann man über ein Skript
diesemTrigger eine bestimmt Funktion zuweisen. Zum Beispiel stirbt der
Charakter, wenn dieser mit dem Collider des Gegners in Berührung kommt.
Typen von 2D Collidern:
• BoxCollider für quadratische und rechteckige Kollisionsbereiche.
• CircleCollider für kreisförmige Kollisionsbereiche.
• PolygonCollider für Freiformkollisionsbereiche.
• EdgeCollider für Freiformkollisionsbereiche und jene, die nicht voll-
ständig umschlossen sind (z.B. abgerundete konvexe Ecken).
Rigidbody 2D
Damit ein GameObject bewegt werden kann, benötigt es einen Rigidbody
2D. Mit dieser Komponente wird dem GameObject eine Interaktion mit der
Unity Physics Engine ermöglicht. Normalerweise bestimmt der Unity Editor
Position, Skalierung und Rotation eines Spielobjektes über die Transform -
Komponente. Dies wird allerdings durch die vom Rigidbody 2D vorgegebene
Position und Rotation überschrieben und aktualisiert. Über den Rigidbody
82D wird auch die Stärke der Gravitation des Spielobjektes eingestellt sowie
dessen Masse.
Physics Material 2D
Ein Physics Material 2D wird verwendet, um die Reibung und den Auf-
prall, der zwischen 2D-Physikobjekten beim Aufprall entsteht, einzustellen.
Einem GameObject wird diese Eigenschaft über einen Collider in der Rubrik
Material hinzugefügt.
Tags
Ein Tag ist ein Referenzwort, das einem oder mehreren GameObjects zu-
geordnet werden kann. So können beispielsweise Player Tags für spielerge-
steuerte Charaktere und Enemy Tags für nicht spielergesteuerte Charaktere
de niert werden. Das gilt auch für Elemente, die der Spieler in einer Sze-
ne sammelt, welche beispielsweise mit einem Collectable Tag versehen sind.
Tags sind hilfreich, um GameObjects für Skriptzwecke zu identi zieren. Sie
stellen sicher, dass GameObjects nicht manuell per Drag and Drop zu den
Eigenschaften eines Skripts hinzugefügt werden müssen, wenn der gleiche
Skriptcode in mehreren GameObjects verwendet wird. Nützlich sind Tags
für Trigger im Collider bei einem Steuerskript. Dadurch ist es möglich, zu
ermitteln, ob der Spieler z.B. mit einem Feind, einer Requisite oder einem
Sammelobjekt interagiert.
Prefabs
Mit dem Prefab-System von Unity ist es möglich, GameObjects komplett mit
allen Komponenten, Eigenschaftswerten und untergeordneten GameObjects
zu erstellen, zu kon gurieren und zu speichern. Das Prefab Asset dient als
Vorlage, aus der neue Prefab -Instanzen in der Szene erstellt werden können.
Wenn ein GameObject, das auf eine bestimmte Weise kon guriert wurde -
wie ein Nicht-Spieler-Charakter (NSC), eine Requisite oder ein Stück Land-
schaft - an mehreren Stellen in der Szene oder über mehrere Szenen in einem
Projekt hinweg wiederverwendet wird, sollte es in eine Vorabversion konver-
tiert werden. Dies ist besser als das Kopieren und Einfügen desGameObjects,
denn das Prefab -System ermöglicht es, alle Kopien automatisch synchron zu
halten. Alle Bearbeitungen, die an einem Prefab Asset vorgenommen wer-
den, spiegeln sich automatisch in den Instanzen dieses Prefab wieder, so dass
mühelos umfassende Änderungen im gesamten Projekt vorgenommen wer-
den können, ohne immer wieder die gleiche Bearbeitung an jeder Kopie des
Assets machen zu müssen.
9Animator
Die Animator -Komponente wird benötigt, um einem GameObject innerhalb
einer Szene eine Animation zuzuordnen. Die Animator -Komponente benö-
tigt eine Referenz auf eine Animator -Steuerung. Gesteuert wird die Ani-
mation durch Animationsebenen, welche durch Animation State Machines
und Animation Blend Trees erstellt werden. Diese werden ihrerseits durch
Animationsparameter gesteuert. Der gleiche Animator Controller kann von
mehreren Modellen mit Animator -Komponenten referenziert werden.
PlayerPrefs
Mit Hilfe der PlayerPrefs -Klasse ist es möglich spezielle Werte zwischen den
Spielsitzungen zu speichern und auf diese später zuzugreifen. In Abschnitt
4.6.2 be ndet sich eine Möglichkeit für die Nutzung dieser Klasse.
2.4 Verwendete Werkzeuge
Hier werden die verwendeten Werkzeuge aufgelistet und kurz beschrieben.
2.4.1 Unity Anima 2D
Unity Anima 2D ist ein Asset, welches von Unity Technologies entwicklet
wurde und Animationen von 2D Texturen innerhalb des Unity Editor er-
möglicht. Anima 2D beinhaltet viele Erweiterungen für Unity. Infolgedessen
wird eine Knochenhierarchie hinzugefügt, um dem 2D GameObject ein Ske-
lett hinzuzufügen. Mit einem Mesh Editor, wird die Feinabstimmung des
Meshes ermöglicht, um Knoten, Löcher, Kanten und Randbeschränkungen
hinzufügen, ebenso wie diese löschen zu können, um die gewünschte Triangu-
lation zu erreichen. Zum Schluss noch die 2D Inverse Kinimatics, welche es
ermöglicht, konsistente Posen für Gliedmaÿen und Knochenketten beliebiger
Länge zu erstellen. Genauer werde ich in Kapitel 4.3 bei der Erstellung des
Spielcharakters auf die Funktionsweise von Anima 2D eingehen.
2.4.2 Krita
Krita ist ein kostenloses Zeichenprogramm, welches von der Krita Foundation
entwickelt wurde. Krita verfügt über eine breite Palette an unterschiedlichen
Pinseln, Stiften und Airbrush -Tools, die eine sehr detailreiche Gestaltung
einer Textur ermöglichen. Durch die Nutzung von unterschiedliche Ebenen,
kann man eine Textur in mehrere Bereiche aufteilen, diese einzeln bearbeiten
und später in einzelne Segmente separat abspeichern.
102.4.3 Inkscape
Inkscape ist eine kostenlose Software zur Erstellung von Vektorgra ken. Von
Vorteil sind hier die Verwendung von Bezier Splines, die es ermöglichen,
die Form von Gra ken leicht zu verändern (genauer gehe ich in Kapitel 4.4
darauf ein).
3 Konzeption
In diesem Kapitel werden das Spielkonzept und die Spielmechanik erläutert.
Es gibt eine Einführung in die Geschichte des Spiels und eine Übersicht der
enthaltenen Erfolge.
3.1 Spielkonzept und Spielmechanik
Das Konzept des Spiels ist die Entwicklung eines klassischen Jump'n'Run
Spiels. Man steuert den Charakter durch drei unterschiedliche Level. Dabei
muss der Charakter Gegenstände einsammeln, Gegner bekämpfen und Hin-
dernisse überwinden. Da es sich um ein 2D Spiel handelt, ist die Sicht auf
die Szene von der Seite dargestellt.
Die ersten beiden Level haben die Elemente eines klassischen Jump'n'Run
Spiels. Im ersten Level muss der Charakter sowohl auf fest platzierte als auch
bewegliche Plattformen springen. An unterschiedlichen Stellen be nden sich
Gegner, die der Spieler besiegen muss. Zusätzlich gibt es im ersten Level
für den Spieler unterschiedliche Erfolge, welche er erreichen kann. Diese sind
allerdings nicht für den Abschluss des Levels erforderlich. In Abschnitt 4.6.3
gehe ich näher auf das Erfolgssystem ein. Das zweite Level hat einen ähnli-
chen Aufbau wie Level 1. Zusätzlich gibt es in diesem Level Plattformen, die
sich bei Kontakt mit dem Spieler zufällig nach unten bewegen. Im Minispiel
be ndet sich der Charakter auf einer Plattform, welche sich nach oben und
unten steuern lässt. Aus unterschiedlichen Spawnpunkten erscheinen Gegner,
die auf den Charakter zusteuern. Ziel ist es hier, so viele Gegner wie möglich
zu besiegen.
3.2 Erfolge
Im ersten Level gibt es mehrere Erfolge, die der Spieler durch bestimmte
Aktionen freischalten kann. Zum einen gibt es ein Menü, in dem man die
einzelnen Erfolge einsehen kann. Zum anderen wird ein freigeschalteter Erfolg
im Spiel kurz eingeblendet. Als Nächstes folgt eine Übersicht der Erfolge in
Abbildung 8.
11Abbildung 8: Übersicht der im Spiel enthaltenen Erfolge mit ihren Bedingungen
und Punkten
3.3 Story
Das Jump'n'Run Spiel trägt den Namen Age of Tunes und man spielt den
bartlosen Barden Bardur.
In der fantastischen Welt Harmonica wurde Bardur als erster und einziger
Sohn, ohne eine prächtige Gesichtsbehaarung, in seine Familie geboren. Er
litt sehr darunter und wurde von den meisten Verwandten belächelt und
verspottet. Es zeigte sich jedoch schnell, dass Bardur über eine einzigartige
Gabe verfügte. Er konnte mit seiner Musik Magie wirken. Nicht nur die
Magie, mit der man Herzen erwärmt. Nein! Richtige Magie.
Als Bardur gerade der Jugend entwachsen war, kam es zu einem schreck-
lichen Unglück auf Harmonica. Eine unbekannte Macht belegte die magischen
Geschöpfe, die auf Harmonica lebten, mit dem Fluch der Boshaftigkeit. Die
vorher so liebevollen Lebewesen waren plötzlich aggressiv und grien die
Bewohner an.
Dies war der Zeitpunkt, an dem Bardur beschloss, seine Gabe dafür einzuset-
zen, die magischen Geschöpfe vom Fluch der Boshaftigkeit zu befreien und
wieder Frieden über Harmonica zu bringen.
4 Implementierung
In diesem Kapitel wird beschrieben, wie das Spiel realisiert wurde.
4.1 Aufbau des Spiels
Startet man das Spiel, önet sich als erstes das Hauptmenü. Über dieses
kann man das Spiel entweder direkt beginnend mit Level 1 starten oder man
önet das Menü für die Levelauswahl, um ein bestimmtes Level direkt zu
laden. Das Spiel lässt sich auch über das Hauptmenü beenden. Schlieÿt man
ein Level ab, wird das nächste Level gestartet. Schat man es nicht, das
Level zu beenden, wird man zu einem GameOver -Bildschirm weitergeleitet,
über den man zurück ins Hauptmenü gelangt. Jedes Level verfügt über ein
12Pausenmenü, wodurch man das Level wieder fortsetzen oder zurück zum
Hauptmenü gelangen kann. Im ersten Level gibt es ein zusätzliches Menü,
in welchem man die Erfolge, die in diesem Level erlangt werden können,
einsehen kann. Veranschaulicht ist der Aufbau in Abbildung 9.
Abbildung 9: Übersicht über den Aufbau des Spiels
4.2 Leveldesign
Für die Gestaltung der Level wurde auf das Asset 2D Handcrafted Art zu-
rückgegrien. Dieses enthält eine Auswahl an unterschiedlichen Sprites (siehe
Abbildung 10), die dazu verwendet werden, Hintergründe und Plattformen
zu gestalten. Je nach Gröÿe der Plattform wird eine unterschiedliche Anzahl
an Sprites verwendet, um diese zu gestalten. Um Plattformen erneut ver-
wenden zu können und einfacher die Gestaltung zu bearbeiten, werden diese
in unterschiedlichen Varianten als Prefabs gespeichert.
Abbildung 10: Übersicht über die Sprites
134.3 Charakterdesign
In diesem Abschnitt wird die Entwicklung des Spielcharakters vorgestellt.
4.3.1 Erstellung und Kon guration des Charakters
Der Spielcharakter (siehe Abbildung 11) wurde in dem Zeichenprogramm
Krita digital gezeichnet. Aufgeteilt ist die Figur in unterschiedlichen Ebe-
nen: Kopf, linker und rechter Arm, Körper sowie linkes und rechtes Bein.
Exportiert werden die Ebenen über Krita, um die einzelnen Teile in Unity
weiterzuverarbeiten. Die einzelnen Teile werden Unity in den zuvor erstellten
Charakterordner hinzugefügt.
Abbildung 11: Darstellung des Spielcharakters
Der erste Schritt ist das Generieren vonSprite Meshes aus den benötig-
ten Texturen mit Hilfe von Anima 2D. Daraufhin erstellt man ein leeres
GameObject, fügt diesem die Sprite Meshes hinzu und baut den Charakter
innerhalb der Szene wieder zusammen.
14Nun müssen die Sprite Meshes noch angepasst werden, wozu der Sprite Edi-
tor Anima 2D bietet eine sehr gute Approximation an den
verwendet wird.
Kanten der Textur an, um eine bessere Geometrie der Sprite Meshes zu erhal-
ten. An den Partien des Sprite Meshes werden weitere Vertices hinzugefügt,
um eine bessere Verformung bei der Charakterbewegung zu gewährleisten
(siehe dazu Abbildung 12 und 13). Zum Schluss werden die Änderungen
bestätigt, damit die neue Geometrie von Unity übernommen wird.
Abbildung 12: Vor der Bearbeitung durch den Sprite Mesh Editor
Abbildung 13: Nach der Bearbeitung durch den Sprite Mesh Editor
Anima 2D stellt dem Unity Editor neue Komponenten zur Verfügung, dazu
zählt die SpriteMeshInstance. In dieser werden die Knochen eingefügt, die
zum jeweiligen Sprite Mesh gehören. Auch kann man hier den Sprite Meshes
ihre Layeranordnung zuweisen.
Der nächste Schritt ist das Erstellen einer Bone Hierarchy, welches die
Bone2D Objekte beinhaltet. Ein Bone2D ist ein Objekt, welches eine va-
15riable Länge hat und mit einem weiteren Bone2D Objekt verknüpft werden
kann. Die erstellte Hierarchie ist in Abbildung 14 zu nden.
Abbildung 14: Übersicht über die verwendete Bone Hierarchy
Ist dieBone Hierarchy fertiggestellt (siehe Abbildung 15), müssen die von
den Sprite Meshes benötigten Knochen per drag-and-drop der Knochenliste
im SpriteMeshEditor hinzugefügt werden.
Abbildung 15: Spielcharakter mit Skelett
Önet man nun den Sprite Editor, erscheinen auch hier die zugewiesenen
Knochen. Um die Knochen mit der Textur zu verbinden, muss man den
Bind Button aktivieren und zum Schluss wieder die Änderungen mit Apply
bestätigen, siehe Abbildung 16. Das Setup ist beendet.
16Abbildung 16: Darstellung eines mit der Textur verbundenen Skelettparts
Um Knochen so anzupassen, dass sie sich natürlich bewegen, werden In-
verse Kinematics (IKs ) verwendet. Für Arme und Beine werden IK Limbs
verwendet. IK Limbs benötigen eine Verkettung von zwei Knochen.
Abbildung 17: Darstellung der IK Limb Komponente
Ist alles erstellt, bringt man den Spielcharakter in die gewollte Pose und spei-
chert diese über den PoseManager ab. Gespeicherte Posen können hierüber
auch erneut geladen werden.
Abbildung 18: Darstellung der Pose Manager Komponente
4.3.2 Animation des Charakters
Für die Erstellung der Animation wird das Animationsfenster in Unity be-
nötigt. Als erstes erstellt man im Animationsfenster einen neuen Clip und
weist diesem einen Namen zu. Mit der Erstellung der Animation beginnt man
nach dem Betätigen des Aufnahmeknopfs (Roter Punkt). Dann kann man
17die IKs, bzw. die Knochen Frame-per-Frame bewegen. Hilfreich ist dabei
die Nutzung des Onion Skin, welches die Darstellung des vorherigen (grün)
5
und folgendem Frame (rot) darstellt (siehe Abbildung 11 ). Dadurch erhält
man einen besseren Überblick über die Animation und kann leichter Anpas-
sungen vornehmen. Zum Schluss wird die Animation über den Befehl Bake
Animations gesichert.
Abbildung 19: Darstellung des Onion Skin
Auf diese Weise sind für den Spielcharakter eine Idle, Run, Jump und Attack
Animation entstanden.
4.3.3 Nutzung der Animationen im Spiel
Um die Animationen im Spiel verwenden zu können, müssen diese im Ani-
mator kon guriert und über ein Skript aufgerufen werden.
Abbildung 20: Darstellung der StateMachine im Animator Fenster
Jede Animation wird durch einen State dargestellt und durch Transitions
mit einem weiteren State verbunden (siehe Abbildung 20). In den Tran-
sitions be nden sich die Bedingungen, welche erfüllt werden müssen, um eine
5
Bildquelle: https://www.moddb.com/news/unity-to-incorporate-2d-animation-
software-anima2d-for-free (aufgerufen am 24.10.2019)
18Animation ausführen zu können. Bedingungen werden über unterschiedliche
Parameter de niert. Dies sind beispielsweise Trigger oder Boolean (Wahr-
heitswerte). Welcher Parameter zum Einsatz kommt, ist abhängig zu der
jeweiligen Funktion der Animation. Sowohl die Jump als auch die Attack
Animation verwendet einen Trigger als Parameter, welcher über das Player-
Controll -Skript aufgerufen wird. Das bedeutet, sobald eine bestimmte Taste
gedrückt wird, startet die jeweilige Animation. Der Angri des Charakters
besteht daraus, dass dieser durch das Spielen seiner Laute erst zu einem be-
stimmten Zeitpunkt eine Note erzeugt. Um dies zu ermöglichen, wird in der
Animation ein Event an einem ausgewähltem Frame hinzugefügt. Der Na-
me des Events muss identisch mit der im PlayerControll -Skript be ndlichen
ShootNow Methode sein, welche für das Erzeugen der Noten verantwortlich
ist (siehe Abbildung 21). Ein weiteres Event wird für den Klang, welcher
durch das Spielen der Laute erzeugt werden soll, benötigt. Hierbei wird die
im PlayerControll -Skript be ndliche playLaute Methode verwendet, die auf
die AudioSource -Komponente zugreift (siehe Abbildung 21).
Abbildung 21: Erstellte Events innerhalb der Animation
Für die Idle und Run Animation wird ein State Motion verwendet, wel-
cher einen BlendTree enthält (siehe Abbildung 22). Für die Entscheidung,
welche der beiden Animationen genutzt wird, kommt eine Speed Variable
zum Einsatz. Das bedeutet, sobald sich der Charakter bewegt, also eine Ge-
schwindigkeit durch die Steuerung des Charakters erzeugt wird, startet die
Run Animation.
19Abbildung 22: Darstellung des BlendTree für Idle und Run Animation
4.4 Gegnerdesign
Die Elementargeister sind in Inkscape mit Hilfe von Bezier Splines gezeich-
net worden. Anders als beim Charakter wurden diese nicht mit Anima 2D
animiert, sondern über zwei unterschiedlich gezeichnete Texturen. Durch Ink-
scape lieÿen sich die Geometrien bei den Gegnern verschieben, um eine zweite
Textur zu erhalten (siehe Abbildung 23).
Abbildung 23: Darstellung des ersten und zweiten Frames der Elementargeis-
ter (Oben sind die ver uchten Elementargeister, in der Mitte die
Feuer- und unten die Wasserelementargeister)
Die fertigen Zeichnungen werden dem Ordner Enemies hinzugefügt und wie
zuvor bei dem Charakter wird ein leeres GameObject erstellt. Die beiden Tex-
turen werden selektiert und gleichzeitig in die Szene geschoben. Unity schlägt
20daraufhin die Erstellung einer Animation vor, welche nur noch benannt wer-
den muss. Da es sich bei den Gegner um einen nicht-spielbaren-Charakter
handelt, wird für diesen ein Skript benötigt, damit dieser sich im Spiel be-
wegt. Dabei gibt es im Spiel zwei verschiedene Richtungen, in denen sich der
Gegner bewegen kann. Einmal entlang der x-Achse und einmal entlang der
y-Achse.
1 endPos . x = endPos . x + Mathf . PingPong ( Time . time * EnemySpeed ,
length ) - arealCal ;
2
3 endPos . y = endPos . y + Mathf . PingPong ( Time . time * EnemySpeed ,
length ) - arealCal ;
Code 1: Auszug aus dem Enemy-Skript
Mit Hilfe der Mathf.PingPong Methode, patrouilliert der Gegner in einem
Bereich von null und dem Wert length. Durch die zusätzliche Variable areal-
Cal, wird der Bereich verschoben und be ndet sich, wenn beispielsweise
length einen Werte von vier und arealCal den Wert zwei hätte, zwischen
minus zwei und zwei. Dies erleichtert es bei Plattformen den Bewegungs-
raum der Gegner über den Inspector festzulegen, nachdem man diese mittig
platziert hat. Da die Gegner so keine Gefahr für den Spieler darstellen wür-
den, wird auch hier eine Methode benötigt.
Hierzu bietet sich die Nutzung der von Unity bereitgestellten
OnCollissonEnter2D -Methode im PlayerControll -Skript und die Verwen-
dung von Tags für die GameObjects an. Den Gegnern wird der Tag Enemy
zugewiesen und sobald der Spieler ein GameObject mit diesem Tag berührt,
wird die RespawnPlayer -Methode für den Spielcharakter aufgerufen. Diese
überprüft, ob der Spieler über genug Leben verfügt, um zu entscheiden, ob
der Spieler einen erneuten Versuch hat oder in die GameOver -Szene wei-
tergeleitet wird. Auÿerdem wird geprüft, ob der Spieler einen Checkpoint
passiert hat, um diesen bei noch vorhandenem Leben entweder beim Level-
start oder Checkpoint zu positionieren. Jetzt ist der Gegner in der Lage, den
Spieler zu töten, sodass nur noch eine Methode fehlt, um den Gegner elimi-
nieren zu können. Bisher kann der Spieler nur Noten erzeugen, welche keinen
Schaden verursachen. Hierzu benötigt der Gegner, ebenso wie der Spieler ei-
ne Lebensanzeige. Nach Fallen der Lebensanzeige auf null wird die Methode
EnemyDeath aufgerufen. Diese beinhaltet die folgenden Codezeilen.
1 Instantiate ( deathEffect , transform . position , Quaternion .
identity ) ;
2 Destroy ( gameObject ) ;
Code 2: Auszug aus dem Enemy-Skript
Mit der Instantiate Methode wird ein Klon eines ausgewählten GameOb-
jects generiert. Der Variable deathEect wird in Abhängigkeit zu dem Level
21entweder das Feuer- oder Wasserelementar- Prefab zugewiesen. Die Position
wird von dem vorher existierenden Gegner übernommen. Durch
Quaternion.identity wird garantiert, dass das GameObject die Standardaus-
richtung der Achsen beibehält. Die durch den Sieg über den Gegner enstande-
nen Elementargeister können dem Spieler nun keinen Schaden mehr zufügen.
Weiterhin unterscheiden sie sich auch in der Bewegung zu den Gegnern. Sie
patrouillieren nicht geradlinig hin und her, sondern erhalten zusätzlich eine
Sinusfunktion, um die Elementargeister freundlicher und vergnügter darstel-
len zu können.
1 transform . position = endPos + transform . up * Mathf . Sin ( Time .
time * frequency ) * magnitude ;
Code 3: Auszug aus dem moveElementary-Skript
4.5 Weitere GameObjects
In diesem Abschnitt werden weitere in Krita gezeichnete GameObjects vor-
gestellt (siehe Abbildung 24). Zum einen sind dies die Runensteine, die vom
Spieler eingesammelt werden können. Auf dem Stein be ndet sich die Rune
FEHU, die für Besitz steht [5]. Dann der Herzstein, der dieselbe Steintex-
tur wie der Runenstein besitzt und sich nur durch die rote Herzkontur von
diesem unterscheidet. Der Herzstein wird für die Lebensanzeige des Spielers
verwendet. Als nächstes der Checkpoint, der über die Inschrift INGUZ ver-
fügt, welche für einen Neubeginn steht [5]. Als letztes GameObject die Note,
welches die Darstellung des Geschosses im Spiel repräsentiert.
Abbildung 24: Auf der linken Seite be nden sich oben der Runenstein, darunter
der Herzstein, in der Mitte die Darstellung der Note und rechts
der Checkpoint.
224.6 Erstellung von Benutzerober ächen
In diesem Abschnitt erläutere ich, wie die einzelnen Benutzerober ächen
realisiert wurden.
4.6.1 Haupt- und Pausenmenü
Für das Hauptmenü (siehe Abbildung 25) wurde eine eigene Szene erstellt.
Für den Menühintergrund werden unterschiedliche Sprites aus dem 2D Hand-
crafted Art Asset angeordnet. Für die eigentliche Benutzerober äche erstellt
man zunächst ein Canvas. In diesem wird über Unity ein Panel hinzuge-
fügt und dessen Darstellung durch weitere Unity Komponenten optimiert.
Der nächste Schritt ist das Hinzufügen der Buttons. Damit die Buttons ei-
ne Funktion haben, wird ein eigenes Skript benötigt, welches die jeweiligen
Methoden enthält, um durch das Menü zu navigieren. Das Skript muss zum
Schluss dem Canvas als Komponente hinzugefügt werden, um die Methoden
dem jeweiligen Button zuweisen zu können.
Das Pausenmenü (siehe Abbildung 25) be ndet sich innerhalb eines Levels.
Önet man dieses, wird durch die de nierte Taste Esc nicht nur das Menü
aufgerufen, sondern auch das Level pausiert. Setzt man das Level wieder
fort, läuft die Zeit normal weiter.
Abbildung 25: Links die Darstellung des Hauptmenüs, rechts die des Pausen-
menüs
4.6.2 Zählanzeigen
Um eine Übersicht der gesammelten Gegenstände, besiegten Gegner, Lebens-
anzeige, Zeitangabe und einen Highscore zu erhalten, benötigt man wieder
ein Canvas. Damit die Übersicht für den Spieler angenehmer gestaltet ist,
wird innerhalb des Canvas zu den meisten Textanzeigen ein dazugehöriges
Bild hinzugefügt (siehe Abbildung 26). Um die Werte in dem Canvas zu
ändern, benötigt man Skripte, die den Text manipulieren. Über das
CollectRunes -Skript wird nach jeder eingesammelten Rune ein Counter er-
höht und dessen Wert dem Text zugewiesen. Dasselbe Verfahren wird bei
den Gegnern angewendet. Der Highscore erhält den Wert in Level 1 und 2
23von den gesammelten Runen, wohingegen im Minispiel die Anzahl der be-
siegten Gegner aufgelistet wird. Beim Highscore wird der höchste erreichte
Wert gespeichert. Deswegen wird nach einem neuen Levelstart ein Vergleich
benötigt, ob dieser aktualisiert werden muss oder nicht. Hierzu greift man auf
die PlayerPrefs zu, in denen der Highscore Wert gespeichert wird, welcher
standardmäÿig null ist. Erhöht wird der Wert durch eine if -Abfrage. Diese
besagt, dass sobald der Counter gröÿer ist als der Wert, der in Highscore
gespeichert ist, der aktuelle Highscore Wert durch den Wert des Counters
ersetzt wird. Andernfalls bleibt dieser unverändert.
Abbildung 26: Darstellung eines Canvas mit Zählanzeigen aus dem zweiten Level
4.6.3 Erfolgssystem
Auch für die Übersicht der Erfolge ist ein eigenes Canvas von Nöten. Dieses
besteht aus einem Hintergrund, einem Bereich, in dem die de nierten Erfolge
gelistet sind, und einem Punktestand. Hinzugefügt und erstellt werden die
Erfolge über ein Skript. Ein Erfolg besteht aus einer Zuweisung zum Mas-
kenbereich, einem Titel, einer Beschreibung, einem Bild mit dazugehörigem
Bildindex, einer Punktzahl und einer vorgegebenen Anzahl auszuführenden
Aktionen, um den Erfolg zu erreichen. Die Informationen werden in einem
Prefab, welches die Darstellung des Erfolges beinhaltet, abgebildet. Hat man
einen Erfolg erreicht, ändert sich der Hintergrund des Erfolges und zusätzlich
erscheint eine Einblendung des Erfolges am unteren Bildschirmrand (siehe
Abbildung 27). Abschlieÿend folgt eine Übersicht der Erfolge mit einer Er-
klärung, wie diese erreicht werden können. Die ersten drei Erfolge haben die
Funktion die Steuerung zu verstehen (siehe Abbildung 27). Werden alle drei
Erfolge erreicht, erhält man einen zusätzlichen Erfolg dafür, dass man die
Steuerung erlernt hat. Die übrigen Erfolge sind an Ereignisse innerhalb des
Spielerlebnisses gebunden. Sobald eine Rune oder ein Gegner zerstört wird,
24steigt der Zähler des dazugehörigen Erfolges an. Zum Erlangen des Erfolges
müssen alle Runen gesammelt, beziehungsweise Gegner besiegt werden.
Abbildung 27: Darstellung des Erfolgssystems in Level 1
4.7 Spielobjekte
In diesem Abschnitt erkläre ich die GameObjects, welche zur Erstellung eines
Levels verwendet wurden.
4.7.1 Spieler
Damit der Spieler mit anderen Objekten interagieren kann, müssen diesem
weitere Komponenten hinzugefügt werden. Dazu gehört ein Boxcollider 2D,
der für Kollisionen mit anderen Objekten genutzt wird. Um festzustellen, ob
sich der Spieler auf dem Boden be ndet, verfügt dieser über ein zusätzliches
GameObject an der Position der Füÿe, welches als Groundcheck verwendet
wird.
4.7.2 Gegner
Die Gegner besitzen einen Boxcollider 2D, welcher als Trigger für die Kolli-
sion mit dem Spielcharakter benötigt wird. Berührt der Spielcharakter den
Gegner, verliert der Spieler ein Leben. Trit der Spieler den Gegner mit
einer Attacke, wird dieser in seine ursprüngliche Elementarerscheinung zu-
rückverwandelt. Die Gegner patrouillieren in ihrer schwarzen Form entweder
von links nach rechts oder von oben nach unten. Dabei wird der Geschwin-
digkeitswert in einem Intervall zwischen fünf und zehn zufällig ermittelt.
Über die boolsche Variablen x-Achse und y-Achse wird im Inspector die
25Bewegungsrichtung festgelegt. Nach der Umwandlung des Gegners in die ur-
sprüngliche Form können diese dem Spieler keinen Schaden mehr zufügen.
Um eine wellenförmige Bewegung zu erzielen, wird eine Sinusfunktion ver-
wendet.
4.7.3 Plattformen
Die festen Plattformen benötigen einen Spriterenderer und einen Boxcollider
2D. Der Boxcollider wird benötigt, damit der Charakter nicht durch die
Plattformen hindurch fällt.
4.7.4 Bewegende Plattformen
Die Plattformen bewegen sich entlang eines de nierten Pfades (siehe Abbil-
dung 28). Dabei kann eine beliebige Anzahl an Pfadknoten genutzt werden.
Es wird aber mindestens ein Start- und Endknoten benötigt. Der erstellte
Pfad wird der dazugehörige Plattform über den Inspector zugewiesen.
Abbildung 28: Darstellung des Pfades (weiÿe Linie) einer Plattform
4.7.5 Fallende Plattformen
Das Fallen der Plattformen wird über ein Tag geregelt. Sobald ein Game-
Object mit dem Player Tag eine Plattform berührt, senkt sich diese ab. Um
es willkürlicher zu gestalten, wird diese Aktion per Zufall mit Hilfe eines
Boolean -Wertes bei jeder Plattform ermittelt. Nach Ablauf einer kurzen Zeit
wird die Plattform wieder zur ursprünglichen Position zurückgesetzt.
4.7.6 Sammelbare Runen
Die Runen im Spiel sind im Level an unterschiedlichen Stellen verteilt. Je-
de Rune verfügt über einen Circle Collider 2D, welcher für eine Kollision
zwischen Spieler und Rune benötigt wird. Zusätzlich verfügen die Runen
über eine Audiokomponente, welche dafür sorgt, das eine Sounddatei nach
Aufsammeln dieser abgespielt wird.
264.7.7 Checkpoints
Um nach einem Tod des Spielcharakters nicht komplett von vorne zu begin-
nen, gibt es im Spiel Checkpoints. Diese ersetzen nach dem Aktivieren die
aktuelle Startposition des Spielers, mit deren Standort.
4.7.8 Hintergrundmusik
Die Menüs und jeweiligen Level beinhalten alle eine eigene Musikquelle. Um
einen Audioclip der Szene hinzuzufügen, wird ein leeres GameObject erstellt
und diesem eine Audiokomponente (siehe Abbildung 29) hinzugefügt. Der
ausgewählte Audioclip wird unter Output hinzugefügt. Durch unterschiedli-
che Regler, wie beispielsweise Lautstärke, kann die Musik der Szene ange-
passt werden. Die Hintergrundmusik für die einzelnen Szenen stammen von
der Internetseite OpenGameArt .
6
Abbildung 29: Darstellung der Audio-Komponente in Unity
4.7.9 Levelende
Das Levelende ist einGameObject, welches aus einem Boxcollider 2D besteht,
der als Trigger de niert wird. Sobald der Spielcharakter den Boxcollider 2D
berührt, wird daraufhin über das nextLevel -Skript die nächste Szene geladen.
6
Musikquellen: https://opengameart.org/content/adventure-begins (abgerufen
am 10.09.2019), https://opengameart.org/content/battle-theme-a (abgerufen am
10.09.2019), https://opengameart.org/content/lost-love (abgerufen am 10.09.2019) und
https://opengameart.org/content/wider-waters (abgerufen am 10.09.2019)
274.7.10 Killbox
Die Killbox ist ebenso wie das Levelende ein GameObject, das aus einem
Boxcollider 2D besteht und als Trigger de niert wird. Wird diese durch den
Spieler berührt, werden in Abhängigkeit zu verschiedenen Faktoren unter-
schiedliche Aktionen ausgeführt. Verfügt der Spieler noch über verfügbare
Leben, wird dieser entweder zum Levelstart oder Checkpoint gebracht. Sind
keine Leben mehr verfügbar, wird man zu der GameOver -Szene weitergelei-
tet.
4.7.11 Spawnpunkte
Spawnpunkte können an unterschiedlichen Stellen im Spiel positioniert wer-
den. In einem festgelegten Intervall von zwei Sekunden werden durch diese
die Gegner im Spiel erzeugt.
4.8 Levelaufbau
In diesem Abschnitt erläutere ich den genauen Aufbau der Level.
4.8.1 Level 1 und 2
Die ersten beiden Level bestehen aus einem Start- und Endpunkt, sowie
Speicherpunkten. Nach Erreichen des Endpunktes wird das nächste Level
gestartet. Der Charakter lässt sich über das PlayerControll-Skript steuern.
Stirbt der Charakter, wird dieser entweder zum Start- oder Speicherpunkt
gebracht. Ist kein Leben mehr vorhanden, wird der GameOver -Bildschirm
geladen. Dies wird über das LevelManager -Skript reguliert. Der Spieler be-
wegt sich über Plattformen, von denen sich manche bewegen können. An
unterschiedlichen Stellen im Spiel be nden sich Runen, welche vom Spieler
eingesammelt werden können. Bezüglich der Gegner ist es die Aufgabe des
Spielers diese umzuwandeln. Den aktuellen Fortschritt sieht man im Zähler-
stand am linken Bildschirmrand. Der Highscore am rechten Bildschirmrand
stellt die am meisten gesammelten Runen in den bisherigen Spieldurchläu-
fen dar. Zusätzlich verfügt das erste Level über eine Erfolgsübersicht, welche
man jederzeit aufrufen kann.
28Abbildung 30: Ausschnitte aus dem ersten Level beim Erreichen eines Erfolges
Abbildung 31: Ausschnitte aus dem ersten Level beim Passieren des Checkpoints
29Abbildung 32: Ausschnitt aus dem zweiten Level
Abbildung 33: Ausschnitt aus dem zweiten Level
4.8.2 Minispiel
Anders als bei den ersten beiden Leveln gibt es hier kein Levelende. Die Geg-
ner werden über drei Spawnpunkte generiert, welche sich am rechten Rand
der Szene be nden. Der Spieler wird über eine Plattform bewegt, welche von
drei Elementargeistern getragen wird. Mit Hilfe der Methode
MoveEnemyToTarget aus dem EnemyMinigame -Skript nden die Gegner
die Position des Spielers und steuern diesen an. Der Spieler muss dabei ver-
suchen, so viele Gegner wie möglich zu besiegen. Die höchste Anzahl von
30besiegten Gegnern wird in einem Highscore gespeichert.
Abbildung 34: Ausschnitt aus dem Minispiel
5 Evaluation
In diesem Kapitel befasse ich mich mit der Studie zu dem Spiel. Hier wird die
Zielsetzung des Spiels erläutert, wie die Studie geplant sowie durchgeführt
wurde und schlieÿt mit einer Auswertung der Testergebnisse ab.
5.1 Zielsetzung der Studie
Das Ziel dieser Studie ist es, einen Eindruck über die Wirkung des Spiels auf
die Probanden zu gewinnen und zu ermitteln, welche Auswirkungen Erfolgs-
systeme auf das Spielverhalten haben.
5.2 Planung und Durchführung
Für die Evaluation wurde ein Fragebogen konzipiert, um unterschiedliche
Aspekte des Spiels bewerten zu können. Der Fragebogen setzt sich aus un-
terschiedlichen Fragetypen zusammen. Es gibt sowohl geschlossene als auch
oene Fragen. Ersteres wurde verwendet, um gezielt Daten für die Hypothe-
sen dieser Arbeit erhalten zu können. Die verwendete Skala bei den geschlos-
senen Fragen ist eine verbalisierte Vierer-Skala von Likert [4]. Bei diesem
Typ wird jeder einzelne Skalenpunkt mit einer verbalen Benennung gekenn-
zeichnet. Dies soll eine Erleichterung für die Probanden sein, damit diese
nicht über die Bedeutung jedes einzelnen Kästchen nachdenken müssen, da
die Zuweisung in der Tabelle enthalten ist. Testpersonen besitzen oft eine
Neigung dazu, eine neutrale Meinung zu vertreten, wenn sie unentschlossen
31sind. Aus diesem Grund wurde das neutrale Element entfernt, um eindeu-
tigere Ergebnisse zu erhalten. Geschlossene Fragen werden nicht in jedem
Block mit einer Skala bewertet. Es gibt auch dichotome Fragen, welche die
Antwortmöglichkeiten Ja und Nein beinhalten. Die oenen Fragen sollen
den Probanden die Möglichkeit geben, Eindrücke über das Spiel festhalten
zu können. Gegliedert ist der Fragebogen in folgende Bereiche: Allgemeine
Fragen, Fragen zu Inhalten des Spiels, Erfolgssystem und Zählanzeigen, und
allgemeine Fragen zum Spiel. Der Fragebogen ist im Anhang dieser Arbeit
zu nden.
An der Nutzungsstudie haben insgesamt 10 Probanden teilgenommen. Die
Altersgrenze lag zwischen 23 und 64 Jahre mit einem durchschnittlichen
Alter von 31,6 Jahren. Zu Beginn des Tests ist jedem Proband ein Informa-
tionsblatt ausgeteilt worden, um garantieren zu können, dass jeder von ihnen
über dieselben Startbedingungen verfügt. Das Informationsblatt enthält die
Geschichte des Spiels und Hinweise zu den einzelnen Level. Nach dem Durch-
lesen des Blatts ist der nächste Schritt das Testen des Spiels. Zum Schluss ist
jedem Proband ein Fragebogen ausgehändigt worden, den er ausfüllen sollte.
Für die Dauer der Tests wurde eine ungefähre Zeit von 30 Minuten ange-
setzt, welche aber für die Probanden nicht bindend gewesen ist. Der längste
Test dauerte ungefähr eine Stunde und zehn Minuten, der kürzeste lag bei
etwa 25 Minuten.
5.3 Auswertung der Testergebnisse
Die vier einzelnen Blöcke werden im Verlauf dieses Abschnittes separat be-
trachtet. Die geschlossenen Fragen werden mit Hilfe eines gestapelten Balken-
diagramms veranschaulicht. Die x-Achse enthält dabei eine Angabe über die
Anzahl der Testpersonen und die y-Achse die zum jeweiligen Block gehören-
den Aussagen. Den in der Skala enthaltenen Auswahlmöglichkeiten wurden
die folgenden Werte zugewiesen. Trit gar nicht zu hatte einen Wert von
minus zwei, Trit nicht zu einen Wert von minus eins, Trit zu einen Wert
von eins und Trit voll zu einen Wert von zwei. Diese Werte wurden mit
der entstandenen Verteilung verrechnet und daraus der Durchschnitt gebil-
det. Dieser dient im Anschluss dem Erhalt einer genauen Tendenz bezüglich
der Aussagen, welche im nächsten Schritt interpretiert wird. Die Auswertung
des Fragebogens ist im Anhang zu nden.
Der erste Block hat als Ziel, allgemeine Informationen über die Probanden zu
sammeln. Hierbei gilt es zu erschlieÿen, welche Erfahrungen die Probanden
zum Zeitpunk des Tests bereits mit Jump'n'Run Spielen haben und welche
Meinung sie im Allgemeinem gegenüber Erfolgssystemen in Spielen besitzen.
In Abbildung 35 sieht man, dass die Häu gkeit des Spielens von Jump'n'Run
Spielen zwischen den Probanden fast ausgewogen verteilt ist. Das lässt ver-
muten, dass auch die Erfahrung dementsprechend zu betrachten ist. Bei dem
Groÿteil der Probanden scheint das Genre Jump'n'Run sehr beliebt zu sein,
32Sie können auch lesen
