Der Adventure Jam 2018 hat mich vor ganz neue Herausforderungen gestellt, mit denen ich nicht gerechnet hatte. Aus Zeitgründen wollte ich zuerst gar nicht mitmachen. Dann habe ich mich doch mit alten Freunden zusammengetan, um ein kleines Spiel zu entwickeln, und wir wollten die Produktion optimieren, indem wir so viel wie möglich im Voraus planen.
Natürlich lief nichts nach Plan. Wir mussten uns auf unvorhergesehene Herausforderungen einstellen und haben im Rahmen unserer Möglichkeiten ein Spiel entwickelt, das Potenzial hatte, aber nicht alle Ziele erreicht hat, die wir uns gesteckt hatten. Trotzdem war es eine enorm lehrreiche Erfahrung. Die wichtigsten Lektionen teile ich in diesem Blogbeitrag.
Ich schreibe nun schon zum dritten Mal über den Adventure Jam. Drei Jahre lang habe ich an diesem Jam teilgenommen und dabei drei Spiele entwickelt: Awake, One Of Us und The Ransom. Die Erfahrungen bei der Entwicklung dieser Spiele waren sehr unterschiedlich und wertvoll, und in dieser dreiteiligen Reihe teile ich meine wichtigsten Erkenntnisse zu jedem einzelnen. In diesem Beitrag geht es um die Entwicklung von The Ransom.
Adventure Jam 2016: Awake
Adventure Jam 2017: One Of Us
Adventure Jam 2018: The Ransom
Team und Konzept finden
Eigentlich hatte ich beschlossen, 2018 nicht beim Jam mitzumachen, weil ich über mein Geburtstagswochenende eine Reise geplant hatte und schlicht keine Zeit gehabt hätte. Als es dann so weit war, wollte ich aber unbedingt doch dabei sein. Also habe ich beschlossen, in der ersten Jam-Woche schnell ein Spiel zu bauen und in der zweiten Hälfte in einen wohlverdienten Urlaub zu fahren.
Da wir schon im Vorjahr zusammengearbeitet hatten, habe ich Torin und Felix gefragt, ob sie wieder ins Team kommen. Mit der Zeit kamen noch Owen dazu, den wir über den Discord des Jams gefunden haben, und Carsten, mit dem ich schon ein paarmal gejammt hatte. Noch vor dem Start des Jams hatten wir verschiedene Ideen gesammelt und hin und her überlegt.
Ein paar Wochen vor dem Jam hatte ich auf einer Spielekonferenz Hitchhiker gespielt und fand die Idee spannend, die Spielenden auf einen Sitz in einem fahrenden Fahrzeug zu beschränken. Mit diesem kurzen Pitch wollte ich die anderen davon überzeugen, so ein Spiel zu machen:
Der Fahrgast. Der Spieler sitzt als Fahrgast in einem Auto (oder, so dachte ich, es könnte auch eine mittelalterliche Kutsche sein, das Setting lässt sich ändern). Zuerst glauben wir, dass uns einfach jemand mitnimmt, doch dann kippt die Stimmung. Der Fahrer verriegelt die Türen. Er hat etwas vor, und es ist nichts Gutes. Vielleicht können wir unsere Gurte nicht lösen. Der Fahrer ist böse. Und wir sind ihm ausgeliefert. Der Spieler muss einen Weg finden, aus dem fahrenden Fahrzeug zu entkommen und herauszufinden, was der Fahrer im Schilde führt.
Wir haben uns wegen der Einfachheit für diese Idee entschieden, das Setting aber in eine mittelalterliche Kutsche verlegt. Wir wollten uns auf eine einzige Umgebung beschränken und auch die Zahl der Figuren möglichst klein halten. Nachdem die Kernidee stand, habe ich ein ausführlicheres Design samt Hintergrundgeschichte ausgearbeitet, auf dem wir zum Start des Jams aufbauen konnten.
Nach den Vorjahren hatte ich mich viel mit Puzzle Design beschäftigt und wollte das Pyramidenmodell ausprobieren. Dabei haben die Spielenden zu Beginn viele verschiedene Dinge zu tun, die nach und nach auf wenige, schwierigere Rätsel zusammenlaufen. Da wir nur die Hälfte der Jam-Zeit nutzen wollten, haben wir uns so gut wie möglich vorbereitet. Sobald der Jam losging, sollten wir nur noch Assets am Fließband produzieren und zusammensetzen müssen. Dazu gehörten Asset-Listen, fertig geschriebene Dialoge, Storyboards für die Cutscenes und Recherche zu den Technologien, die wir nutzen wollten. Die Planung wurde zu einer großartigen Lernerfahrung in Sachen Spieleproduktion, auch wenn (oder gerade weil) wir in dieser Zeit viele Fehler gemacht und uns oft verschätzt haben.
Produktion
Weil alles so gut wie möglich vorbereitet war, sind wir hochmotiviert in den Jam gestartet und haben direkt angefangen, Assets und Inhalte zu produzieren. Die Asset-Listen dienten uns als Leitfaden, und das Flussdiagramm der Rätsel war eine super Roadmap, um Logik und Rätsel umzusetzen. Ich hatte das Flussdiagramm ausgedruckt und nach jedem umgesetzten Teil eines Rätsels die erledigten Stellen abgehakt.
Torin hat schnell die Umgebung gebaut und mit der Beleuchtung experimentiert. Die Idee war ein kreisförmiger Weg, auf dem die Kutsche endlos fährt, damit die Spielenden das Gefühl haben, ständig in Bewegung zu sein. Am meisten unterschätzt habe ich die Aufgabe, die Kutsche mit einem Spline-System im Kreis durch die Umgebung fahren zu lassen. Am Ende habe ich es umgekehrt gemacht und die Umgebung um die Kutsche kreisen lassen. Weil sich alle interaktiven Stellen und UI-Overlays ständig bewegten, tauchten viele kleine Artefakte auf, und die Interaktionen ruckelten stark. Die Umgebung um die Kutsche zu bewegen, hat das gelöst (während sich die Umgebung bewegt, wird die Kutsche trotzdem passend zu ihrer Position auf dem Weg gedreht … eine seltsame Lösung, aber sie hat funktioniert).
Owen hatte die Aufgabe, die Pferde und ihre Laufanimation zu erstellen. Das hat lange gedauert, brauchte viel Feinschliff und ist im fertigen Spiel kaum zu sehen. Hätte ich gewusst, wie groß diese Aufgabe wird, hätte ich die Pferde gestrichen, eine einfachere Lösung gefunden oder sie im Spiel mehr gezeigt.
Da ich damals an einem First-Person-Exploration-Spiel gearbeitet habe, war das die perfekte Gelegenheit, ein paar Tools zu üben, die ich für mein Hauptspiel einsetzen wollte. Deshalb haben wir bei diesem Spiel nicht Adventure Creator genutzt (wie bei den vorherigen Titeln), sondern das „First Person Exploration Kit“ aus dem Asset Store. Das zu lernen war cool, hat aber auch bedeutet, dass ich die Rätsel viel langsamer umgesetzt habe als mit einem Tool, das ich gut kenne. Alles in allem hat die Umsetzung der First-Person-Logik gut geklappt, sie war nur sehr langsam. Deshalb hatten wir nach den ersten fünf Tagen auch noch nichts wirklich Spielbares.
Gespräche mit anderen Jammern über unsere Story und das Feedback zu den Dialogen brachten uns auf die Idee, das Ende zu ändern. Wir wollten die Schuld der Hauptfigur bis zum bitteren Ende führen und haben eine kurze Sequenz eingebaut, in der die Spielfigur sich das Leben nimmt, indem sie sich erhängt (Monate später ist mir aufgefallen, dass „Erhängen“ ungewollt zum roten Faden aller drei Spiele für den Adventure Jam geworden war). Dieses Ende bedeutete mehr Assets, zusätzliche Bewegungslogik und eine komplett neue Umgebung. Obwohl wir es einfach gehalten haben, hat es länger gedauert als gedacht.
Zum Glück hat uns der Voice Acting Power Squad wieder beim Voice Acting unterstützt. Diesmal wurden die Aufnahmen nicht online gestreamt, trotzdem haben wir kostenlos großartige Sprachaufnahmen bekommen. Vielen, vielen Dank! Das Skript war schon vor dem Jam fertig, und weil ich in der ersten Woche durch sein wollte, haben wir die Texte sehr früh an den VAPSquad geschickt. Das hieß aber auch, dass wir das Skript danach nicht mehr ändern konnten.
Trotz aller Mühe war das Spiel nach der ersten Woche nicht fertig. Die meisten Assets schon, aber die Logik hatte noch jede Menge Bugs. Das Spiel brauchte einfach noch viel mehr Feinschliff. Um es fertigzustellen, habe ich meinen Laptop mit in den Urlaub genommen und weiter am Feinschliff gearbeitet, während die anderen schliefen oder wir im Zug saßen. Ich habe es rechtzeitig geschafft und das Spiel am letzten Tag des Adventure Jam unterwegs hochgeladen.
Resonanz und Erkenntnisse
Weil in diesem Jahr Jake Rodkin in der Jury saß und ich ein riesiger Fan von Firewatch bin, war mein Traum, ein Spiel zu entwickeln, das es wenigstens in die Auswahl schafft, die die Jury spielt. Das hat nicht geklappt, aber insgesamt kam das Spiel trotzdem ziemlich gut an: Es wurde auf Platz 10 der besten Spiele insgesamt gewählt, auf Platz 7 für die beste Musik und auf Platz 9 für das beste Storytelling.
Trotz aller Mühe hatte das Spiel ziemlich viele Bugs. Der schlimmste hat das ganze Spiel kaputt gemacht und wurde jedes Mal ausgelöst, wenn jemand die Leertaste drückte. Das hat für ordentlich Stress gesorgt und auch einige Let’s-Play-Videos ruiniert. Vor allem das von Jupiter Hadley, auf das ich mich so gefreut hatte (The Ransom beginnt bei 11:23, der Bug bei 12:06).
Eines der größten Probleme war die Art, wie die Geschichte erzählt wurde. Manche Teile der Erzählung ließen sich überspringen oder wurden nicht richtig erklärt. Dazu kam einfach zu viel Vorgeschichte, sodass die Spielenden nicht verstanden, was eigentlich los war. Die Beziehung zwischen der Spielfigur und ihrem Entführer sollte ziemlich komplex sein und wurde über subtile Dialoge und kleine Hinweise in der Umgebung erzählt. Nach den Let’s Plays, die ich gesehen habe, waren die Spielenden aber mehr an den Rätseln interessiert als an den Dialogen. Sie haben sie übersprungen und die Geschichte deshalb überhaupt nicht verstanden. Das bedeutete auch, dass der Story-Twist oft gar nicht wahrgenommen wurde und das Ende für viele keinen Sinn ergab.
Als Lernerfahrung für First-Person-Exploration haben wir eine MENGE mitgenommen. Geschichten interaktiv zu erzählen ist schwer!
Die Rätsel funktionierten größtenteils gut, aber an einigen Stellen blieben die Spielenden häufig hängen. Man ist es gewohnt, auf das zu schauen, was direkt vor einem liegt. Interaktive Stellen hinter oder neben der Spielfigur zu finden, dauerte deshalb oft ziemlich lange. Wir hätten Hinweise oder kleine Anstöße einbauen sollen, die die Spielenden dazu bringen, sich öfter umzudrehen. Das letzte Rätsel war etwas zu konstruiert und seltsam (man musste einen Nagel an einem Stock befestigen und damit in einem bestimmten Zeitfenster den Mantel des Fahrers durch ein Fenster greifen) und hat einige dazu gebracht, das Spiel abzubrechen. Die richtige Balance im Rätseldesign zu finden ist schwer. Das in einem Game-Jam-Setting zu üben, ist eine sehr wertvolle Erfahrung!
Alles in allem steckte der Adventure Jam 2018 voller wertvoller Lektionen. Eine Produktion zu planen ist wichtig, wird aber nie perfekt sein. Scheinbar einfache Aufgaben können länger dauern als gedacht, und sie werden es auch. Interaktives Storytelling und Rätseldesign sind schwer. Es geht darum, klar mit den Spielenden zu kommunizieren, statt Informationen vor ihnen zu verstecken.
