Dokumentation.md

@@ -26,14 +26,14 @@ Die Betreuung des Projekts erfolgt über Prof. Walter Kriha. Die Anmeldung und B
 
 ## 4. Projektziel
 
-Das Ziel war es ein Spiel zu programmieren, das einfach zu bedienen war und durch seine comichaften Charakter auch jungen Spielern Freunde macht. Dabei wollten wir sicherstellen, dass das Spiel auch online mit mehreren Spielern spielbar ist, um den Spielspaß zu maximieren. Um den Lernerfolg für alle zu erhöhen, war es uns wichtig alle Designs, Controls und Prototypen selbst zu erstellen, sowie persönlich mit den Probanden der User Tests zu sprechen. Da die meisten Mitglieder des Teams noch wenig Erfahrung mit interdisziplinären Gruppen hatten, sollte dieses Projekt außerdem Erfahrungswerte schaffen, von denen später profitiert werden konnte.    
-Aus Projektmanagement Sicht war es außerdem sehr interessant ein größeres Team zu organisieren, da Tamara bisher nur kleinere Teams betreute. Zudem war dieses Projekt eine gute Möglichkeit die gelernten agilen Methoden anzuwenden und zu schauen, wie sich User Experience Design in ein Game integrieren lässt. 
+Das Ziel war es ein Spiel zu programmieren, das einfach zu bedienen war und durch seine comichaften Charakter auch jungen Spielern Freunde macht. Dabei wollten wir sicherstellen, dass das Spiel auch online mit mehreren Spielern spielbar ist, um den Spielspaß zu maximieren. Um den Lernerfolg für alle zu erhöhen, war es uns wichtig alle Designs, Controls und Prototypen selbst zu erstellen, sowie persönlich mit den Probanden der User Tests zu sprechen. Da die meisten Mitglieder des Teams noch wenig Erfahrung mit interdisziplinären Gruppen oder Game Entwicklung hatten, sollte dieses Projekt außerdem Erfahrungswerte schaffen, von denen später profitiert werden konnte.    
+Aus Projektmanagement Sicht war es außerdem sehr interessant ein größeres Team zu organisieren, da Tamara bisher nur kleinere Teams betreute. Zudem war dieses Projekt eine gute Möglichkeit die gelernten agilen Methoden anzuwenden und zu schauen, wie sich das User Experience Design in ein Game integrieren lässt. 
 
 ## 5. Projektablauf
 Der Projektablauf teilt sich in die Vorarbeit und eigentliche Arbeitsphase auf.
 
 ## 5.1 Vorarbeit
-Bevor sich das Team gebildet hatte haben Alex, Olivia und Niklas bereits ein paar Ideen gesammelt und ein Demo Moodboard erstellt um möglichen weiteren Team Mitgliedern die grundlegende Idee zu vermitteln, dabei wurden auch ein paar Ideen aufgeschrieben welche das Spiel interessant machen sollten. Am Ende wurden jedoch die Meisten davon wieder verworfen.
+Bevor sich das Team gebildet hatte haben Alex, Olivia und Niklas bereits ein paar Ideen gesammelt und ein Demo Moodboard erstellt, um möglichen weiteren Team Mitgliedern die grundlegende Idee zu vermitteln. Dabei wurden auch ein paar Ideen aufgeschrieben, welche das Spiel interessant machen sollten. Am Ende wurden jedoch die Meisten davon wieder verworfen.
 ![unknown](uploads/a450b92f98b11cf15e1ebfb079d28422/unknown.png)
 
 Vor der eigentlichen Arbeitsphase ging es darum ein einheitliches Verständnis von der Spielidee und dem Projektziel zu bekommen. Dazu erstellte Julian anfänglich ein Moodboard und zwei Personas, um unser Vorhaben und Zielgruppe greifbarer zu machen.
