@@ -45,7 +45,7 @@ Nach den Auswertungen der Competitor Analyse, hatte wir eine genauere Vorstellun
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
Die Arbeitsphase erfolgte in Iterationen mit regelmäßigen Austausch und Synchronisation zwischen den Departments. Näheres zu der verwendeten Projektmanagement Methode ist unter Punkt 5.3.4 zu lesen. Im Folgenden wird die Arbeit und Erkenntnisse der einzelnen Departments vorgestellt. Dabei wird auch auf aufgetretene Problematiken, sowie die Lösung deren eingegangen. Alle erstellten Dateien, mit direkten Bezug auf die Erläuterung in der vorliegenden Dokumentation, wurden eingefügt. Größere Dokumente, Bilder oder zusätzliches Material ist im Ordner "Anhang" zu finden, indexiert über eckige Klammern.
Die Arbeitsphase erfolgte in Iterationen mit regelmäßigen Austausch und Synchronisation zwischen den Departments. Näheres zu der verwendeten Projektmanagement Methode ist unter Punkt 5.3.4 zu lesen. Im Folgenden wird die Arbeit und Erkenntnisse der einzelnen Departments vorgestellt. Dabei wird auch auf aufgetretene Problematiken, sowie die Lösung deren eingegangen. Alle erstellten Dateien, mit direkten Bezug auf die Erläuterung in der vorliegenden Dokumentation, wurden eingefügt. Größere Dokumente, Bilder oder zusätzliches Material ist im Ordner "Anhang" auf der MI Cloud zu finden, hier indexiert über eckige Klammern.
### 5.2.1 Department "Design"
...
...
@@ -134,12 +134,12 @@ Bei der Medianight haben einige geäußert, dass sich die Kamera erst zu spät b
**Waves**
Das Ziel war, dass Gegner immer in Wellen spwanen. Solange eine Wave noch nicht eliminiert ist, soll keine weitere spawnen. Wenn alle Gegner getötet wurden bleibt noch ein wenig Zeit in welcher man auswählen kann inwiefern sich der eigene Held verbessern soll. Dann kommt die nächste größere, stärkere Wave.
Das Ziel war, dass Gegner immer in Wellen spwanen. Solange eine Wave noch nicht eliminiert ist, soll keine Weitere spawnen. Wenn alle Gegner getötet wurden bleibt noch ein wenig Zeit, in welcher man auswählen kann inwiefern sich der eigene Held verbessern soll. Dann kommt die nächste größere, stärkere Wave.
Olivia kümmerte sich darum, dass die Waves zur richtigen Zeit und nur am Rand der Map gespawnt wurden. Alexander sorgte noch dafür, dass mit jeder Wave mehr Gegner gespawnt wurden und deren Stats besser waren.
**Animations**
Olivia beschäftigte sich auch damit wie man in Unity animieren kann. Hierfür nahm sie Niklas' Zeichnungen von Helden und Gegnern als Basis. Für jeden musste ein eigenes Skelett erstellt werden. Mit den einzelnen Knochen konnte nachher die Animation leichter gesteuert werden. Dann mussten die Regionen der Zeichnungen auf die Knochen gemappt werden. Das heißt, man musste entscheiden wie viel ein Bildpunkt von jedem einzelnen Knochen beeinflusst wird. Um die Animationen noch einfacher zu machen, erstellte Olivia für die Extremitäten jeweils einen Inverse Kinematic Control. Damit konnte man zum Beispiel einen Arm ausrichten indem man angibt wo er hinzeigt.
Olivia beschäftigte sich auch damit wie man in Unity animieren kann. Hierfür nahm sie Niklas' Zeichnungen von Helden und Gegnern als Basis. Für jeden musste ein eigenes Skelett erstellt werden. Mit den einzelnen Knochen konnte nachher die Animation leichter gesteuert werden. Dann mussten die Regionen der Zeichnungen auf die Knochen gemappt werden. Das heißt, man musste entscheiden wie viel ein Bildpunkt von jedem einzelnen Knochen beeinflusst wird. Um die Animationen noch einfacher zu machen, erstellte Olivia für die Extremitäten jeweils einen Inverse Kinematic Control. Damit konnte man zum Beispiel einen Arm ausrichten, indem man angibt wo er hinzeigt.
Dann ging es an die Animationen. Für jeden Held und Gegner erstelle Olivia eine eigene Lauf-Animation. Das geschah indem sie angab welcher Knochen zu welchem Zeitpunkt wie ausgerichtet sein sollte. Dafür definierte sie einige Keyframes in welchen sie die Position und Rotation der Knochen speicherte. Für die Frames dazwischen wird die Position berechnet.
Da Animation sehr aufwendig ist, blieb leider keine Zeit für Angriffsanimationen oder ähnliches.
...
...
@@ -163,61 +163,61 @@ Aus jedem State kann man auch in den "Dash" State wechseln in welchem die Lauf A
Die fähigkeiten der Helden wurden so gewählt das sie zum Spielstyl der Figuren passen. Dabei kann der Nahkampf Held Blitze aus dem Himmel beschwören, welche gegner immer direkt Treffen und den Nebel in der Umgebung lichten. Diese verbessert sich durch erhöhten Schaden und mehr gleichzeit erschaffener Blitze. Leider gibt es hierfür auch nur eine Platzhaltergrafik, welche einfach ein helles Oval ist.
Alex hat an vielen Stellen im Code Leistungsoptimierungen vorgenommen. So auch bei dieser Fähigkeit. Damit nicht jedes mal alle Gegnerobjekte gesucht und durchlaufen werden müssen Tragen sich alle Gegner, welche ihn als nächsten Gegner besitzen in eine Sortierte Liste ein und sollten sie Sterben tragen sie sich selbst wieder aus. Dadurch hat der Character immer eine valide Liste, in welcher er nur die ersten x Objekte angreifen muss.
Die Fähigkeiten der Helden wurden so gewählt, dass sie zum Spielstil der Figuren passen. Dabei kann der Nahkampf Held Blitze aus dem Himmel beschwören, welche Gegner immer direkt treffen und den Nebel in der Umgebung lichten. Diese verbessert sich durch erhöhten Schaden und mehr gleichzeit erschaffener Blitze. Leider gibt es hierfür auch nur eine Platzhaltergrafik, welche einfach ein helles Oval ist.
Alex hat an vielen Stellen im Code Leistungsoptimierungen vorgenommen. So auch bei dieser Fähigkeit. Damit nicht jedes mal alle Gegnerobjekte gesucht und durchlaufen werden müssen Tragen sich alle Gegner, welche ihn als nächsten Gegner besitzen in eine sortierte Liste ein und sollten sie Sterben tragen sie sich selbst wieder aus. Dadurch hat der Character immer eine valide Liste, in welcher er nur die ersten x Objekte angreifen muss.
Die Bogenschützin besitzt die Fähigkeit mehrere Pfeile gleichzeitig zu verschießen, diese werden in einem Winkel von z.B. 15° zum nächsten Pfeil abgefeuert, wodurch ein Fächer ensteht. Die Winkel werden Dabei in einer Liste gespeichert. Wenn ein neuer Wert dazu kommt (die Fähigkeit verbessert wird), erden alle werte in der Liste -7.5° gerechnet und ein neuer Pfeil eingefügt, wobei er das letzte Element der Liste +15° als Wert hat. Dadurch fächern sich die Pfeile gleichmäßig auf und können ohne viel aufwand erweiter werden.
Die Bogenschützin besitzt die Fähigkeit mehrere Pfeile gleichzeitig zu verschießen, diese werden in einem Winkel von z.B. 15° zum nächsten Pfeil abgefeuert, wodurch ein Fächer entsteht. Die Winkel werden dabei in einer Liste gespeichert. Wenn ein neuer Wert dazu kommt (die Fähigkeit verbessert wird), erden alle Werte in der Liste -7.5° gerechnet und ein neuer Pfeil eingefügt, wobei er das letzte Element der Liste +15° als Wert hat. Dadurch fächern sich die Pfeile gleichmäßig auf und können ohne viel Aufwand erweitert werden.
Alle weiteren Werte der Character werden am Ende jeder Welle verbessert. Hierfür werden 3 zufällige Runentafeln generiert. Diese bestehen aus einem oberen und einem unteren teil. Dabei stehen oben verbesserungen zu Grundlegendern Werten wie Angriffsschaden, Leben, Rüstung und Geschwindigkeiten. Im untern Teil stehen Fähigkeitsverbesserungen, welche die Anzahl der Fähigkeiten die gleichzeitig gewirkt werden, der Schaden der fähigkeit und der Abklingzeit. Diese können beliebig gemischt sein und jeder Spieler kann sich so für einen Spielstyl entscheiden und demnach seine Runen wählen. Damit das gezielte verbessern eines Spielstyls gefördert wird haben wir uns entschieden einen Grundlegenden Wert, sowie einen Prozentualen wert auf zu rechnen. So überwiegt zunächst der Grundlegende Wert beim Bonus und später der Prozentuale Wert (Beispiel +5 Schaden und +5% Schaden).
Leider sind auch hier die Runentafeln nur Platzhalter welche in einem unschönen Gelb mit standard Buttons hinterlegt wurden.
Alle weiteren Werte der Character werden am Ende jeder Welle verbessert. Hierfür werden drei zufällige Runentafeln generiert. Diese bestehen aus einem oberen und einem unteren Teil. Dabei stehen oben Verbesserungen zu grundlegendern Werten wie Angriffsschaden, Leben, Rüstung und Geschwindigkeiten. Im untern Teil stehen Fähigkeitsverbesserungen, welche die Anzahl der Fähigkeiten die gleichzeitig gewirkt werden, der Schaden der Fähigkeit und der Abklingzeit. Diese können beliebig gemischt sein und jeder Spieler kann sich so für einen Spielstil entscheiden und demnach seine Runen wählen. Damit das gezielte verbessern eines Spielstils gefördert wird, haben wir uns entschieden einen grundlegenden Wert, sowie einen prozentualen wert auf zu rechnen. So überwiegt zunächst der grundlegende Wert beim Bonus und später der prozentuale Wert (Beispiel +5 Schaden und +5% Schaden).
Leider sind auch hier die Runentafeln nur Platzhalter, welche in einem unschönen Gelb mit Standard Buttons hinterlegt wurden.
Um das Spiel spannend zu gestalten investierte Alex viel Zeit in das entwickeln der Gegner Ai gesteckt. Hierfür wurde ein Enemy script erstellt, welches das gesamte Gegnerverhalten steuert. Alle Einheitentypen werden hierfür von einem Script gesteuert, welches entscheidet ab welcher Reichweite beispielsweise ein Gegner angreifen darf oder auch wann er ausweichen sollte. Um dies zu gewährleisten wurde eine Statemachine entworfen welche die verschiedenen Zustände und verhaltensweisen beinhaltet.
Um das Spiel spannend zu gestalten investierte Alex viel Zeit in das Entwickeln der Gegner Ai gesteckt. Hierfür wurde ein Enemy Script erstellt, welches das gesamte Gegnerverhalten steuert. Alle Einheitentypen werden hierfür von einem Script gesteuert, welches entscheidet ab welcher Reichweite beispielsweise ein Gegner angreifen darf oder auch wann er ausweichen sollte. Um dies zu gewährleisten wurde eine Statemachine entworfen, welche die verschiedenen Zustände und Verhaltensweisen beinhaltet.
Diese beinhalten die Zustände:
Follow: Sucht den gegner und äuft auf ihn zu.
Follow: Sucht den gegner und läuft auf ihn zu.
Attack: greife den nächsten Spieler an.
Flee: läuft von Spielern weg und schafft so mehr abstand zwischen ihnen.
Dodge: Weiche dem nächsten Spieler Projektiel aus indem er im 90° Winkel dazu davon läuft.
Flee: läuft von Spielern weg und schafft so mehr Abstand zwischen ihnen.
Dodge: Weiche dem nächsten Spieler Projektiel aus, indem er im 90° Winkel dazu davon läuft.
Diese Verhaltensweisen wurden durch verschiedene Parameter beeinflusst, welche beim inizieren der Gegner zufällig in einem bestimmten Bereich gesetzt wurden. Dadurch konnten wir jeden Gegner etwas besonders machen und ihm etwas unterschiedliches und einzigartigeres Verhalten mit geben. Es wurde so beispielsweise festgelegt wie nah sich ein Gegner traut befor er anfängt weg zu laufen oder auch ab wie vielen schüssen auf ihn er anfängt auszuweichen.
Diese Verhaltensweisen wurden durch verschiedene Parameter beeinflusst, welche beim Initiieren der Gegner zufällig in einem bestimmten Bereich gesetzt wurden. Dadurch konnten wir jeden Gegner etwas besonders machen und ihm etwas unterschiedliches und einzigartigeres Verhalten mit geben. Es wurde so beispielsweise festgelegt wie nah sich ein Gegner traut, bevor er anfängt weg zu laufen oder auch ab wie vielen Schüssen auf ihn er anfängt auszuweichen.
Die States besitzen dabei eine Reihenfolge in welcher sie Prioritisiert werden. Die Grundlegende Prioritisierung ist dabei:
Die States besitzen dabei eine Reihenfolge, in welcher sie priorisiert werden. Die grundlegende Priorisierung ist dabei:
Attack > Dodge > Follow > Flee
Wobei sich die Reihenfolge auch leicht ändern kann, je nachdem wie die Parameter gesetzt wurden. Follow beispielsweise ist umso wichtiger umso weiter ein Gegner entfernt von Characteren ist. So konnten wir sicher stellen das sie nicht schon am Anfang weglaufen. Außerdem weichen Gegner beispielsweise nicht aus und laufen nicht so schnell davon. Mit solchen kleinen Kniffen haben wir versucht ein tiefgründigeres Verhalten in die Gegner zu implementieren.
Wobei sich die Reihenfolge auch leicht ändern kann, je nachdem wie die Parameter gesetzt wurden. Follow beispielsweise ist umso wichtiger, umso weiter ein Gegner entfernt von den Charakteren ist. So konnten wir sicher stellen, dass sie nicht schon am Anfang weglaufen. Außerdem weichen Gegner beispielsweise nicht aus und laufen nicht so schnell davon. Mit solchen kleinen Kniffen haben wir versucht ein tiefgründigeres Verhalten in die Gegner zu implementieren.
Ein weiteres Verhalten der Gegner kann das Ghosten sein. Hierbei handelt es sich um Spezielle gegner, welche die Eingaben des nächstgelegenen Spielers imitieren. Hierfür lesen sie die Eingaben des Spielers mit und laufen beispielsweise in die Gleiche richtung, wobei die Intänsität des Ghostens variabel ist und beim erzeugen der Gegner festgelegt wird.
Ein weiteres Verhalten der Gegner kann das Ghosten sein. Hierbei handelt es sich um spezielle Gegner, welche die Eingaben des nächstgelegenen Spielers imitieren. Hierfür lesen sie die Eingaben des Spielers mit und laufen beispielsweise in die gleiche Richtung, wobei die Intensität des Ghostens variabel ist und beim Erzeugen der Gegner festgelegt wird.
Es gibt noch einige weitere Zusammenhänge wie beispielsweise die Treffsicherheit, welche in Verbindung mit der Angriffsgeschwindigkeit liegt. So wird bei höheren angriffsgeschwindigkeiten ein erhöhter zufallswinkel auf den Abschuss von Pfeilen gesetzt und Nahkämpfer verfehlen ihre Angriffe. Sollten sie jedoch eine Weile nicht angreifen (da sie beispielsweise erst zum Spieler laufen müssen) können sie sich "Konzentrieren und verbessern kurzzeitig ihre Treffsicherheit für den ersten Angriff).
Es gibt noch einige weitere Zusammenhänge, wie beispielsweise die Treffsicherheit, welche in Verbindung mit der Angriffsgeschwindigkeit liegt. So wird bei höheren Angriffsgeschwindigkeiten ein erhöhter Zufallswinkel auf den Abschuss von Pfeilen gesetzt und Nahkämpfer verfehlen ihre Angriffe. Sollten sie jedoch eine Weile nicht angreifen (da sie beispielsweise erst zum Spieler laufen müssen) können sie sich "konzentrieren und verbessern kurzzeitig ihre Treffsicherheit für den ersten Angriff).
Diese ganzen Zusammenhänge und einflüsse auf unterschiedliche Dinge machten das Ballancing jedoch sehr schwer für eine Person, weswegen nur ein Rudimentäres Ballancing von Alex vorgenommen wurde. Hauptsächlich wurden hier nur Grundwerte geballanced und der Einfluss des Nebels auf den Angriff und die Geschwindigkeit der Gegner.
Diese ganzen Zusammenhänge und Einflüsse auf unterschiedliche Dinge machten das Balancing jedoch sehr schwer für eine Person, weswegen nur ein Rudimentäres Balancing von Alex vorgenommen wurde. Hauptsächlich wurden hier nur Grundwerte gebalanced und der Einfluss des Nebels auf den Angriff und die Geschwindigkeit der Gegner.
Alex entschied für dieses Projekt die Netzwerk Bibliothek Photon zu nutzen welche eine mehr oder weniger Einfachere Version von UnityNetwork ist. Es hat sich jedoch herausgestellt, das nur das erstellen von Multiplayer Räumen und das joinen bzw. rejoinen nach einem verbindungsabbruch einfacher gemacht ist. Alle anderen Aspekte waren recht kniffelig einzubinden.
Alex entschied für dieses Projekt die Netzwerk Bibliothek "Photon" zu nutzen, welche eine mehr oder weniger einfachere Version von UnityNetwork ist. Es hat sich jedoch herausgestellt, dass nur das Erstellen von Multiplayer Räumen und das Joinen bzw. Rejoinen nach einem Verbindungsabbruch einfacher gemacht ist. Alle anderen Aspekte waren recht kniffelig einzubinden.
Es stellte sich mit mehreren Entwicklern als schwierig heraus alle Objekte immer über das Netzwerk zu syncronisieren, da bereits eine neue Funktion welche z.b. die Bewegung von gegnern einschränkt eventuell nicht über das Netzwerk geshared ist und somit eine desyncronisation verursachen kann.
Es stellte sich mit mehreren Entwicklern als schwierig heraus alle Objekte immer über das Netzwerk zu syncronisieren, da bereits eine neue Funktion welche z.b. die Bewegung von Gegnern einschränkt eventuell nicht über das Netzwerk geshared ist und somit eine Desyncronisation verursachen kann.
Um den Multiplayer einzubinden musste sich Alex zunächst einige Photonkentnisse aneigenen, was vor allem durch kleine Demos geschah in denen Objekte syncronisiert wurden und sich bewegten. Ein großer Teil der Zeit wurde vor allem auch für das löschen von Syncronisierten Objekten aufgewendet, da es hier ab und an vor kam das eine Desyncronisation entstand, welches die hälfte der Spielfunktionen auf einen Streich lahm legte.
Um den Multiplayer einzubinden musste sich Alex zunächst einige Photonkentnisse aneigenen, was vor allem durch kleine Demos geschah, in denen Objekte syncronisiert wurden und sich bewegten. Ein großer Teil der Zeit wurde vor allem auch für das Löschen von syncronisierten Objekten aufgewendet, da es hier ab und an vor kam das eine Desyncronisation entstand, welches die Hälfte der Spielfunktionen auf einen Streich lahm legte.
Die Grundlegenden möglichkeiten bestehen jedoch. Zu diesen zählen beispielsweise:
Eine Lobby erstellen, einer Lobby beitreten, reconnecten nach einem Verbindungsabbruch, dem verlassen einer Sitzung (ohne das dabei das Spiel abstürzt oder ein unerlaubter State entsteht) und natürlich dem Spielen und Syncronisieren von Objekten.
Es gibt jedoch immer noch Buggs mit denen man zu kämpfen hat, welche Alex auch nach Tagen intensiver Suche nicht finden konnte, wobei es beim Enemy count zu einer Desyncronisation kommen kann, wodurch sofort Unendlich viele Gegner gespawned werden oder garkeine mehr, wobei beides das Spiel unspielbar machte. Dieser fehler tritt jedoch sehr zufällig auf und ist von Sitzung zu Sitzung unabhängig (wenn der Fehler in der Ersten Welle nicht auftritt wird er auch das ganze Spiel nicht auftreten (Der fehler tritt in 4 von 10 Spielen auf))
Die grundlegenden Möglichkeiten bestehen jedoch. Zu diesen zählen beispielsweise:
Eine Lobby erstellen, einer Lobby beitreten, reconnecten nach einem Verbindungsabbruch, dem Verlassen einer Sitzung (ohne das dabei das Spiel abstürzt oder ein unerlaubter State entsteht) und natürlich dem Spielen und Syncronisieren von Objekten.
Es gibt jedoch immer noch Buggs mit denen man zu kämpfen hat, welche Alex auch nach Tagen intensiver Suche nicht finden konnte, wobei es beim Enemy Count zu einer Desyncronisation kommen kann, wodurch sofort unendlich viele Gegner gespawned werden oder garkeine mehr, wobei beides das Spiel unspielbar machte. Dieser Fehler tritt jedoch sehr zufällig auf und ist von Sitzung zu Sitzung unabhängig (wenn der Fehler in der ersten Welle nicht auftritt wird er auch das ganze Spiel nicht auftreten (Der Fehler tritt in 4 von 10 Spielen auf)).
### 5.2.3 Department "UX"
#### State of the Art & Research
Nach dem das Moodboard erstellt war, wurden die aktuellen Gamingtrends analysiert.
In der Competitor Analyse geht es darum, die mögliche Konkurrenz auf dem Markt zu analysieren und herauszufinden, was man besser machen kann. Wir hatten einige Spiele zu Auswahl, legten uns aber auf die folgenden fest. Die untersuchten Spiele waren: The binding of isaac, Moonlighter, Nuclear Throne und noch vier weitere, welche als Beispiel dienten.
In der Competitor Analyse geht es darum, die mögliche Konkurrenz auf dem Markt zu analysieren und herauszufinden, was man besser machen kann. Wir hatten einige Spiele zu Auswahl, legten uns aber auf ein paar fest. Die untersuchten Spiele waren: The binding of isaac, Moonlighter, Nuclear Throne und noch vier weitere, welche als Beispiel dienten.
Die Analyse diente uns als Vergleich was momentan gespielt wird und was die Konkurrenz gut, beziehungsweise auch schlecht gemacht hat. Daraus ergaben sich Ziele, was wir erreichen wollten und welche Aspekte wir nicht mitaufnehmen wollten. Details sind im Git Wiki unter "UX & Research" zu finden.
#### Informations- und Navigationsarchitektur:
...
...
@@ -229,19 +229,19 @@ Das UI Kit [3] stellte einen einheitlichen Design-Leitfade dar. Durch Angaben zu
#### Prototyping und User Testing
Durch den iterativen Projektansatz war es uns möglich, das Game in drei Stufen zu testen. Dabei handelte es sich jeweils um Prototypen, also um Konzepte mit zunehmender Genauigkeit und Detailtreue. Dabei stellte der Papierprototyp Stufe 1 dar, mit Hilfe dessen wir die größten Schwierigkeiten in Bezug auf die Bedienbarkeit und des Designs finden konnten. Das direkte Feedback der fünf Personen wurde dann direkt in die nächste Iteration, die des Low fidelity Prototyp, eingebaut. Dieses bezog sich besonders auf den allgemeinen Designansatzes: wir entschieden Pop-ups für alle Inhalte zu nutzen, da diese für den User näher wirken und zum Stil des Spiels passten. Außerdem waren kurze Erklärungstexte bei dem Steuerungs-Screen gewünscht, um die Funktion der einzelnen Tasten deutlicher zu machen, sowie um die direkte Einbindung der Mini-Karte in das Spiel gebeten. Grund dazu war, dass die Probanden nicht immer während dem Spielen extra auf einen Button klicken wollen. *Weiteres Feedback findet sich im Anhang.*
Auf Stufe 2 findet sich der klickbare Low fidelity Prototyp, der mithilfe von Adobe XD erstellt wurde. Wir legten das Dokument auf der Adobe Cloud ab, um gemeinsam daran arbeiten und über Änderungen diskutieren zu können. Da das Design nicht im Vordergrund stand, wurden Platzhalter für Bilder und Buttons verwendet. Beim User Testing ging es primär um die allgemeine Struktur und den Zusammenhang der einzelnen Komponenten. Wir testeten mit fünf Personen im Alter von 19 bis 27 Jahren. Wunsch war es die Fähigkeitenregler der Helden manuell selbst einstellen zu können. In der jetzigen Versionen waren die jeweiligen Fähigkeiten schon pro Heldenart (Fern-, Nahkämpfer) vordefiniert und konnten nicht einzeln verändert werden. Außerdem war der Button „Erklärung“ in dem Slide „Player Mode“ unnötig, da die Begriffe für jeden gut verständlich waren und keiner Erklärung benötigten. Die Probanden fanden dies eher störend. Einstellungen zum Spiel waren ebenso gewünscht wie die Möglichkeit sich das Erklärungstutorial nochmal anschauen zu können, falls es vergessen wurde. Dafür bauten wir einen neuen Screen und verlinkten über das „Einstellung“ Symbol im Hauptmenü. Zudem wurde gewünscht das Spiel pausieren und beenden zu können. Wir hatten diese Funktionen zunächst vernachlässigt, merkten durch die Tests jedoch, dass sie für die User Experience maßgeblich dazugehörten. Somit passten wir alles an und arbeiteten die Rückmeldung ein. *Weiteres Feedback findet sich im Anhang.*
Auf Stufe 2 findet sich der klickbare Low fidelity Prototyp, der mithilfe von Adobe XD erstellt wurde. Wir legten das Dokument auf der Adobe Cloud ab, um gemeinsam daran arbeiten und über Änderungen diskutieren zu können. Da das Design nicht im Vordergrund stand, wurden Platzhalter für Bilder und Buttons verwendet. Beim User Testing ging es primär um die allgemeine Struktur und den Zusammenhang der einzelnen Komponenten. Wir testeten mit fünf Personen im Alter von 19 bis 27 Jahren. Wunsch war es die Fähigkeitenregler der Helden manuell selbst einstellen zu können. In der jetzigen Versionen waren die jeweiligen Fähigkeiten schon pro Heldenart (Fern-, Nahkämpfer) vordefiniert und konnten nicht einzeln verändert werden. Außerdem war der Button „Erklärung“ in dem Slide „Player Mode“ unnötig, da die Begriffe für jeden gut verständlich waren und keiner Erklärung benötigten. Die Probanden fanden dies eher störend. Einstellungen zum Spiel waren ebenso gewünscht wie die Möglichkeit sich das Erklärungstutorial nochmal anschauen zu können, falls es vergessen wurde. Dafür bauten wir einen neuen Screen und verlinkten über das „Einstellung“ Symbol im Hauptmenü. Zudem wurde gewünscht das Spiel pausieren und beenden zu können. Wir hatten diese Funktionen zunächst vernachlässigt, lernten durch die Tests jedoch, dass sie für die User Experience maßgeblich dazugehörten. Somit passten wir alles an und arbeiteten die Rückmeldung ein. *Weiteres Feedback findet sich im Anhang.*
Als letzte Vorstufe zum fertigen Spiel, kann der high fidelity Prototyp angesehen werden. Dieser weist durch die fertigen Designs der Controls und den Spielfiguren eine sehr hohe Genauigkeit und Detailtreue auf. Er eignet sich daher perfekt um das Spiel zu testen, ohne es implementieren zu müssen. Somit war es uns möglich letztes Feedback zu sammeln, ohne auf die Entwicklung angewiesen zu sein. In unseres Fall war dies sehr hilfreich, da Alexander und Oliva zu diesem Zeitpunkt noch mitten in der Entwicklung steckten. Im Gegensatz zu den beiden vorherigen Iterationen gab es nicht mehr so viel Rückmeldung, da vieles schon verbessert wurde. Durch die Erstellung eines UI Kits hatten Julian, Tamara und Susanne ein einheitliches Verständnis darüber. Susanne erstellte die Control Elemente und Team UX baute dann alles in dem Prototyp zusammen. Dabei funktionierte die Absprache und Zusammenarbeit sehr gut. Die Farben gefielen den vier Testpersonen gut, da es den comichaften Charakter der Figuren unterstützte. Außerdem fanden drei der Probanden die Position des „Einstellung“ Icon unpassend, da es getrennt von den anderen Buttons wahrgenommen wurde. Hierbei könnte man über eine andere Anordnung nachdenken. Des Weiteren wurde der „Zurück-Button“ und „Fertig-Button“ als teilweise redundant kritisiert (siehe Screen „Steuerung“). Da jedoch nur zwei Personen dieser Meinung waren und die anderen es hilfreich fanden, nicht in die obere linke Ecke navigieren zu müssen, müsste man eine erneute Befragung mit anderen Testpersonen vornehmen, um eine endgültige Entscheidung treffen zu können. Ein Infobutton mit Mouse Hover über die „Ultimative Fähigkeit“ zur Erklärung ist zudem denkbar, um Verwirrung zu verhindern. Dabei ist jedoch zu beachten, die Screens nicht zu überladen und das Spiel so übersichtlich wie möglich zu halten.
Als letzte Vorstufe zum fertigen Spiel, kann der high fidelity Prototyp angesehen werden. Dieser weist durch die fertigen Designs der Controls und den Spielfiguren eine sehr hohe Genauigkeit und Detailtreue auf. Er eignet sich daher perfekt um das Spiel zu testen, ohne es implementieren zu müssen. Somit war es uns möglich letztes Feedback zu sammeln, ohne auf die Entwicklung angewiesen zu sein. In unseres Fall war dies sehr hilfreich, da Alexander und Oliva zu diesem Zeitpunkt noch mitten in der Entwicklung steckten. Im Gegensatz zu den beiden vorherigen Iterationen gab es nicht mehr so viel Feedback und Verbesserungswünsche als zuvor, da vieles schon verbessert wurde. Durch die Erstellung eines UI Kits hatten Julian, Tamara und Susanne ein einheitliches Verständnis darüber. Susanne erstellte die Control Elemente und Team UX baute dann alles in dem Prototyp zusammen. Dabei funktionierte die Absprache und Zusammenarbeit sehr gut. Die Farben gefielen den vier Testpersonen gut, da es den comichaften Charakter der Figuren unterstützte. Als eher negativ empfanden drei der Probanden jedoch die Position des „Einstellung“ Icon, da es getrennt von den anderen Buttons wahrgenommen wurde. Hierbei könnte man über eine andere Anordnung nachdenken. Des Weiteren wurde der „Zurück-Button“ und „Fertig-Button“ als teilweise redundant kritisiert (siehe Screen „Steuerung“). Da jedoch nur zwei Personen dieser Meinung waren und die anderen es hilfreich fanden, nicht in die obere linke Ecke navigieren zu müssen, müsste man eine erneute Befragung mit anderen Testpersonen vornehmen, um eine endgültige Entscheidung treffen zu können. Ein Infobutton mit Mouse Hover über die „Ultimative Fähigkeit“ zur Erklärung ist zudem denkbar, um Verwirrung zu verhindern. Dabei ist jedoch zu beachten, die Screens nicht zu überladen und das Spiel so übersichtlich wie möglich zu halten.
Insgesamt hatten Julian und Tamara bei dem dritten Testing die Schwierigkeit Probanden zu finden, da Freunde und Bekannte schon die früheren Iterationen getestet hatten und wir, aus Gründen der Datenverfälschung durch Vorkenntnisse, nicht die Personen doppelt befragen wollten. Wir schafften es am Ende noch vier Personen des niedrigen Semesters zu akquirieren, die bei Tamara das Mathetutorium besuchten.
Das Feedback wurde von Tamara und Julian dann direkt umgesetzt und die finale Version in Unity implementiert. Dabei war es uns leider nicht möglich alle Funktionen und Designs so umzusetzen, wie wir es im Prototypen erstellt hatten. Das lag an der Tatsache, dass die Implementierung der Funktionen und Screens natürlich in echt viel länger dauert, als in Adobe XD und Alexander und Oliva die einzigen beiden Entwicklern waren. Trotzdem zeigt der Prototyp gut wie eine Weiterentwicklung des Spiels aussehen könnte und auf welche Dinge man dabei aus User Experience Sicht achten sollte. *Weiteres Feedback findet sich im Anhang.*
Das Feedback wurde von Tamara und Julian dann direkt umgesetzt und die finale Version in Unity implementiert. Dabei war es uns leider nicht möglich alle Funktionen, Rückmeldungen und Designs so umzusetzen, wie wir es im Prototypen erstellt hatten. Das lag an der Tatsache, dass die Implementierung der Funktionen und Screens natürlich in Echt viel länger dauert, als in Adobe XD und Alexander und Oliva die einzigen beiden Entwicklern waren. Trotzdem zeigt der Prototyp gut wie eine Weiterentwicklung des Spiels aussehen könnte und auf welche Dinge man dabei aus User Experience Sicht achten sollte. *Weiteres Feedback findet sich im Anhang.*
Alle Adobe XD Dateien und ausführlichen Testergebnisse finden sich unter Anhang [4].
Alle Adobe XD Dateien und Testergebnisse finden sich unter Anhang [4].
### 5.3.4 Department "Projektmanagement"
...
...
@@ -252,10 +252,11 @@ Mithilfe des Kanban Boards hatte jeder im Team zu jedem Zeitpunkt eine klare Üb
#### Allgemeiner Zeitplan:
Um den allgemeinen Überblick über wichtige Ereignisse und die Stage zu behalten, wurde von Tamara ein groben Zeitplan erstellt [5] und die wichtigsten Daten eingetragen. Dabei spielten besonders Abgaben und die Zeit zu Beginn des Projekts und vor der Medianight eine Rolle. Da wir anfänglich noch nicht genau abschätzen konnten wie viel Zeit die Einarbeitung in das Thema brauchte, wurde die Arbeitsphase selbst hier nicht abgebildet. Die Abgabetermine und einzelnen Tasks, innerhalb des Projektablaufs, wurden über Git Issues und Milestones organisiert (siehe unten). Sie kümmerte sich außerdem auch um die Projektanmeldung, und -koordination, sowie die Bearbeitung der Stage.
Die knappe Zeitspanne von einem Semester ließ es leider nicht zu, jedes Feedback der Tester und die von Usability Sicht konzertierten Funktionen zu vollständig implementieren. Grund dafür waren die vielen Einzelheiten und der geplant große Funktionsumfang, der mit zwei Entwicklern nicht zu schaffen war. Wir fokussierten uns somit auf die wichtigsten Aspekte des Spiels. Nach Absprache mit Herr Prof. Kriha werden die Prototypen als zusätzliche Komponente zum aktuellen Entwicklungsstand gesehen. Es hat sich gezeigt, dass zur Realisierung eines zu umfangreichen Spiels inkl. Usability Testing mehr Zeit benötigt wird.
#### Problematik:
Die knappe Zeitspanne von einem Semester ließ es leider nicht zu, jedes Feedback der Tester und die von Usability Sicht konzertierten Funktionen zu vollständig implementieren. Grund dafür waren die vielen Einzelheiten und der geplant große Funktionsumfang, der mit zwei Entwicklern nicht zu schaffen war, wie oben schon erwähnt. Wir fokussierten uns somit auf die wichtigsten Aspekte des Spiels. Nach Absprache mit Herr Prof. Kriha werden die Prototypen als zusätzliche Komponente zum aktuellen Entwicklungsstand gesehen. Es hat sich gezeigt, dass zur Realisierung eines zu umfangreichen Spiels inkl. Usability Testing mehr Zeit benötigt wird. Tamara lernte durch dieses Projekt sehr viel. Besonders, dass die Entwicklung eines Spiels mit User Experience Anteil sich doch deutlich von der einer App ode Webseite unterschied. Wir schafften es glücklicherweise, trotz Zeitmangel, die wichtigsten Designs umzusetzen, um an der Media Night ein gut spielbares und schön gestaltendes Spiel vorzustellen. Dies war besonders auf die verstärkte Zusammenarbeit der letzten Wochen zurückzuführen.
#### Git Issue Board:
Git Issues werden als Liste und Board in Git strukturiert. Dabei stellt Letzteres ein einfaches Kanban Board dar, das mit verschiedene Spalten und Labels für die Organsiation von anfallenden Aufgaben verwendet werden kann. Initial setzte Tamara das Board auf und erstellte Labels wie z.B. "Design", "UX", "Development", "Organizational", "Must-have" oder "could-have", um Priorisierung und die Zuordnung der verschiedenen Departments deutlich zu machen. Außerdem ist es möglich ein Ticket direkt einem Teammitglied zuzuweisen, sowie Duedates und Milestones anzuhängen. Das Erstellen der Tickets stellten in unserem Projekt keine Schwierigkeit dar, auch wenn die Issues von den Teammitglieder unterschiedlich stark. genutzt wurden. Insgesamt hat die Organisation der Aufgaben darüber aber reibungslos funktioniert und nichts Wichtiges wurde vergessen. Jedoch könnte man das nächste Mal z.B. "ready for test or review" einfach in "blocked" integrieren, um die Anzahl der Spalten zu reduzieren und die Übersichtlichkeit zu erhöhen. Ebenso wurde "should-have" und "urgent" bei uns nie genutzt und kann das nächste Mal weggelassen werden. Als weitere Ebene der Organisation nutzten wir Milestones. Dazu haben wir den MI Präsentationstag, die Media Night und Projektabgabe angelegt. Granularere Milestones waren in diesem Projekt nicht nötig. Die Zeitplanung und -Organisation der Aufgaben sollte so einfach wie möglich gehalten werden. Details sind im Git Wiki unter "Git Issues Board" zu finden.
Git Issues werden als Liste und Board in Git strukturiert. Dabei stellt Letzteres ein einfaches Kanban Board dar, das mit verschiedene Spalten und Labels für die Organsiation von anfallenden Aufgaben verwendet werden kann. Initial setzte Tamara das Board auf und erstellte Labels wie z.B. "Design", "UX", "Development", "Organizational", "Must-have" oder "could-have", um Priorisierung und die Zuordnung der verschiedenen Departments deutlich zu machen. Außerdem ist es möglich ein Ticket direkt einem Teammitglied zuzuweisen, sowie Duedates und Milestones anzuhängen. Das Erstellen der Tickets stellte in unserem Projekt keine Schwierigkeit dar, auch wenn die Issues von den Teammitglieder unterschiedlich stark genutzt wurden. Insgesamt hat die Organisation der Aufgaben darüber aber reibungslos funktioniert und nichts Wichtiges wurde vergessen. Jedoch könnte man das nächste Mal z.B. "ready for test or review" einfach in "blocked" integrieren, um die Anzahl der Spalten zu reduzieren und die Übersichtlichkeit zu erhöhen. Ebenso wurde "should-have" und "urgent" bei uns nie genutzt und kann das nächste Mal weggelassen werden. Als weitere Ebene der Organisation nutzten wir Milestones. Dazu haben wir den MI Präsentationstag, die Media Night und Projektabgabe angelegt. Granularere Milestones waren in diesem Projekt nicht nötig. Die Zeitplanung und -Organisation der Aufgaben sollte so einfach wie möglich gehalten werden. Details sind im Git Wiki unter "Git Issues Board" zu finden.
#### Git Wiki:
Alle (Teil-)Dokumentationen und Zwischenergebnisse wurden über das Git Wiki festgehalten, um nichts Wichtiges zu vergessen und strukturiert arbeiten zu können. Das stellte besonders im Bereich UX sehr eine große Hilfe dar, um die Recherche und User Test Ergebnisse zu dokumentieren. Dazu wurde Markdown als allgemeingültige Syntax verwendet.
...
...
@@ -266,39 +267,32 @@ Die interne Kommunikation wurde komplett über Whatsapp abgehandelt. Tamara hatt
Die Absprache mit Herr Prof. Kriha erfolgte ebenfalls nach Absprache und war besonders am Anfang sehr hilfreich, um Anforderungen zu klären und die Erwartungen auf beiden Seiten zu synchronisieren.
#### Datenablage:
Alle Dokumente werden primär auf einer geteilten GDrive Ablage abgelegt. Im UX Bereich hat es Sinn gemacht direkt die Cloud Funktion von AdobeXD zu verwenden, um immer an der neusten Version der Prototpyen arbeiten zu können. Dazu gehörte neben den Prototypen auch das Moodboard, Personas oder das UI Kit.
Alle Dokumente werden primär auf einer geteilten GDrive Ablage abgelegt. Dazu gehörte neben den Prototypen auch das Moodboard, Personas oder das UI Kit. Im UX Bereich hat es Sinn gemacht direkt die Cloud Funktion von AdobeXD zu verwenden, um immer an der neusten Version der Prototpyen arbeiten zu können.
## 6. MI-Präsentationstag & Medianight
Für den MI-Präsentationstag erstellte Tamara ein Factesheet und Alexander und Niklas präsentierten unsere Idee vor den Studierenden und Professoren. Zur Präsentation an der Medianight erstellte Tamara außerdem noch ein Poster und organisierte die benötigten Materialen und den Ablauf. Dabei hatte sie anfänglich Probleme mit der Erstellung der Materialen, besonders mit der Druckdatei. Durch fehlende Vorkenntnisse mit Adobe Illustrator fiel ihr die Erstellung erst schwer, zumal eine Umwandlung in den YCYK Farbraum und ein spezifischer Anschnitt für das Drucken des Posters nötig war. Nach Einarbeitung in das Programm, war jedoch die Erstellung kein Problem mehr und sie konnte ihre Fähigkeiten in dem Bereich stark verbessern. Zudem stand sie in ständiger Kommunikation mit Frau Schlitter, um einen reibungslosen Ablauf zu ermöglichen. Uns war möglich das Spiel soweit fertigzustellen, dass es direkt an der Media Night ausprobiert werden konnte. Es fand durchweg positiven Anklang und begeisterte besonders durch die comichafte Grafik und die Idee des Nebels.
## 7. Lernerfolg
Susanne wollte bei einem Projekt im designerischen Bereich eines Spiels mal reinschauen und erste Erfahrungen sammeln. Das hat sich anfangs nicht wirklich als einfach gestaltet und war mit sehr viel Recherche und Inspirationen finden verbunden. Am Anfang war es sehr schwer sich in ein Spiel hineinzufinden. Zudem war es auch nicht so einfach herauszufinden welche Inhalte wichtig für ein User Interface eines Games sind. In Absprache mit den anderen Departments konnte dann das User Interface erstellt werden, mit den wichtigen Infos die z.B. für den Spieler während des Spiels ersichtlich sind. Da die Icons sehr einfach gestaltet werden sollte, lernte Susanne dass es einfacher ist, erstmal nur in Adobe XD zu arbeiten, nur für wenige Einzelheiten musste zu Affinity Designer gewechselt werden. Dadurch lernte Sie besser in beiden Programmen umzugehen und so einige Besonderheiten mit der Arbeit der Programme. Sowie Farben gespeichert werden in Adobe XD, damit man später die einzelnen Farben des ganzen Prototypen schnell geändert werden konnten. Zusätzlich hat Susanne gerlernt, dass es schon nochmal ein großer Unterschied ist, ein User Interface für Games zu erstellen, denn es werden ganz andere Blickpunkte betrachtet.
Susanne wollte bei einem Projekt im designerischen Bereich eines Spiels mal reinschauen und erste Erfahrungen sammeln. Das hat sich anfangs nicht wirklich als einfach gestaltet und war mit sehr viel Recherche und Inspirationen finden verbunden. Am Anfang war es sehr schwer sich in ein Spiel hineinzufinden. Zudem war es auch nicht so einfach herauszufinden welche Inhalte wichtig für ein User Interface eines Games sind. In Absprache mit den anderen Departments konnte dann das User Interface erstellt werden, mit den wichtigen Infos die z.B. für den Spieler während des Spiels ersichtlich sind. Da die Icons sehr einfach gestaltet werden sollte, lernte Susanne dass es einfacher ist erstmal nur in Adobe XD zu arbeiten - nur für wenige Einzelheiten musste zu Affinity Designer gewechselt werden. Dadurch lernte Sie besser in beiden Programmen umzugehen und so einige Besonderheiten mit der Arbeit der Programme. Z.B wie Farben gespeichert werden in Adobe XD, damit man später die einzelnen Farben des ganzen Prototypen schnell geändert werden konnten. Zusätzlich hat Susanne gerlernt, dass es schon nochmal ein großer Unterschied ist, ein User Interface für Games zu erstellen, denn es werden ganz andere Blickpunkte betrachtet.
Niklas wollte sich vor allem das Erstellen der Ingame-Grafik vornehmen. Hierbei lernte er sehr schnell, dass das Erstellen von mehreren Charakteren im gleichen Stil deutlich schwerer ist, als das Erstellen eines einzelnen Charakters. Allerdings machte es ihm sehr viel Spaß, verschiendene Skizzen anzufertigen, um den gleichen Stil für die Grafik zu erreichen. Der größte Lernerfolg liegt hierbei darin, dass er nun weiß, wie er vorzugehen hat, um mehrere Grafiken für ein Spiel anzufertigen, da er anfangs wild "ins Blaue" skizziert hat und nachdem er mit den ersten beiden Charakteren fertig war, ein immer besseres Gefühl dafür hatte, wie er die Charaktere gestalten sollte. Der zweite große Lernerfolg liegt darin, dass er sich das Programm "Adobe Illustrator", mit dem er davor nur wenig Kontakt hatte, durch verschiedene Tutorials beigebracht hat und sich nun in der Lage sieht, mit dem Programm effizient arbeiten zu können.
> TODO: Alex korektur lesen
Alex hatte am meisten im Bereich Modularem Programmieren, sowie den Multiplayer Funktionen gelernt. Da es in diesem Projekt mehr Teilnehmer gab welche auch alle auf einem verschiedenen Stand waren beim Programmieren musste er lernen seine Software so zu schreiben, das sie einfach bedient werden kann. Funktionen sollten bei der Anbindung und Gebrauch einfach verständlich sein und auf Anhieb funktionieren. Im Multiplayeraspekt hat er sich weiterentwickelt da er nun mit Photon eine neue Bibliothek kennen gelernt hat und nun einen Vergleich von mehreren Multiplayer Bibliotheken kennt und so abschätzen kann was sich lohnt und was vielleicht unnötig wäre.
Ein weiterer Lernerfolg war nach Möglichkeit alles Procedural zu gestalten, wodurch auch der Code Procedural an alle Objekte angehängt werden können sollte. Dies war zunächst schwierig und musste schrittweise gelernt werden und durchlief dabei mehrere Stadien, wobei zunächst Liniare Ziele angestrebt worden sind und später schritt für schritt direkte Ergebnisse herausgeworfen wurden, um generierte ein zu binden. Außerdem konnte er sich darin weiter bilden den Teamkolegen unter die Arme zu greifen was Unity angeht, da er durch das vorherige Projekt bereits Erfahrungen damit sammeln konnte und diese nun teilen konnte. Dabei war es wichtig allen nur das bei zu bringen was für die Aufgaben erforderlich waren und Sie in die richtige Richtung zu leiten da Unity sonst sehr überfüllt mit Möglichkeiten und Baustellen an welchen man sich weiterbilden kann ist.
Olivia wollte sich im Projekt die Shader Programmierung anschauen. Mithilfe von Unitys "Shader Graph" konnte sie einen relativ einfachen Einstieg in ein komplexes Thema finden. Zusätzlich hat sie sich ein bisschen mit eigenständiger Shader Programmierung beschäftigen können als sie mit Compute Shadern herumexperimentiert hat.
Das Projekt hat auch allgemein geholfen ihre Erfahrung im Programmieren zu erweitern und neue Herausforderungen zu bewältigen.
Das Projekt hat auch allgemein geholfen ihre Erfahrung im programmieren zu erweitern und neue Herausforderungen zu bewältigen.
Außerdem konnte sie sich in das Animationssystem in Unity einarbeiten und somit erste Erfahrungen im Bereich 2D Animation sammeln.
Das größere Team stellte auch eine neue Herausforderung, da die Koordination deutlich komplizierter war. Die Teammitgliedern, die noch nichts mit Unity zu tun hatten, konnte sie dabei unterstützen sich in der Engine zu orientieren und die Grundlagen zu verstehen.
Für Julian war die größte Erfahrung an einer Spielentwicklung aus Sicht der Usability beteiligt zu sein. Da für ihn in diesem Projekt das erste mal Usability mit einem Spiel in Kontakt trat. Bisher hatte er UI/UX nur für Apps, Websites oder Interfaces erstellt und hatte somit eine neue Erfahrung. Der größte Lernerfolg zeigte sich darin, dass Spiele extrem von UX-Design profitieren und Julian merkte trotz anfänglicher Unsicherheiten gute Fortschritte.
Der größte Lernerfolg konnte Tamara im Bereich Projektmanagement verbuchen, da es für sie eine ganz neue Erfahrung war mit einem Team von sechs Personen zu arbeiten. Sie merkte schnell, dass größere Gruppen dabei andere Herausforderungen mit sich bringen, als die, die sie durch Projekte mit nur drei Teammitglieder kannte. Die Kommunikation mit HdM Verantwortlichen fiel ihr leicht und nach anfänglichen Schwierigkeiten stellte auch die interne Kommunikation keine Probleme dar.
Lernte sie in ihrem Studium die beiden agilen Methoden Scrum und Kanban nur theoretisch, war das Projekt eine super Möglichkeit zur praktischen Umsetzung, an der sie wuchs. Sie fühlt sich nun viel sicherer im Umgang mit agilen Projektmanagementmethoden.
Da sie außerdem noch nie bei einer Spieleentwicklung beteiligt war, lernte sie sehr viel in diesem Bereich dazu. Besonders lehrreich war die Integration von UX und User Testing in die Entwicklung der Desktopanwendung, die sich zur Entwicklung einer App oder Webseite unterschied. So musste viel mehr Wert auf den Spielflow und eine einfache Steuerung gelegt werden, um das Game benutzerfreundlich zu gestalten. Der Zeitaufwand wurde von Tamara anfänglich auch unterschätzt, was bei ihr gegen Ende Stress aufbaute. Insgesamt war es eine wertvolle Erfahrung, die Tamara fachlich weiterbrachte.
Mit der größte Lernerfolg konnte Tamara im Bereich Projektmanagement verbuchen, da es für sie eine ganz neue Erfahrung war mit einem Team von sechs Personen zu arbeiten. Sie merkte schnell, dass größere Gruppen dabei andere Herausforderungen mit sich bringen, als die, die sie durch Projekte mit nur drei Teammitglieder kannte. Die Kommunikation mit HdM Verantwortlichen fiel ihr leicht und nach anfänglichen Schwierigkeiten stellte auch die interne Kommunikation keine Probleme dar.
Lernte sie in ihrem Studium die beiden agilen Methoden Scrum und Kanban nur theoretisch, war das Projekt eine super Möglichkeit zur praktischen Umsetzung, an der sie wuchs. Sie fühlt sich nun viel sicherer im Umgang mit agilen Projektmanagementmethoden und deren Vorteilen.
Da sie außerdem noch nie bei einer Spieleentwicklung beteiligt war, lernte sie sehr viel in diesem Bereich dazu. Dazu gehörte auch die Konzeption der Idee, in die sie sich erst einmal einfinden musste. Besonders lehrreich war auch die Integration von UX und User Testing in die Entwicklung der Desktopanwendung, die sich zur Entwicklung einer App oder Webseite unterschied. So musste viel mehr Wert auf den Spielflow und eine einfache Steuerung gelegt werden, um das Game benutzerfreundlich zu gestalten. Der Zeitaufwand wurde von Tamara anfänglich auch unterschätzt, was bei ihr gegen Ende Stress aufbaute. Insgesamt war es jedoch eine wertvolle Erfahrung, die Tamara fachlich weiterbrachte.
Zudem konnte sie sich, durch die Einarbeitung in Adobe Illustrator und das Prototyping in Adobe XD, im Bereich Gestaltung deutlich verbessern und erweiterte durch die Zusammenarbeit mit Unity ihre Kenntnisse.
## 8. Mögliche Weiterarbeit
Dadurch, dass wir noch einige Ideen haben, wie das Spiel verbessert werden könnte, könnten wir und unter Vorbehalt vorstellen, das Spiel tatsächlich weiterzuführen. Denkbar wäre der Einbau von ...
> TODO: Alex/Oliva ->Korrektur lesen des abschnittes
Gegenständen die auf dem Boden liegen, welche man einsammeln kann, sowie mehr Interaktionsmöglichkeiten mit der Umwelt. Außerdem würde sich ein Leaderboard für den Multiplayer gut machen, in welchem man die Erledigten Gegner, genutzten Charactere, sowie den Spielernamen hinterlegen könnte. Desweiter wären noch mehr Bug Fixes nötig, welche Hauptsächlich den Multiplayer betreffen, da es dort in manchen Fällen zu Desinkronisation von Variablen kommt.
Dadurch, dass wir noch einige Ideen haben, wie das Spiel verbessert werden könnte, könnten wir und unter Vorbehalt vorstellen, das Spiel tatsächlich weiterzuführen. Denkbar wäre der Einbau von Gegenständen, die auf dem Boden liegen, welche man einsammeln kann, sowie mehr Interaktionsmöglichkeiten mit der Umwelt. Außerdem würde sich ein Leaderboard für den Multiplayer gut machen, in welchem man die erledigten Gegner, genutzten Charaktere, sowie den Spielernamen hinterlegen könnte. Desweiter wären noch mehr Bug Fixes nötig, welche hauptsächlich den Multiplayermode betreffen, da es dort in manchen Fällen zu Desinkronisation von Variablen kommt.
Aus Sicht der User Experience, wären weitere Nutzertests, besonders die des fertigen Spieles der nächsten Schritt. Dabei könnte verstärkt der Fokus auf die Menüführung und Steuerung gelegt werden, da dies zentrale Elemente des Spiels sind. Besonders wenn noch anderen Features und somit auch Menüpunkte wie z.B. Highscore Board oder die Heldeninfo dazu kommen, ist es wichtig den Navigationsflow möglichst intuitiv und einfach zu halten, um unserer Zielgruppe gerecht zu werden. Auch ist ein Eye-Tracking Test sehr gut denkbar, um herauszufinden welche Bereiche, Farben oder Symbole stark und welche weniger stark wahrgenommen werden. Daraus lassen sich dann auch wichtige Erkenntnisse zur Lesbarkeit, Auswahl und Verständlichkeit von Icons und der Schrift finden.
