¶ GAME INFO
¶ Kurzbeschreibung
Where Wolf ist ein One-Button-Reaktions/Rätsel-Spiel, bei dem man Gatter im richtigen Augenblick öffnen und schließen muss, um Schafe in die Scheune zu lotsen und Werwolf-Schafe, die sich unter die Herde gemischt haben, verscheuchen.
¶ Links
¶ Spielprinzip
Bei Where Wolf versuchen Schafe automatisch über mehrere Weiden in die Scheune zu gelangen, die jedoch mit Gattern voneinander getrennt sind. Es ist die Aufgabe des Spielers, die Gatter durch Betätigen der Leertaste im richtigen Augenblick zu öffnen/schließen, um die Schafe hindurchzulassen, ohne sie dabei zu treffen, da sie ansonste zurückgestoßen werden.
Unter den Schafen mischen sich gelegentlich Werwolfschafe, die ebenfalls versuchen, in die Scheune zu gelangen und Schafe fressen bzw. in weitere Werwolfschafe verwandeln, wenn sie zu lange mit Schafen auf einer der Weiden eingesperrt sind.
Manchmal kann es auch geschehen, dass Werwolfschafe durch die Lücken im Zaun auf die Weiden gelangen. Vom Spieler ist daher Aufmerksamkeit gefordert, alle Weiden im Blick zu behalten.
Werwolfschafe können vertrieben werden, indem man sie im richtigen Moment mit den Gattern trifft, was über die Zeit immer schwieriger wird, da Schafe und Werwolfschafe sich zunehmend schneller bewegen.
Ziel des Spiels ist es, über eine möglichst lange Zeit möglichst viele Schafe in die Scheune zu lotsen, wobei mehr Schafe auf einmal einen größeren Punktebonus geben. Das Spiel ist vorbei, sobald ein Werwolfschaf in die Scheune gelangt.
¶ Core Mechanic
Core Mechanic ist das Öffnen und Schließen der Gatter mit Hilfe der Leertaste. Alle Gatter werden gleichzeitig durch das Drücken der Taste betätigt, wobei einige Gatter sich schließen, während andere sich öffnen.
¶ Game Loop
¶ SCREENSHOTS
|
|
¶ TEAM
|
Jacob Zuber |
Nadine Friede |
Eliese Brock |
Vivica Priem |
|---|---|---|---|
|
Programming |
Art |
Art |
Soundeffects |
 |
 |
 |
 |
