Im Rahmen der Module „119400 Projekt“, "119450 Interdisziplinäres Projekt" sowie "113468 Projektarbeit" haben wir uns vorgenommen ein Spiel zu programmieren. Das Spiel ?? und online mit mehreren Spielern spielbar sein. Dabei wollten wir die Steuerung und Aufbau des Spieles durch Prototyping und User Tests validieren.
Im Rahmen der Module „119400 Projekt“, "119450 Interdisziplinäres Projekt" sowie "113468 Projektarbeit" haben wir uns vorgenommen ein Spiel zu programmieren. Unsere Projekt ist ein rogue-like coop Spiel und sollte online mit mehreren Spielern spielbar sein. Dabei wollten wir die Steuerung und Aufbau des Spieles durch Prototyping und User Tests validieren.
## 2. Verwendete Software
## 2. Verwendete Software
Als Game-Engine wurde Unity (Version: 2019.2.10f1) gewählt, die Grafiken wurden in Adobe- Photoshop, Adobe-Illustrator, Affinity Designer und Substance Painter erstellt. Für das Prototyping wurde Stift und Papier und Adobe XD verwendet.
Als Game-Engine wurde Unity (Version: 2019.2.10f1) gewählt, die Grafiken wurden in Adobe- Photoshop, Adobe-Illustrator, Affinity Designer und Substance Painter erstellt. Für das Prototyping wurde Stift und Papier und Adobe XD verwendet.
## 3. Team & Verantwortlichkeiten
## 3. Team & Verantwortlichkeiten
Die Betreuung des Projekts erfolgt über Prof. Walter Kriha. Die Anmeldung und Benotung war innerhalb des Teams dabei wie aufgelistet verteilt.
Die Betreuung des Projekts erfolgt über Prof. Walter Kriha. Die Anmeldung und Benotung war innerhalb des Teams dabei wie aufgelistet verteilt:
@@ -31,16 +31,18 @@ Die Betreuung des Projekts erfolgt über Prof. Walter Kriha. Die Anmeldung und B
...
@@ -31,16 +31,18 @@ Die Betreuung des Projekts erfolgt über Prof. Walter Kriha. Die Anmeldung und B
## 5.1 Vorarbeit
## 5.1 Vorarbeit
## 5.2 Arbeitsphase
## 5.2 Arbeitsphase
Im Folgenden wird die Arbeit und Erkenntnisse der einzelnen Departments vorgestellt. Dabei wird auch auf aufgetretene Problematiken, sowie die Lösung deren eingegangen.
Um den allgemeinen Überblick über wichtige Ereignisse und die Stage zu behalten, wurde ein groben Zeitplan erstellt und die wichtigsten Daten eingetragen [Bild Zeitplan GDrive]. 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 Milstones organisiert.
Um den allgemeinen Überblick über wichtige Ereignisse und die Stage zu behalten, wurde ein groben Zeitplan erstellt und die wichtigsten Daten eingetragen [Bild Zeitplan GDrive]. 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).
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 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. Für unser Projekt 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. Als Milestones 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. Für unser Projekt 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 keine Schwierigkeit dar. 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. 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 Wiki:
#### Git Wiki:
Alle (Teil-)Dokumentationen und Erkenntnisse über z.B. das User Testing wurden über das Git Wiki festgehalten. Dazu wird Markdown als allgemeingültige Syntax verwendet.
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.
#### Teamkommunikation:
#### Teamkommunikation:
Die interne Kommunikation wurde komplett über Whatsapp abgehandelt. War zuerst die Idee "Slack" zum Austausch im Team zu verwenden, wurde schnell klar, dass sich Whatsapp dafür besser eignete. Grund dafür war die höhere Präsenz und Regelmäßigkeit auf der Plattform. Wir haben uns zudem jede 2. Woche als ganzes Team remote oder persönlich für wichtige Absprachen getroffen. Meetings innerhalb der verschiedenen Subteams fanden häufiger statt und wurden selbst organisiert.
Die interne Kommunikation wurde komplett über Whatsapp abgehandelt. War zuerst die Idee "Slack" zum Austausch im Team zu verwenden, wurde schnell klar, dass sich WhatsApp dafür besser eignete. Grund dafür war die höhere Präsenz und Regelmäßigkeit auf der Plattform. Slack wurde vom Team hingegen kaum akzeptiert und stellte dabei somit keine praktikable Alternative dar. Wir haben uns zudem jede 2. Woche als ganzes Team remote oder persönlich für wichtige Absprachen getroffen, was sehr gut funktionierte. Die Synchronisation zwischen den einzelnen Departments erwies sich als sehr wichtig, um an einem gemeinsamen Ziel arbeiten zu können. Besonders die Absprache zwischen Design und UX war von Bedeutung, um einzelne Komponenten in das Prototyping rechtzeitig einbauen zu können. Meetings innerhalb der verschiedenen Subteams fanden häufiger statt und wurden selbst organisiert.
#### GDrive Datenablage:
#### 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 oder das UI Kit.
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.
## 6. Medianight
## 6. Medianight
Zur Präsentation an der Medianight erstellten wir ein Werbeplakat und stellten unser Spiel vor. Durch die Fertigstellung des Projekts, war es möglich unser Spiel direkt an der Media Night ausprobieren zu können. Es fand durchweg postiven Anklang und begeisterte besonders durch die comichafte Grafik.
Zur Präsentation an der Medianight erstellten wir ein Werbeplakat und stellten unser Spiel vor. 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.
