¶ Dokumentation von WONKEY DONKEY
einem 2.5D Lane-Runner Spiel übers Balancieren von unterschiedlich stapelbarer Fracht auf einem wackeligen Eselskarren.
¶
von Team Jelly Fox mit Calvin Fehl, Christian Willner, Julia Büttner und Caroline Römer
¶
¶ Ziele
Der Spieler soll möglichst viele Kisten und Gegenstände sammeln und stapeln, ohne dass die Fracht vorm Erreichen des Ziels herunterfällt.
¶ Kernmechaniken
Durch swipen kann man sich auf Lanes bewegen. Man sammelt dabei unterschiedlich geformte Fracht ein und stapelt diese auf seiner Ladefläche. Je nach relativer Position zum Einsammeln (bestimmt und planbar anhand der Lanes) kann man die Position auf dem immer wachsenden Stapel bestimmen. Neue Fracht fällt dabei Tetris-ähnlich von oben, landet jedoch als Physik Objekt und kann verrutschen und herunterfallen. Die Fracht spawnt in kürzer werdenden Abständen auf den Lanes in randomisierter Position und Ausrichtung, so muss man gegen Ende schnell reagieren und hektisch verteilen.
¶ Komplettbeschreibung
Ein 2.5D Lane-Runner im Handy Format, in dem man einen Postmann spielt, der Kisten, Kaktusfeigen, Käse und Fische einsammelt, auf einer kleinen und beim Steuern wackelnden Ladefläche sortieren muss, um möglichst viel davon nach einer gewissen Zeit am Ziel - dem Postamt - abzugeben und in Karotten einzutauschen. Dabei sind die Menge Kisten, ihre teils unvorteilhaften Formen und die sich ändernde Schräglage des Transportgefährts Herausforderungen, die durch geschicktes Sortieren und eventuelles Gegensteuern ausgehobelt werden können.
Der Wagen wird von einem charismatischen Esel (dem Funkey Donkey) gezogen und man sieht den Reiter mit einer Karotte steuern, während der Wagen die Spur wechselt. Das Setting ist ein Wüsten- und Western-Setting mit schiefen Gebäuden und Kakteen und einem Sandnebel aus dem die Fracht und bald die Gebäude im Zielgebiet auftauchen. Wenn man ankommt, wird die Fracht gezählt und an einer Poststation abgeladen, bevor man dankenderweise mit Karotten belohnt wird.
Im Kontext "One-Button Game" interpretieren wir One Button als Drücken und Swipen, unsere Steuerung basiert auf links und rechts swipen, was ein intuitives Handy-Bedienen mit der nötigen Präzision für zielgerichtetes Stapeln ermöglichen soll.
¶ Kritikpunkte Tester:innen und ChangeLog
Das Grundkonzept und die Steuerung waren spätestens nach einer Runde allen Spielern klar, selbst denen, die das Tutorial nicht gelesen haben.
In der ersten Iteration war das Scoring System abhängig von der Anzahl der gesammelten Kisten, der verlorenen Kisten und vor allem der Höhe der gestapelten Ware. Diese Meta wurde sehr schnell von Spielenden erkennt und hat dazu geführt, dass nur noch auf Höhe gestapelt wurde. Da zu diesem Zeitpunkt nur rechteckige Boxen im Spiel waren, war dies sehr einfach und führte zu einem niedrigen Schwierigkeitsgrad und kaum Replayability. Um das Spiel schwieriger zu machen und die "Mittelstapelmeta" zu verhindern, haben wir neue Formen eingeführt (L Boxen, dreieckige Käsestücke, ovalen Fischen und Kaktusfeigen). Nach Playtesting stellte sich das Spiel erfolgreich als herausfordernder dar und man konnte nicht mehr einfach nur einen hohen Turm in der Mitte bauen. Zusätzlich haben wir eine kleine Difficulty Progression eingebaut, indem am Anfang Objekte langsamer spawnen und am Ende hin sehr schnell.
Initiell war der Eselswagen mit einem Rad geplant, und das korrekte Platzieren der Objekte auf der Wagenfläche sollte zu einer Neigung der Fläche und Herunterfallen der Waren führen, falls falsch balanciert gestapelt würde. Dies wurde getestet, war allerdings zu unvorhersehbar und schwer planbar, was den Planungserfolg aus dem Gameplay nimmt und zu Frustration bei den Spielenden geführt hat. Nach Testing wurde dieses Feature also gestrichen.
Um mehr Replayability und Schwierigkeit zu bieten, wollten wir gerne noch ein Questsystem einbauen (zB "Sammel diese Runde nur Fische"), und auch Objekte mit negativen Effekten einbauen (zB Dynamit, dass die Boxen wegsprengt), aber aus Overscoping Gründen wurde dies wieder gestrichen.
Eine längere Debatte erfolgte um die Länge des Spiels zu bestimmen: Erst war das Spiel als Endlessrunner geplant, mit einer gewissen Anzahl an Leben, die man hat (verloren wenn Kisten fallen), deren Verlust die Endcondition darstellt. Allerdings fielen oft mehrere Kisten auf einmal und es war sehr frustrierend, einen großen Turm zu stapeln und nach einem Fehler direkt zu sterben. Außerdem konnte man bei sehr vielen Kisten und hohen Stapeln irgendwann nicht mehr die Fahrbahn sehen, deshalb entschieden wir uns, das Spiel lieber schwerer zu machen und dafür dafür zeitlich zu begrenzen, sodass Zeit bzw. Strecke statt des Verlusts von Leben das Spielende bestimmt.
Allgemein haben viele Spielende die Möglichkeit perfekt zu Planen und genaue Stapel zu bauen, gegen das Hin- und Herwackeln der Kisten kommentiert. Wir haben durch Testing die richtige Menge an "wonkey" (wie stark Kisten wackeln und fallen) gegen Planung (wie genau halten sie in ihrer Position) iteriert, bis die Spielenden zufrieden waren.
Spieler haben sich am Ende mehr Belohnung gewünscht, also haben wir besonders unser Ende belohnender gestalten wollen, einmal durch das Einbauen eines aus der Distanz visuell sichtbaren Ziels (der Poststation) und durch das Abgeben der Boxen und die Bezahlung in Karotten.
¶ Fortschritt durch Screenshots der Management Tools
Um unser Projekt zu planen, haben wir ein Kanban Board auf Miro genutzt. Zu Beginn gab es ein Kanban Board mit den Punkten "Not Started", "In Progress" und "Complete", aber dies funktionierte nur für den Start des Projekts und um Miro allgemein als Planungstool zu testen, als das Projekt komplexer wurde, reichten diese Punkte jedoch nicht mehr aus.. Wir haben für das weitere Projekt ein neues Kanban Board erstellt, wo wir alle besprochenen Ideen, Features und To-Dos im Backlog (genannt "Wunschbrunnen") gesammelt haben und diese nach MoSCoW bewertet haben. Alle Must Haves wurden Personen zugeteilt und während einwöchiger Sprints wurden die wichtigsten Must Haves abgearbeitet. Dann wurden die Must Tasks in "Progress" und "Complete" gezogen, je nach Bearbeitungsstand. Mit den wöchentlichen Sprints konnten wir gut unseren Fortschritt sehen, den Scope an unser Arbeitstempo anpassen und schnell Lücken in der Produktionspipeline identifizieren. Außerdem mussten wir uns so wöchentlich besprechen, konnten Feedback und Ideen austauschen und sehen, wie der Stand aller Teammitglieder war. Da das große Kanban Board sehr gut für uns funktioniert hat, als zentraler Planungstool für unser Projekt, haben wir noch die Spalten "User Testing" und "BUGS!" ergänzt. In "User Testing" haben wir alles Feedback während der Playtests festgehalten, konnten uns so im Nachhinein gut besprechen und aus dem Input neue Features und Tasks für unser Backlog ableiten. In "BUGS!" wurden Bugs festgehalten, die am auffälligsten in der Planung sein sollten und auch mit der höchsten Priorität gefixt werden sollten.
Zusätzlich haben wir zu Beginn des Projekts eine Timeline erstellt, auf der alle Abgaben, Termine und Milestones festgehalten wurden. So konnten wir auf einen Blick sehen, wie viel Zeit wir noch für das Projekt haben und wann gewisse Features stehen müssen.
Insgesamt hat dieses Planungskonzept für uns sehr gut funktioniert, wir hatten immer den Überblick über unseren Arbeitsstand und den unserer Teammitglieder. Durch das gemeinsame Erstellen des Backlogs, gemeinsames Durchgehen von User Feedback und sortieren nach MoSCoW, waren wir alle auf demselben Stand bezüglich der Prioritäten und darüber, in welche Richtung sich unser Projekt entwickeln sollte. Allerdings kostete dies natürlich auch viel Zeit, und der Kompromiss zwischen "alles gemeinsam besprechen" und "möglichst viel arbeiten statt reden", war nicht immer einfach zu finden.
¶
¶ Lessions Learned von jeder Person
Julia:
Im Bereich Planung habe ich gelernt, wie wichtig die richtige Balance zwischen gemeinsamer Absprache und tatsächlicher Arbeitszeit ist. Sich regelmäßig als Team zusammenzusetzen und Ideen, Probleme oder Prioritäten zu besprechen, war sehr hilfreich, um alle auf denselben Stand zu bringen und Missverständnisse zu vermeiden. Gleichzeitig habe ich aber auch gemerkt, dass man schnell in lange Diskussionen abrutschen kann und dann weniger Zeit für die eigentliche Entwicklung bleibt. Klare Verantwortlichkeiten und Aufgabenbereiche waren deshalb besonders wichtig. Insgesamt habe ich die Erfahrung gemacht, dass gemeinsames Arbeiten und gegenseitiger Austausch unglaublich hilfreich sind. Außerdem habe ich gelernt, reflektiert mit User-Feedback umzugehen. Während Playtests bekommt man viele unterschiedliche Meinungen und Verbesserungsvorschläge, die sich teilweise sogar widersprechen. Deshalb sollte man Feedback nicht einfach direkt umsetzen, sondern erst durch weiteres Testing überprüfen und gegen die eigene Vision des Projekts abwägen. Bei unserem Spiel war beispielsweise die Frage wichtig, wie viel "wonkey" Physik wir zulassen wollen und wie planbar das Stapeln trotzdem bleiben muss. Durch mehrere Iterationen und wiederholtes Testen konnten wir hier einen guten Mittelweg finden.
Bei der Produktion meiner Assets habe ich vor allem gelernt, Assets und Ideen möglichst früh im Spiel zu testen. Durch den relativ kurzen Entwicklungszeitraum hatte ich oft nicht die Möglichkeit, sehr viel Zeit in Konzeption oder detaillierte Planung zu investieren. Stattdessen bin ich häufig nach dem Prinzip "erst mal machen und schauen, wie es funktioniert" vorgegangen. Überraschenderweise hat das in diesem Projekt sehr gut funktioniert. Viele Dinge zeigen ihre tatsächlichen Stärken oder Schwächen erst, wenn sie im Spiel eingebaut wurden. Außerdem habe ich gemerkt, dass Blockout-Assets beziehungsweise relativ undetaillierte Assets manchmal ausreichend sind, besonders bei Objekten, die später nicht stark im Fokus des Spielers stehen. Mehrfach habe ich festgestellt, dass sich eine aufwendige Ausarbeitung bestimmter Assets gar nicht gelohnt hätte, weil sie im fertigen Spiel nur kurz sichtbar waren. Eine weitere wichtige Erkenntnis war, dass es am Ende fast immer mehr Aufgaben gibt als ursprünglich erwartet. Es ist deutlich sinnvoller, zunächst alle wichtigen Features in einer funktionierenden Version im Spiel zu haben, auch wenn sie noch nicht final oder besonders schön umgesetzt sind. Sobald alle Kernfunktionen vorhanden sind, kann man gezielt die Bereiche polishen, die für das Spielerlebnis wichtig sind oder besonders stark auffallen.
Calvin:
Ähnlich wie Julia habe ich gelernt, realistisch mit dem eigenen Zeit-Budget zu sein, auch wenn man es am liebsten großherzig groß schätzt, um seiner Motivation auf das Projekt Ausdruck zu verleihen. Nämlich und zudem haben mich während der Produktion private Themen und Verantwortungen vermehrt vom Arbeiten am Projekt abgehalten und ich habe zu spät eingesehen, dass ich das Studium - und damit das Projekt - eher Halbzeit angehen sollte, bzw muss. Erst als Caro uns den Realitäts-Check gab, dass sie unser Team zu verlassen beabsichtigte, setzte ich mich ernsthaft mit diesem Miss-Match aus "Geben Wollen" und "Geben Können" auseinander; in Zukunft sollte ich etwas nachsichtiger mit mir (und vergebender mit meinem Selbstanspruch) sein und rechtzeitig so mit meinem Team kommunizieren, dass ich nichts verspreche, was ich am Ende nicht halten kann.
Zudem war ich als Game Designer etwas untergegangen, als unsere Power-Programmierer loslegten und Prototypen raushauten, ohne dass ich hinterherkam, auf eigene Faust neue Mechanics zu testen, Werte zu Tweaken oder ausführlich User-zu-Testen. Erst, als wir in der Uni Playtesting Session hatten, konnte ich Feedback sammeln und in eine Liste an To-Dos verwandeln, ich beabstichtigte ursprünglich, mehr Teil an Idee und System-Design zu haben, aber da eben mein Zeit-Budget nicht ausreichte (und, da wohl die Kommunikation auch etwas unklar seitens der Rollenverteilung war) sah ich mich mehr und mehr zu anderen Aufgaben shiften: etwa prozedurale Animationen und Sounds, sowie eine Liste an anfallenden sonstigen. Seit wir zu dritt sind, sind wir etwas gezwungener, Rollen sehr klar zu definieren und haben uns auch rhythmisch etwas besser eingespielt. So fällt bisher keiner mehr zurück, wo andere galoppieren können und alle Fracht bleibt auf dem Wagen, seit dieser ein bisschen gemütlicher trabt.
Außerdem habe ich Hard-Skills bezüglich Soundproduktion und -Implementation (v.a. in Fmod) und weiterhin Übung in C# und Unity gesammelt.
Insgesamt hat das Projekt sehr gut funktioniert und wir haben als Team Wunder vollbracht. Ich wünschte, wir hätten öfter in Person zusammengesessen, aber es hat termin- und zeittechnisch leider selten funktioniert (mit drei Arbeitenden im Team). Denn die Male, als wir das getan hatten, haben wir Quantensprünge im Stand des Projekts gemacht und ich war jedes Mal danach Stolz wie ein Esel, was für ein starkes und fähiges Team wir doch haben.
Christian:
Ähnlich wie bei den anderen habe ich viel über das Zusammenwirken im Team gelernt. Insbesondere dass es okay ist, zu sagen, dass man etwas nicht schaffen wird. Das war anfangs schwer, aber es hilft dem Team mehr als überzogene Erwartungen, die danach nicht haltbar sind. Es ist sehr wichtig zu sehen, dass alle das gleiche Ziel haben. Dabei ist nicht nur das Was und Wie zu berücksichtigen, sondern auch das Wie viel. Ab wann ist etwas "gut genug"? Diese Kommunikation der "Definition of Done" war super wichtig, als wir nur noch zu dritt waren und unsere Arbeit neu koordiniert werden musste.
Caro:
Während des Projekts habe ich vor allem gelernt, wie wichtig eine offene Kommunikation und eine klare Abstimmung im Team sind. Gerade wenn unterschiedliche Ideen oder Vorstellungen aufeinandertreffen, ist es wichtig, diese früh anzusprechen und gemeinsam Entscheidungen zu treffen. Außerdem habe ich gemerkt, dass Kompromisse zwar manchmal Zeit kosten, langfristig aber zu besseren Ergebnissen führen können, wenn alle Teammitglieder hinter den getroffenen Entscheidungen stehen.
Gleichzeitig habe ich gelernt, wie wichtig es ist, Spielideen möglichst früh praktisch auszuprobieren, anstatt sich zu lange auf die eigenen Annahmen zu verlassen. Viele Entscheidungen konnten erst durch Prototypen und Playtests sinnvoll bewertet werden. So merkt man manchmal auch erst durch die Playtests, dass sich das Spielerlebnis eventuell doch von unseren ursprünglichen Erwartungen unterscheidet, oder auch manchmal tatsächlich sich mit der eigenen Annahme überschneidet. Dadurch habe ich gelernt, dass gutes Game Design ein iterativer Prozess ist und regelmäßiges Feedback von Spielenden unverzichtbar ist.
¶ Links
