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.
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.
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:
Tamara erstellte zu Projektbeginn eine Informations- und Navigationsarchitektur [2], um den Flow des Spiels festzuhalten. Ersteres dient zur Identifikation und Definition von Seiten Inhalt bzw. Funktionalität. Im Laufe der Entwicklung merkte man aber relativ schnell, dass nicht alle Funktionen darin in der vorgegebenen Zeit zu implementieren waren. Trotzdem war es sehr hilfreich einen Überblick über mögliche Features zu haben, die in Zukunft noch implementiert werden könnten. Mithilfe der Navigationsstruktur war es Julian und Tamara möglich Fragen zur Nutzungspriorität, Anordnung und das allgemein verwendete Muster festzulegen, um Inhalte am besten finden zu können.
...
...
@@ -123,7 +123,7 @@ Um den allgemeinen Überblick über wichtige Ereignisse und die Stage zu behalte
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.
#### 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.
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 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.
