¶ Team
Alex Stolovnik
Komponist
Eric-Iv Staici
Tech-Art
Johann Teßmer
Programmer
Linda Adelmann
2D/3D Artist
Luca Merten
Narrative & Level Designer
¶ Konzept
¶ Kernmechanik
Die Mechanik, auf der das ganze Spiel basiert, ist die “One-Button“-Mechanik. Eine frei wählbare Taste (außer Spezial-/Systemtasten) löst eine formabhängige Aktion aus:
JumpDash
Tippe auf den Boden, um zu springen, tippe in der Luft, um zu dashen - ein Sprint pro Sprung. Kette sie über die Lücken hinweg aneinander.
Gravity
Tippe auf Schwerkraft umkehren - nach oben fallen, nach unten fallen. Halte die Finger gedrückt, um stärker zu ziehen. Navigiere durch den Spalt zwischen Decke und Boden.
ZipZap
Keine Schwerkraft - reiner 45°-Flug. Tippe auf snap diagonal, nach oben oder unten, und schlängle dich im Zickzack durch die Schienen.
Mit den Schaltern kannst du mitten im Lauf zwischen den Modi wechseln. Passe dich an - oder werde Teil der Kulisse.
¶ Ziel
Der Spieler wird anhand von zwei Aspekten bewertet: Distanz und gesammelte Coins. Diese erhöhen die Punktzahl des Spielers. Ziel ist es also, möglichst lange zu überleben und eine hohe Punktzahl aufzubauen.
¶ Game Loop
Der Spieler wird in ein Level geworfen, erkennt die kommenden Hindernisse und weicht ihnen aus. Nach Möglichkeit kann der Spieler versuchen, Coins zu sammeln, um seine Punktzahl zu erhöhen.Diese sind meist nah an Hindernissen und stellen ein Risk-Reward-System dar. Besteht er ein Level, folgt direkt das nächste. Beim Wechseln der Level kann der Spieler in eine neue Form umgewandelt werden.
¶ Visual Effects & Juice
¶ Runtime Shader
Die Hindernis- und Objekt-Optik läuft komplett zur Laufzeit und reagiert live auf den Spielmodus (JumpDash, Gravity, ZipZap). Die drei Varianten entstehen aus derselben Shader-Logik, nur mit eigener Farbe und „Energie". Das hält alles konsistent und mit wenig Aufwand editable.
Hindernisse (Fill-Effekt): Der Shader nimmt die Silhouette des Sprites und rechnet die Warn-Optik pro Bildpunkt darauf: einen leuchtenden Rand, eine wachsende Füllung und eine „Energie" im Inneren, die sich bewegt. Je nach Modus animiert die Energie anders: “Glut” = einzelne Funken driften nach oben, “Sog” = langsame Spiralarme mit dunklem Zentrum, “Strom” = dünne Reihen flackern quer durch den Körper.
Sobald ein Hindernis ins Bild kommt, materialisiert sich zuerst der Rand, dann beginnt die Füllung über das Hindernis zu wachsen, je näher es dem Spieler kommt. Voll gefüllt ist es kurz bevor es den Spieler erreicht. Nebenbei lässt sich dadurch auch grob ablesen, was gerade “scharf” ist und wie viel Zeit noch bleibt.
Interaktive Objekte: Ein zweiter Shader zeichnet leuchtende Icons direkt auf die Objekte, damit man ihre Funktion erkennt: aufsteigende Pfeile für Boost/Sprungplattformen, ein Kristall für Sammelobjekte. Die Icons sind reine Mathematik (keine gemalten Texturen nötig) und blinken, wenn ein Knopfdruck gefragt ist.
¶ Particle Effects
Particle Effects fasst die vielen kleinen, bewegten Elemente zusammen: vom Hintergrund über die Spieler-Partikel bis zu den Sammel-Effekten. Vieles davon greift die Farbe des aktuellen Modus auf.
Hintergrund: Der Weltraum-Hintergrund wird prozedural aufgebaut: Der Manager spawnt per Code ein Sternenfeld in mehreren Parallax-Ebenen (Nebel, Planeten, zwei Stern-Bänder, Debris). Jedes Element bekommt zufällige Größe, Geschwindigkeit und Drehung. Die Ebenen scrollen unterschiedlich schnell (weiter hinten = langsamer) und beschleunigen mit dem Spieltempo. Verlässt ein Element den linken Rand, wird es rechts wieder eingesetzt und neu gewürfelt, so bleibt die Dichte konstant und das Feld endlos. Die Färbung mischt sich pro Modus Richtung der aktuellen Akzentfarbe.
Spieler und Feedback: Der Spieler zieht einen Trail, der je Modus anders aussieht (wässrig / rauchig / elektrisch), dazu Partikel für Antrieb, Knopfdruck, Aufprall und Start. Screenshake und eine kurze Hit-Pause bei Treffern machen Aktionen spürbar.
¶ Sounds
Wir haben uns bewusst dazu entschieden, starke Soundeffekte gezielt dort einzusetzen, wo der Nutzer sie intuitiv erwartet. Menü-Buttons erhalten beispielsweise klangliche Rückmeldung, um sich wertiger und reaktionsfreudiger anzufühlen.
Bei Elementen und Spielmechaniken, die sehr häufig auftreten, haben wir hingegen auf Sounds verzichtet, um den Spieler nicht unnötig abzulenken. Sprünge, Gravitationswechsel und Richtungsänderungen bleiben daher bewusst stumm. Unsere Tests haben gezeigt, dass ein wiederholter Sound bei diesen Aktionen schnell als störend wahrgenommen wird und den Spielfluss unterbricht.
¶ Planung & Workflow
Im Laufe des Projekts haben wir mit einer Vielzahl an Tools gearbeitet – von Discord, Figma und Miro über Unity und Git bis hin zu Jira. In Jira haben wir unsere Aufgaben in Form von Tickets verwaltet und damit stets den Überblick behalten, was noch zu erledigen ist.
Unser Board war in mehrere Spalten unterteilt: eine für geplante Features, die wir flexibel befüllen konnten, eine für bekannte Bugs und eine für gesammeltes Spieler-Feedback. Sobald jemand eine Aufgabe übernommen hat, wurde das entsprechende Ticket der eigenen Person zugewiesen und in die Spalte „In Arbeit" verschoben. So war jederzeit transparent, wer gerade woran arbeitet, und der gesamte Entwicklungsablauf blieb übersichtlich nachvollziehbar. Erledigte Arbeit musste zudem immer von Mindestens einer weiteren Person getestet werden. So haben wir versucht von anfang an Bug zu vermeiden.
¶ MoSCoW
¶ Genutzte Tools
Unity
Jira
Git
Figma
Discord
Miro¶ Ideen & Entwicklung
¶ Ausgangslage
Die Aufgabenstellung sah vor, ein One-Button-Game zu entwickeln, das primär für mobile Endgeräte ausgelegt ist. Gestaltung und Umfang des Projekts waren dabei uns überlassen – mit der zusätzlichen Anforderung, dass das Spiel am Ende einen hohen „Juice"-Faktor aufweisen soll.
Da für das Gesamtprojekt zehn Wochen eingeplant waren und parallel weitere Projekte liefen, musste der Scope bewusst klein gehalten werden, um eine realistische und qualitativ hochwertige Umsetzung zu gewährleisten.
¶ Entwicklungsprozess
¶ Ideenfindung
Während der Konzeption wurden viele mögliche “One-Button“-Spiele besprochen. Dazu wurden bestehende “One-Button“ analysiert. Unter den verworfenen Konzepten sind zum Beispiel:
- Rhythmus-Spiel
- Tower Defense Spiel
- Bogenschützen-Spiel
- Tower-Stacking-Spiel
¶ Idee festmachen
Nach der Ideenfindung zu One-Button-Konzepten einigte sich das Team auf einen Endless Runner und analysierte bestehende Spiele des Genres als Referenz.
¶ Mini-Prototypen
Drei Prototypen mit unterschiedlichen Bewegungsarten wurden entwickelt und direkt von anderen Studierenden getestet, um herauszufinden, welches Prinzip am meisten Spaß macht. Ergebnis dieses Testings war, dass alle Prototypen Spaß machten. Somit entschieden wir uns, sie zu kombinieren.
¶ Medium-Prototyp
Die Mini-Prototypen wurden kombiniert: Alle Bewegungsarten existierten gleichzeitig im Spiel, der Wechsel erfolgte über Zonen. Eine dynamische Level-Generierung wurde vorab kurz prototypisch erprobt und ebenfalls integriert. Nachdem die Zusammensetzung fertig war, testeten wir sie erneut mit einigen Spielern und begannen den Prototypen weiter auszuschmücken.
¶ Sound Recherche & Anpassung
Die Musik und Soundeffekte stammen von Pixabay, da die Plattform lizenzfreie Musik und SFX anbietet. Wir haben die Audiodaten in DaVinci Resolve Studio und Audacity so bearbeitet, dass sie optimal zu unserem Spiel passen. Zusätzlich haben wir in Unity den Audio Mixer genutzt, um Musik und SFX klanglich abzustimmen. Damit ermöglichen wir dem Spieler zudem, die Audioeinstellungen individuell anzupassen.
¶ Erster großer Prototyp
Der Medium-Prototyp wurde um weitere Visuals, ein Tutorial und deutlich mehr zufällig generierte Level erweitert. Bis zum Playtesting im GamesLab konnten noch nicht alle geplanten Features implementiert und Bugs gefixt werden. Aber aufgrund unserer Priorisierung war doch eine finale Version des Prototyps beim Playtesting spielbar
¶ Erster Playtest
Beim Playtesting beim Games Lab erhielten wir zahlreiche wertvolle Ideen, Kritikpunkte und entdeckte Bugs. Wie bereits zuvor beschrieben, hatten wir bereits eine eigene Liste mit fehlenden Features und Problemen erstellt. Die Playtests halfen uns, die Priorität dieser Probleme zu identifizieren und entsprechend in unserer Planung zu berücksichtigen.
¶ Erste Iteration
Ein zentrales Feedback aus den Playtests war, dass die Gravity-Steuerung für viele Spieler zu schwer zu kontrollieren war. Zudem wurden sammelbare Collectibles gewünscht, und die UI muss überarbeitet werden. Des Weiteren wurde die Level-Generierung als zu repetitiv bewertet. Abschließend gab es die Empfehlung, die Steuerung zu verbessern. Vorher mussten Spieler zwischen Maus und Tastatur hin und her wechseln.
¶ Neue Zielsetzung
Nachdem wir das Feedback systematisch iteriert hatten, haben wir uns dazu entschlossen, einige bisherige Features aus dem Scope zu nehmen, die wir zuvor noch als „Could have" eingestuft hatten. Insbesondere weitere Spielmodi zum Lernen oder Vergleichen, trotz positiver Rückmeldungen von vielen Spielern, haben wir bewusst zurückgestellt. Unser Fazit war, dass für den Grundmodus zunächst noch weitere Level fehlen. Zusätzlich haben wir beschlossen, den ersten Prototyp komplett zu verwerfen, was erneut Zeitinvestition in das Grundgerüst notwendig machte.
¶ Finales Game
Der erste große Prototyp wurde bewusst verworfen, da seine schnell gewachsene Codebasis keine saubere Grundlage für die Weiterentwicklung bot. Die finale Version wurde neu aufgebaut und vereint alle gewünschten Features sowie das Feedback aus dem Playtesting:
- Überarbeitete Visuals und UI
- Mehr Level und mehr „Juice"
- Intuitiveres Gameplay, besseres Tutorial
¶ Playtesting & Feedback
¶ Ergebnisse
Beim Games-Lab-Playtesting erhielten wir vieles an guten Ideen, Kritiken und gefundenen Bugs. Wie schon vorher beschrieben, hatten wir bereits selbst eine Liste an fehlenden Features und Problemen. Die Playtests halfen die Wichtigkeit dieser Probleme zu identifizieren und entsprechend zu planen. Key-Feedback aus den Playtests war unter anderem:
- Gravity war zu schwer zu kontrollieren
- Sammelbare Collectibles sind gewünscht
- UI muss überarbeitet werden
- Level Generierung zu repetitiv
- Steuerung verbessern (vorher musste man zwischen Maus und Tastatur hin und her wechseln)
¶ Konsequenzen
Wir mussten feststellen, dass wir an den einzelnen Level-Konzepten noch arbeiten mussten, damit diese besser zueinander passen. Besonders die wenig unterschiedlichen Level stellten für viele Spieler ein Problem dar, weshalb wir hier deutlich mehr Zeit investiert haben. Daraus ergab sich, dass andere geplante Features weiter nach hinten verschoben und somit an Bedeutung verloren. Auf der anderen Seite bestätigte uns dies jedoch, dass unsere Idee gut ankommt. Das Konzept muss lediglich noch weiter ausgearbeitet werden.
¶ Finale Version
Der erste große Prototyp wurde bewusst verworfen, da seine schnell gewachsene Codebasis keine saubere Grundlage für die Weiterentwicklung bot. Die finale Version wurde neu aufgebaut und vereint alle gewünschten Features sowie das Feedback aus dem Playtesting: Überarbeitete Visuals und UI Mehr Level und mehr „Juice" Intuitiveres Gameplay, besseres Tutorial