+ Zusätzliche Unterstützung von Moritz, der für den Soundtrack gesorgt hat.
¶ PROJEKTMANAGEMENT
¶ MoSCow-Analyse
Die hier abgebildete MoSCoW-Analyse bezieht sich auf die erste Version des Spiels, bei der vor Anbruch der Nacht Schafe noch aus der Scheune herausgebracht werden müssen, während man Wölfe in der Scheune eingesperrt lassen sollte.
Für die aktuellste Version des Spiels sähe die MoSCoW-Analyse so aus:
| Must Have |
|
| Should Have |
|
| Could Have |
|
| Won't Have |
|
¶
¶ Tools
|
|
|
|
|
|
|
|
¶ Organisation
- Organisation geschah hauptsächlich über Discord und Miro.
- Alle drei Tage gab es Jour Fixe, in der Teammitglieder in einem Discordchannel ihren Fortschritt auflisten konnten und was sie als nächstes vorhaben.
- Mindestens einmal in der Woche (meist aber öfter) wurde sich im Team (vor Ort und/oder online) zusammengesetzt, um weitere Vorgehen zu besprechen.
- Discord wurde außerdem zur Übersicht wichtiger Assets und Dokumente genutzt.
- Miro wurde für Inspirationsfindung und der Organisation von Aufgaben sowie Besprechung von Feedback verwendet.
¶ Ideenfindung
¶ Concept Art, Inspirationen und Moodboard
¶ Kanban
¶ ENTWICKLUNG
¶ Prototyp 1
- Erster Prototyp in der Handyapp “Game Creator” gebaut, um die Idee, Schafe aus einer Scheune herauszubekommen.
- Auf Grund der Limitationen von Game Creator wurde das Spiel in Unity nachgebaut.
|
|
- Zu diesem Zeitpunkt konnten Wölfe noch nicht vertrieben werden und das Ziel war es, Schafe aus der Scheune auf die Weide zu bekommen, ohne die Wölfe rauszulassen.
- Hier kristallisierte sich eine Grundfrage heraus: Sollte man die Schafe von innen (Scheune) nach außen (Weide) oder von außen nach innen lotsen?
- Gameplaytechnisch war es angenehmer und intuitiver, die Schafe vom inneren Bereich (der Scheune) nach außen zu bekommen, da die “Story” des Spiels jedoch sein sollte, seine Schafe von den Wölfen zu beschützen und zu trennen, wäre es logischer, die Schafe in die Scheune zu lotsen. Letzteres würde eine Menge Arbeit nach der Frage des Spielsziels abnehmen, da es fast selsbterklärend ist, dass man seine Schafe natürlich besser beschützen kann, wenn man sie sicher in die Scheune lockt.
¶ Ideenchaos
Während dieser Phase der Entwicklung des Spiels sind im Team viele Ideen und Änderungswünsche aufgekommen. So viele, dass irgendwann der Überblick darüber verloren wurde, was wie ins Spiel implementiert werden sollte und was nur potentielle oder alternative Ideen waren.
Um Übersicht über die herumschwebenden Ideen zu bekommen und Fokus in die Entwicklung des Spiels zu bringen wurden daher sämtliche Ideen auf Notizzetteln in Miro niedergeschrieben, sortiert nach Themen bzw. Bereichen, die davon betroffen sind:
Dann wurde im Team nach und nach jede Spalte (Level, Ziel, Schafe, …) besprochen. Ideen, die umgesetzt werden sollten, wurden behalten. Ideen, die nicht umgesetzt werden sollten (weil sie z.B. zu aufwändig oder mit anderen Ideen nicht kompatibel sind), werden in einen figurativen “Müllcontainer” über dem Bereich gesteckt.
Am Ende ergab sich daraus eine übersichtliche Liste an Features, die im Spiel implementiert werden sollten und die alle Teammitgleider auf den gleichen Nenner gebracht hat:
¶ Prototyp 2
- Für den zweiten Prototyp wurde das Spiel basierend auf dem oben dargestellten Miroboard überarbeitet.
- Schafe durchwandern nun mehrere Weiden und müssen am Ende in eine Scheune oben rechts (in diesem Build visuell noch nicht implementiert) gebracht werden.
- Das Spiel wurde geplaytested und sämtliches Feedback wurde auf Miro aufbereitet und sortiert nach Themengebiet festgehalten:
- Die einzelnen Punkte wurden besprochen und dann farblich gekennzeichnet, ähnlich wie auch schon bei der MoSCoW-Analyse.
- Grün = wird bzw. wurde umgesetzt/verbessert
- Gelb = nur umsetzen, wenn noch Zeit
- Orange = wird in Betracht gezogen, vermutlich wird die Zeit aber nicht ausreichen
- Rot = wird nicht umgesetzt
¶ Prototyp 3
- Feedback des vorherigen Playtests wurde dementsprechend umgesetzt und das Spiel weiter gepolished.
- Hierfür wurden sämtliche Punkte zunächst in dringende Fixes (rechte Abbildung, oben links) und zusätzliche Features zum weiteren Polish des Spiels eingeteilt (rechte Abbildung, unten links)
- Nach weiteren Playtests wurden an diesen Änderungen noch einige letzte Fixes, besonders was den Game-Over-Screen angeht, getätigt.
¶ LEARNINGS
Vivica Priem
- FMOD ist mega easy und geht gut Hand-in-Hand mit Unity
- Je breiter aufgestellt, desto besser, weil dann nicht einer die A-Karte hat, sich mit den nervigen Sachen auseinanderzusetzen
- offene Kommunikation ftw
- Enthusiasmus kann voll geile Sachen hervorbringen
Jacob Zuber
- Aufgaben im Team müssen klar verteilt werden, damit man gut parallel arbeiten kann.
- Ein klares Projektziel (Core Experience/Core Mechanic) zu definieren ist wichtig und dieses sollte bei jedem weiteren neuen Feature bedacht werden.
- Webgames zu machen ist nervig und man sollte sich nur im äußersten Fall darauf einlassen.
- Förderungen sollte man am besten nicht mit fertigen Konzepten gegenübertreten.
Nadine Friede
- Entscheidungen treffen und diese auch durchzusetzen, selbst wenn dies bedeutet, gute Ideen zurücklassen zu müssen ist schwer.
- Gute Organisation hilft ungemein dabei, Ordnung in Ideenchaos zu bekommen (und das alles auf Notes zu verteilen und verschieben zu können macht es so viel angenehmer, mit Feedback und Ideen zu arbeiten).
- Jour Fixe helfen ziemlich gut gegen das Prokrastinieren.
- Zu viel Diskussion/Austausch kann auch hinderlich sein, wenn am Ende keine klaren Entscheidungen getroffen werden.
Eliese Brock
- Mehr mit dem Team Kommunizieren, auf welchem stand man gerade ist.
- Spielprinzip vorher viel mehr testen, bevor darauf Committed wird.
- Arbeitsverteilung vor Projektstart besser mit den anderen absprechen.
- Nicht den chat mit Ideen vollspammen, das überfordert schnell und lenkt vom eigentlichen ziel ab.
- Kleiner scopen. VIEL KLEINER SCOPEN.