@@ -41,8 +41,7 @@ Vor der eigentlichen Arbeitsphase ging es darum ein einheitliches Verständnis v
 Das Moodboard orientierte sich an ähnlichen Spielen und fasst anhand von Screenshots für uns wichtige Elemente wie z.B. die verschiedenen Biome und Figuren zusammen, welche als comichafte Kämpfer zusammen mit Waffen dargestellt sind. Auf Basis dieser Zusammenstellung einigten wir uns auf einen Design Stil, Features und wesentliche Aspekte für die Entwicklung des Spieles. 
 
 Um einen Einblick auf den aktuellen Gamingbereich zu bekommen, legten wir unsere Spielkategorie fest. Anhand dieser Kategorie wurde eine Competitor Analyse durchgeführt. 
-Nach den Auswertungen der Competitor Analyse, hatte wir eine genauere Vorstellung, was unser Spiel beinhalten sollte und was nicht. Ebenso hatten wir nun eine Vorstellung welche Zielgruppe hinter diesen Spielen steht. Auf Basis dieser Erkenntnis, erstellte Julian die Personas. 
-Die beiden Personas [1], repräsentiert Charaktereigenschaften, Ziele und Gewohnheiten unsere Zielgruppe und ermöglichen uns dadurch auf einer einheitlichen Basis arbeiten zu können. Die spezifische Zielgruppe beeinflusst nicht nur Designelemente, sondern auch die Navigationsstruktur und konzeptuelle Aspekte wie z.B. der Schwierigkeitsgrad.
+Nach den Auswertungen der Competitor Analyse, hatte wir eine genauere Vorstellung, was unser Spiel beinhalten sollte und was nicht. Ebenso hatten wir nun eine Vorstellung welche Zielgruppe hinter diesen Spielen steht. Auf Basis dieser Erkenntnis, erstellte Julian die Personas. Die beiden Personas [1], repräsentiert Charaktereigenschaften, Ziele und Gewohnheiten unsere Zielgruppe und ermöglichen uns dadurch auf einer einheitlichen Basis arbeiten zu können. Die spezifische Zielgruppe beeinflusst nicht nur Designelemente, sondern auch die Navigationsstruktur und konzeptuelle Aspekte wie z.B. der Schwierigkeitsgrad.
 Auf Basis dieser Vorarbeiten wurden dann erste Tasks im Git Issue Board (siehe unten) erstellt und der grobe Zeitplan abgestimmt. Tamara gab zudem eine kurze Einführung in die Projektmanagement Tools und der allgemeinen Vorgehensweise. Außerdem wurde darüber geredet welchen Grafikstil wir verwenden wollen und welche Funktionen besonders wichtig oder weniger wichtig waren. Dabei war es sinnvoll Aufgaben, die für das Spiel als verpflichtend markiert wurden, auch mit dem Label "must-have" zu kennzeichnen, um den Überblick zu behalten. Da Alexander und Olivia letztes Semester schon ein Multiplayer Spiel entwickelten, fiel die Eingrenzung der Funktionen, aus Sicht der Entwicklung, dieses Mal viel leichter und wir konnten ohne Probleme starten. Julian und Tamara hatten zuvor noch nie ein Spiel mit solch einem großen UX Anteil entwickelt, warum sie sich anfänglich unsicher waren wie viele Iterationen von User Tests möglich waren.
 
 ## 5.2 Arbeitsphase
@@ -57,7 +56,7 @@ Da die Charaktere komplett frei erfunden sind, mussten zuerst sehr viele Skizzen
 Die Skizzen wurden auf Papier gezeichnet. Dabei wurde schon darauf geachtet, dass das Design so angefertigt wird, dass spätere Animationen leicht zu realisieren sind. Nachdem die Skizzen für die Helden und Monster angefertigt worden waren, wurden dennoch noch kleine Veränderungen nach Absprache mit dem Entwicklungsteam vorgenommen, sodass das finale Aussehen der Charaktere fest stand. In diese Phase floss ein sehr großer Teil der Zeit, da hier deutlich wurde, dass das Anfertigen verschiedener Charaktere, die einem einheitlichen Stil folgen sollten, deutlich schwerer ist, als einen einzelnen Charakter zu erstellen.
 In dieser Phase wurde außerdem das Aussehen der Welt, sowie der Eye Candies festgelegt. Auch diese wurden auf Papier in einem zu den Charakteren passenden Stil skizziert.
 
