¶ 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. Fracht spawnt in kürzer werdenden Abständen auf den Lanes; in zufälliger Position und Ausrichtung und von zufälliger Art. Gegen Ende muss man schnell reagieren und hektisch verteilen. Es gibt jedoch eine gewisse Stabilisierungshilfe, die das Balancieren erleichtert und etwas vergebender mit hoch gestapelten Türmen dealt.
¶ 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.
Die Kiste 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/Western-Setting mit schiefen Gebäuden und Kakteen und einem Sand-Nebel aus dem die Fracht und bald die Gebäude im Zielgebiet auftauchen. Wenn man ankommt, wird die Fracht gezählt und am Post-Posten 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, habe wir neue Formen
eingeführt (L Boxen, dreieckige Käsestücke, ovale Fischen und Kaktusfeigen). Nach Playtesting stelle 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 langsamer Objekte 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 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 in den Spielern 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 Boxen wegsprengt), aber aus Overscoping Gründen wurde dies wieder gestrichen.
Eine längere Debatte erfolgte um die Länge des Spieles 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 punishing, 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 begrenzt lange, dass Zeit/Strecke statt Verlust an Leben das Spielende bedingt.
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” (also wie viel Wackeln und fallen Kisten) gegen Planung (wie genau halten sie in ihrer Position) iteriert, bis die Spielende zufrieden waren.
Spieler haben sich am Ende mehr Belohnung gewünscht, also haben wir besonders unser Ende juicy machen wollen, einmal durch das Einbauen eines auf Distanz visuell sichtbares Zieles (der Poststation) und durch das Abgeben der Boxen und die Bezahlung in Karotten.
¶ Fortschritt durch Screenshots der Management Tools
Management auf Miro, mit Scrum und einer Timeline mit allen Milestones
Initiell simple Planung mit Backlog, Progress und Complete. Zusätzlich Ideenstapel. Bei weiterem Fortschritt des Projekts Update des Planungssystems zu einer integration mit Moscow System
¶ Lessions Learned von jeder Person
¶ Link zu Itch.io und Newgrounds