-Die zweite Phase bei der Entwicklung des Designs war anschließend, die auf Papier skizzierten Dateien zu digitalisieren. Dafür wurden die Skizzen eingescannt und anschließend in Photoshop nachgezeichnet. Das Problem hierbei ist, dass Photoshop Pixelbasiert ist und da die Auflösung, die die Charaktere haben sollten zu diesem Zeitpunkt noch nicht fest stand, war es besser die Grafiken vektorbasiert vorliegen zu haben. Zuerst wurden die Skizzen also durch schwarze Outlines in Photoshop gezeichnet. Anschließend wurden diese Dateien in Adobe Illustrator importiert, wo es eine Funktion gibt, schwarze Outlines in eine Vektorgrafik umzuwandeln.
+Die zweite Phase bei der Entwicklung des Designs war anschließend, die auf Papier skizzierten Dateien zu digitalisieren. Dafür wurden die Skizzen eingescannt und anschließend in Photoshop nachgezeichnet. Das Problem hierbei ist, dass Photoshop pixelbasiert ist und da die Auflösung, die die Charaktere haben sollten zu diesem Zeitpunkt noch nicht fest stand, war es besser die Grafiken vektorbasiert vorliegen zu haben. Zuerst wurden die Skizzen also durch schwarze Outlines in Photoshop gezeichnet. Anschließend wurden diese Dateien in Adobe Illustrator importiert, wo es eine Funktion gibt, schwarze Outlines in eine Vektorgrafik umzuwandeln.
 Da vorher noch nicht wirklich in Adobe Illustrator gearbeitet wurde, war es eine große Aufgabe, sich in das Programm einzuarbeiten. Die Charaktere wurden dabei so gezeichnet, dass die einzelnen, beweglichen Körperteile auf verschiedenen Ebenen liegen, um die spätere Animation zu ermöglichen. 
 In Illustrator wurden anschließend auch die Flächen zwischen den Outlines mit Farben gefüllt. Ein großer Vorteil von Illustrator ist dabei, dass Farbflächen sehr einfach durch andere Farbfläschen ersetzt werden können und das gesamte farbliche Aussehen der Charaktere jederzeit geändert werden konnte.
 Der letzte Schritt bei der Digitalisierung der Eye-Candies und Charaktere war schließlich, dass die Illustrator Dateien wieder in Photoshop Dateien umgewandelt werden mussten, da nur diese in Unity eingebunden werden konnten. 
@@ -67,10 +66,10 @@ Bei der Erstellung der Spielwelt wurde mit Substance Painter und Photoshop gearb
 
 #### Grafiken Menü:
 Zum Design des User Interface wurde überwiegend mit Adobe XD gearbeitet, damit später auch ein High-Fidelity Prototyp entsteht, der für die User Tests verwendet werden kann.
-Die Farben zum Design sind abgeleitet worden von den Farben die für die Charaktere des Spiels verwendet wurden. Hier war es wichtig dem Spieler ein einheitliches Bild auch außerhalb des Spiels durch die Menüführung zu bieten. Genauso wurde versucht das einheitliche Bild in den Icons wieder zu spiegeln, um die Benutzung so einfach wie möglich zu gestalten, damit der Spieler nicht durch viele unterschiedliche Farben vom eigentlichen Spiel abgelenkt wird.
+Die Farben zum Design sind abgeleitet worden von den Farben, die für die Charaktere des Spiels verwendet wurden. Hier war es wichtig dem Spieler ein einheitliches Bild auch außerhalb des Spiels durch die Menüführung zu bieten. Genauso wurde versucht das einheitliche Bild in den Icons wieder zu spiegeln, um die Benutzung so einfach wie möglich zu gestalten, damit der Spieler nicht durch viele unterschiedliche Farben vom eigentlichen Spiel abgelenkt wird.
 
 Bei der Überlegung was alles im User Interface untergebracht werden muss, wurde erstmal nach unterschiedlichen Inspirationen von User Interfaces speziell für Spiele in Google und Pinterest gesucht. Denn es war nicht ganz einfach dieses umzusetzen, da Susanne keine Erfahrungen im Spielebereich hatte und wie das User Interface für Spiele umgesetzt wird. Zusätzlich wurde dann in Absprache mit den anderen Departments festgelegt, was alles in dem Spiel benötigt wird um dem Spieler alles benötigte anzubieten aber nicht zuviel, sodass es unübersichtlich wird. Bei den Icons wurde versucht das Design der Figuren mit den dicken Outlines zu übernehmen, was nicht ganz so einfach umzusetzen war. Es wurde vorallem darauf geachtet dass die Linien der Icons dick sind. Die Icons wurden größtenteils selber erstellt und wenige aus flaticon.com verwendet.
-Bei der Erstellung des Prototypen wurde darauf geachtet, dass es einfach ist die verwendeten Farben in jedem Element zusammen ändern zu können. Dass hat es uns im Nachhinein erleichtert, nochmal kleinere Anpassungen zu machen und somit kurz schauen welche Farben am besten zueinander passen, damit nicht jedes einzelne Element angefasst werden musste. Das selbe Prinzip wurde noch für Komponenten angewendet, wie z.B. den Bereich wie man ins Menü kommt und wie man das Spiel beendet.
+Bei der Erstellung des Prototypen wurde darauf geachtet, dass es einfach ist die verwendeten Farben in jedem Element zusammen ändern zu können. Das hat es uns im Nachhinein erleichtert, nochmal kleinere Anpassungen zu machen und somit kurz schauen welche Farben am besten zueinander passen, damit nicht jedes einzelne Element angefasst werden musste. Das selbe Prinzip wurde noch für Komponenten angewendet, wie z.B. den Bereich wie man ins Menü kommt und wie man das Spiel beendet.
 
 Zum Schluss, als das ganze Design des Prototypen stand, wurden überall noch die ganzen Verlinkungen zwischen den einzelnen Elementen eingefügt. Somit konnte der Prototyp zum Testing verwendet werden und war einfach zum Durchklicken.
 
@@ -79,35 +78,31 @@ Zum Schluss, als das ganze Design des Prototypen stand, wurden überall noch die
 
 ### 5.2.2 Department "Entwicklung"
 
-Um das Entwickeln zu vereinfachen entstanden schon sehr früh 2 Ausgabezeilen, welche hauptsächlich zum Debuggen genutzt wurden. Dabei wurde die Obere für Multiplayerspezifische und die Untere für Clientspezifische Outputs genutzt. Diese Debugzeilen haben dann jedoch auch ins fertige Spiel geschafft und wurden zu Statusleisten umfunktioniert. Das Design blieb jedoch sehr rudimentär und diente am Ende des Projektes vor allem für das Feintuning der Character Werte, welche die Spieler nun sehen können. Es war eigentlich noch geplant diese mit Icons zu ersetzen und eventuell auch gerade zu rücken um es optisch etwas ansprechender zu machen und nicht nur Zweckmäßig zu sein. Uns war es als Entwickler jedoch nicht mehr möglich diese auf zu bereiten und gerade zu rücken, da wir kurz vor der Medianight mehr damit beschäftigt waren Bugs zu suchen, zu finden und zu beseitigen. 
+Um das Entwickeln zu vereinfachen entstanden schon sehr früh zwei Ausgabezeilen, welche hauptsächlich zum Debuggen genutzt wurden. Dabei wurde die Obere für multiplayerspezifische und die Untere für clientspezifische Outputs genutzt. Diese Debugzeilen haben dann jedoch auch ins fertige Spiel geschafft und wurden zu Statusleisten umfunktioniert. Das Design blieb jedoch sehr rudimentär und diente am Ende des Projektes vor allem für das Feintuning der Character Werte, welche die Spieler nun sehen können. Es war eigentlich noch geplant diese mit Icons zu ersetzen und eventuell auch gerade zu rücken um es optisch etwas ansprechender zu machen und nicht nur zweckmäßig zu sein. Uns war es als Entwickler jedoch nicht mehr möglich diese auf zu bereiten und gerade zu rücken, da wir kurz vor der Medianight mehr damit beschäftigt waren Bugs zu suchen, zu finden und zu beseitigen. 
 
 ![3](uploads/975a403ec4aca105a417aac1387a3136/3.png)
-
-
 **Mapgeneration**
 
 Die Umgebung sollte ein wichtiger Bestandteil des Spiels werden. Daher sollte zu Beginn des Spiels eine neue Karte generiert werden, die aus einer neuen Anordnung der vier Biome bestand. Dadurch muss sich der Spieler jedes mal auf die neuen Bedingungen einlassen und kann nicht über die Runden hinweg die Karte auswendig lernen. 
 Alex baute zunächst einen Prototyp für die Mapgeneration. Dieser basierte auf dem Aneinanderlegen von Kacheln die jeweils zu einem Biom gehörten. Die Kacheln werden dabei wie in der späteren Version durch einen Noise erzeugt und in eine normalisierte Höhenkarte umgerechnet (Bsp. alles über Höhe == 0.5 wird zu Sand, alles darunter wird zu Wasser). So war es möglich beliebig viele Biome mit ein zu binden und diese bei Bedarf auch jederzeit zu erweitern.
 Später entwickelte Olivia mit diesem Vorbild einen Shader, welcher einen besseren Übergang zwischen Biomen erlaubte. Grundlage ist eine Noise Textur, welche vorher in C# generiert und an den Shader übergeben wird. Über Grenzwerte wird bestimmt, welches Biom in welchem Bereich angezeigt wird.
 
-Um die Bäume und Tiere zu generieren wird der gleiche Noise Algorithmus genutzt. Hierbei wird jedoch ein anderer Maßstab genommen um eine neue Noise Höhenkarte zu erstellen. Diese wird danach genutzt um zu entscheiden ob etwas generiert wird oder nicht. Außerdem wird sie an der Stelle mit der eigentlichen Karte verglichen um in jedem Biom die Biomspezifischen EyeCandys zu generieren. 
-Damit diese nicht wie in einem Raster angeordnet sind werden sie noch um einen zufälligen Offset in x und y richtung verschoben.
-Um eine Beliebige Anzahl an EyeCandy Objekten zu erhalten, werden diese, wie im Bild gezeigt, an den Grid Manager übergeben und verwaltet um einen guten Überblick zu behalten.
+Um die Bäume und Tiere zu generieren wird der gleiche Noise Algorithmus genutzt. Hierbei wird jedoch ein anderer Maßstab genommen um eine neue Noise Höhenkarte zu erstellen. Diese wird danach genutzt, um zu entscheiden ob etwas generiert wird oder nicht. Außerdem wird sie an der Stelle mit der eigentlichen Karte verglichen um in jedem Biom die biomspezifischen Eye Candies zu generieren. 
+Damit diese nicht wie in einem Raster angeordnet sind werden sie noch um einen zufälligen Offset in x und y Richtung verschoben.
+Um eine beliebige Anzahl an Eye Candy Objekten zu erhalten, werden diese, wie im Bild gezeigt, an den Grid Manager übergeben und verwaltet um einen guten Überblick zu behalten.
 ![1](uploads/4658cdf8a17b2ec47b49a53cd45fa047/1.PNG)
 
-
-
 **Nebel**
 
-Um die Umgebung noch interessanter und wichtiger für das Spielverhalten zu machen, entschieden wir uns die Karte in Nebel zu hüllen. Die Helden können diesen Nebel temporär entfernen indem sie hindurchlaufen oder schießen.
-Hierfür erstellte Olivia einen weiteren Shader. Dafür verwendete sie zwei Gradient Noise Texturen in welche verschieden stark reingezoomt wurde und mit verschieden starker Offset Änderung. So konnte der Effekt von sich bewegendem, wabernden Nebel erzielt werden. Zudem konnte man die Farbe des Nebels mithilfe von zwei Color Werten von Außen beeinflussen.
+Um die Umgebung noch interessanter und wichtiger für das Spielverhalten zu machen, entschieden wir uns die Karte in Nebel zu hüllen. Die Helden können diesen Nebel temporär entfernen, indem sie hindurchlaufen oder schießen.
+Hierfür erstellte Olivia einen weiteren Shader. Dafür verwendete sie zwei Gradient Noise Texturen, in welche verschieden stark reingezoomt wurde und mit verschieden starker Offset Änderung. So konnte der Effekt von sich bewegendem, wabernden Nebel erzielt werden. Zudem konnte man die Farbe des Nebels mithilfe von zwei Color Werten von Außen beeinflussen.
 
 Die Durchlässigkeit des Nebels (oder der Alpha Wert) wird durch verschiedene Bedingungen beeinflusst. Der Nebel soll nicht überall gleich dicht sein, daher ließ Olivia die zwei oben genannten Noise Texturen mit in die Alpha Berechnung einfließen. Das sollte allerdings nur einen leichten Einfluss haben. Die sogenannte LightMap sollte den größten Einfluss haben. Die Lightmap sorgt zum Beispiel dafür, dass dort wo die Helden stehen kein Nebel ist. Für den Shader ist die LightMap nur eine schwarz-weiße Textur, welche vom Alpha-Wert des Nebels abgezogen wird. Das heißt an den Stellen wo die Textur weiß ist, ist der der Nebel nicht sichtbar.
 
 Um die Lightmaptextur zu generieren und an den Shader zu übergeben erstellte Olivia eine CalculateFog Klasse. Hier wurde zu Spielbeginn eine neue schwarze Textur erstellt. Wir entschieden uns für eine geringe Auflösung der Textur. Das sorgte zwar für relativ eckige Übergänge zwischen Nebel und Licht, aber eine höhere Auflösung wäre mit mehr Rechenaufwand verbunden.
 Die Helden senden ihre Position konstant an die Klasse. Dadurch werden die Pixel in der Lightmap im Umfeld der Spieler auf weiß gesetzt. Das selbe passiert bei den Pfeilen des Rangers.
 
-Da der Nebel sich konstant verdichten soll, muss sich die Lightmap wieder verdunkeln. Die Idee war das mit einem Compute Shader zu lösen, welche die Farbe der Pixel um einen bestimmten Wert verdunkeln sollte. Die Aufgabe wäre gut geeignet für die GPU und würde die CPU entlasten. Allerdings gab es einige Schwierigkeiten, weswegen wir die Idee letztendlich verwarfen. Zum einen musste die GPU auf einem anderen Texturformat arbeiten. Die Lightmap konnten wir allerdings nicht komplett auf das Texturformat umstellen. Das Übertragen der Werte von der einen Textur in die andere wäre aber ineffizient. Zudem ist die Kommunikation von CPU und GPU nicht schnell genug dass es sich mit den anderen Einschränkungen gelohnt hätte. 
+Da der Nebel sich konstant verdichten soll, muss sich die Lightmap wieder verdunkeln. Die Idee war dies mit einem Compute Shader zu lösen, welche die Farbe der Pixel um einen bestimmten Wert verdunkeln sollte. Die Aufgabe wäre gut geeignet für die GPU und würde die CPU entlasten. Allerdings gab es einige Schwierigkeiten, weswegen wir die Idee letztendlich verwarfen. Zum einen musste die GPU auf einem anderen Texturformat arbeiten. Die Lightmap konnten wir allerdings nicht komplett auf das Texturformat umstellen. Das Übertragen der Werte von der einen Textur in die andere wäre aber ineffizient. Zudem ist die Kommunikation von CPU und GPU nicht schnell genug, dass es sich mit den anderen Einschränkungen gelohnt hätte. 
 Somit ließen wir das letztendlich doch die CPU lösen.
 
 
@@ -118,7 +113,7 @@ Das neue System trennt die Hardware vom spielspezifischen Code. Das macht den Co
 
 Mit dem neuen Input System werden zum Hardware-Trigger an einer Stelle mit Aktionen gemappt. 
 Hierfür wird eine Action Map verwendet. Hier kann man für Actions wie zum Beispiel "Move Up" eine oder mehrere Inputtrigger festlegen. So haben wir ermöglicht, dass man seinen Character mit WASD oder den Pfeiltasten steuern kann.
-Hier hätten wir nun ohne Probleme den Input verschiedener Devices auf die Aktionen mappen können indem wir mehrere Control Schemes erstellt hätten.
+Hier hätten wir nun ohne Probleme den Input verschiedener Devices auf die Aktionen mappen können, indem wir mehrere Control Schemes erstellt hätten.
 
 ![Unbenanntes_Bild](uploads/1cd3b60efef7be8379202ec542b83292/Unbenanntes_Bild.png)
 
@@ -129,12 +124,11 @@ In unserem Code musste dann nur noch festgelegt werden, woraus diese Aktionen be
 
 **Character Movement**
 
-Wir haben gelernt, dass es nicht immer gut ist die Daten vom Human Interface Device unverändert im Spiel zu verwenden. Für ein angenehmeres Spielgefühl wollten wir, dass die Helden einen Moment brauchen um auf die maximale Geschwindigkeit oder in den Stillstand zu kommen. Daher implementierte Olivia ein paar Berechnungen, welche Beschleunigung und Entschleunigung mit in die Bewegung einbezogen. Zudem kümmerte sie sich darum, dass die verschiedenen Bewegungswerte wie Beschleunigung, Entschleunigung und maximale Geschwindigkeit davon abhingen in welchem Biom sich der Held befindet.
+Wir haben gelernt, dass es nicht immer gut ist die Daten vom Human Interface Device unverändert im Spiel zu verwenden. Für ein angenehmeres Spielgefühl wollten wir, dass die Helden einen Moment brauchen, um auf die maximale Geschwindigkeit oder in den Stillstand zu kommen. Daher implementierte Olivia ein paar Berechnungen, welche Beschleunigung und Entschleunigung mit in die Bewegung einbezogen. Zudem kümmerte sie sich darum, dass die verschiedenen Bewegungswerte wie Beschleunigung, Entschleunigung und maximale Geschwindigkeit davon abhingen in welchem Biom sich der Held befindet.
 
-I7
-**Camera**
+** I7 Camera**
 
-Die Kamera sollte sich erst mit dem Spieler mit bewegen, wenn dieser einen bestimmten Bereich verlassen hat.  Olivia setzte das um indem sie ein GameObjekt erstellte, welches den Bereich abdeckte in welchem der Spieler sich bewegen konnte, ohne, dass sich die Kamera bewegte. Das Skript auf der Kamera musst nur prüfen, ob der Spieler außerhalb des Bereichs sind und sich nur dann mit bewegen.
+Die Kamera sollte sich erst mit dem Spieler mit bewegen, wenn dieser einen bestimmten Bereich verlassen hat.  Olivia setzte das um, indem sie ein GameObjekt erstellte, welches den Bereich abdeckte in welchem der Spieler sich bewegen konnte, ohne, dass sich die Kamera bewegte. Das Skript auf der Kamera musst nur prüfen, ob der Spieler außerhalb des Bereichs sind und sich nur dann mit bewegen.
 Bei der Medianight haben einige geäußert, dass sich die Kamera erst zu spät bewegt. Das könnte einfach angepasst werden indem man das GameObjekt kleiner macht.