JUST DO IT! ist ein kleines Geschicklichkeitsspiel. Es entstand innerhalb 72 Stunden für den Dr. Snails Game Jam und ist, zum Erstaunen mancher, sehr umfangreich. Wie funktioniert das? Wie kann man alleine binnen drei Tage ein Spiel mit 30 Level, zahlreichen Grafiken, Menüs, Optionen, Soundeffekten, Partikeln, Musik und vielen anderen Kleinigkeiten, die alle Zeit kosten, erstellen? Dieser Artikel soll die wichtigsten Tricks verraten.
Bevor es los geht: Wer sich einen Eindruck vom Spiel verschaffen möchte, kann hier die HTML5-Version spielen.
Erfahrung hilft enorm
Ebenfalls hilfreich ist es, wenn man sich bereits gut mit seiner Entwicklungsumgebung auskennt. Wenn man erst lange suchen muss, wo und wie man bestimmte Dinge umsetzt, schafft man vieles einfach nicht. Neu bei dem Spiel war für mich, dass ich mich zum ersten Mal im GameMaker intensiver mit Tiles befasste. Beim Levelbau hätte es mir beinahe das Genick gebrochen, aber die Bedienung ist zum Glück derart intuitiv, dass ich die verlorene Zeit zum Ende hin aufholen konnte.
Die Darstellung ist dann denkbar einfach. Man zeichnet zunächst den Kreis, dann die Linie, welche abhängig von image_angle ist. Anschließend kommt das eigentliche Sprite und ganz oben das Dreieck, ebenfalls abhängig von image_angle. Die ganze Optik mit Farben, Outline etc. sind nur 15 Zeilen. Mit etwas Erfahrung ist das in Nullkommanichts umgesetzt.
Vorbereitung und Planung
Das Problem beim Jam war, dass das Thema erst kurz vor Beginn feststand. Die zur Wahl stehenden Themen waren teils so unterschiedlich, dass eine Vorarbeit nahezu unmöglich war. Das war die Absicht dahinter. Meine Vorbereitung bestand vor allem darin, mir Gedanken zu machen und mich auszuruhen. Das begann schon mit dem Schlafrhythmus. Ich stand erst wenige Stunden vor Beginn auf, war komplett ausgeruht und erstaunlich gut „im Saft“.
Zu ein paar Themen hatte ich bereits einige, teils verrückte Ideen. Als das Thema „Einer gegen alle“ feststand, musste ich mich für eine Idee entscheiden. Grob gesagt fiel die Entscheidung zwischen „mach was verrücktes, aber wenig davon“ und „mach was solides, aber dafür mehr Inhalt“. Es wurde Letzteres, da mir die Idee kam, gleich mehrere Kriterien bzw. zur Auswahl stehende Themen zu erschlagen. Als spezielle Herausforderung, sozusagen. Es sollte ein wenig wie alte DOS oder Amiga-Spiele wirken (Retro) und ich wollte einen Umfang von circa 30 Minuten Spielzeit erreichen.
Das Spielprinzip von JDO! war mir auch nicht ganz neu. Vor acht Jahren machte ich ein vergleichbares Spiel, damals aber viel umfangreicher mit gerenderten 3D Grafiken. Ich konnte also zumindest abschätzen, wie viel Arbeit der Levelbau in Anspruch nimmt.
Alte Batman-Veteranen kennen den Spruch: „Erfahrung lehrt langsam und auf Kosten vieler Fehler.“ Deshalb weiß ich mittlerweile, dass man mit den Dingen beginnen sollte, die am meisten Konzentration abverlangen. Klar, man kann auch mit Grafiken und Sounds beginnen und dann Level bauen, aber ich ziehe es vor, mit dem Code zu starten. Hier kann man mit Platzhalter-Grafiken arbeiten und wenn man das sauber löst, hat man für die kommenden Stunden ein relativ ruhiges Leben. Übermüdet komplexere Dinge zu programmieren führt nur selten zu einem beglückenden Ergebnis.
Auf der anderen Seite ist es für mich besser, Level zu bauen, wenn ich etwas müde bin. Da bin ich zwar nicht kreativer, aber da ich immer sofort teste, werden die Level um einiges leichter als im fitten Zustand. Den Trick habe ich bei CYPEST gelernt, weshalb ich jedes Level noch ausgiebig teste, wenn ich sehr müde bin.
Die Schlafeinteilung ist zwar eine wichtige Komponente, lässt sich bei mir aber nicht perfekt planen. In den 72h habe ich etwa sechs Stunden geschlafen. Nach dem Aufwachen habe ich mich mit Kaffee versorgt, ein paar Sachen getestet, dann einfache Dinge eingebaut und als ich fit war, ging es an die komplexen Arbeiten. Am Ende, vor allem am letzten Tag, war der Levelbau angesagt. Grundsätzlich war es auch hilfreich, die Arbeiten so einzuteilen, dass ich nicht zu lang die selben Aufgaben durchführte. Zwischen dem Code ging es an Soundeffekte, Musik, ein paar Grafiken und dann wieder, geistig ausgeruht, wieder an den Code. Auch hier hilft die Erfahrung, um sich die Kraft optimal einzuteilen.
Entwicklungsumgebung
Außerdem gibt es Verfahren, die sich bei mir seit Jahren bewährt haben. Wie baue ich generell ein Spiel auf? Wo platziere ich welche Objekte und welche Werte frage ich wann ab? Wenn man das noch nie gemacht hat, hängt man sich schon an so simplen Dingen wie einer globalen Steuerung für Fullscreen/Fenstermodus auf. Hier spielen Erfahrungen und Entwicklungsumgebung perfekt zusammen. Seit Jahren verwende ich die gleichen Variablen und Abläufen, die sich im laufe der Zeit nur etwas verbessert haben. Dazu kommen ein paar nützliche Skripte, die mich ebenfalls seit Jahren begleiten. Das ganze INI-System, Mehrsprachigkeit und andere Dinge begleiten mich bereits seit Jahren. Neu im Spiel war allerdings der Anspruch, das Menü mit Tastatur, Gamepad UND Maus zu bedienen. Das hatte ich vorher noch nie, weshalb ich auch auf kein bestehendes Menüsystem zurückgreifen konnte und alles neu schrieb. Aber auch das ist mit GameMaker relativ einfach umsetzbar, wenn man weiß, wie es geht.
Der Vorteil an der effizienten Vorgehensweise ist zusätzlich, dass man Bugs sehr schnell beheben kann. Erst kurz vor Release tauchten ein paar Fehler auf und beispielsweise der Wunsch eines Testers, Checkpoints einzubauen. Letzteres war in 20min umgesetzt, für die Grafik gingen weitere fünf Minuten drauf. Auch hier ist es gut, wenn man sich mit einem Programm wie Photoshop ausreichend auskennt.
Für die Sounds verwende ich ebenfalls Programme, die ich mittlerweile blind bedienen kann. Für Soundeffekte und Schnitt kommt natürlich Audacity zum Einsatz, Lieder werden ausschließlich in Renoise komponiert.
Recycling lebt vom Mittmachen
Das Tileset musste ich komplett neu erstellen, für die Buttons hatte ich bereits eine Vorlage aus anderen Projekten, beispielsweise Kopfnuss.
Wie bereits geschildert, lässt sich beim Code durch die konsequente Anwendung von Vererbungen viel einsparen. Ein zweiter Trick ist, alles, was man mehrfach braucht, in Skripte auszulagern.
Das offensichtlichste Element, bei dem Recycling zum Einsatz kam, waren die Level selbst. Zunächst baute ich mir eine Vorlage. Jedes Level hat eine Mindestgröße, ein paar Objekte die immer vorhanden sind und eine bestimmte Anzahl und Reihenfolge von Ebenen. JDI! hat acht Ebenen und eine Levelgröße von mindestens 1920×1080 Pixel. Immer vorhanden sind Wände, das Startfeld und das Ende-Feld. Der Spieler ist ein persistentes Objekt und wird vom Startfeld in Level 1 erzeugt, ab dann in jedem Level neu positioniert. Mit so einer Vorlage kann man schon ganz gut arbeiten. In vielen Fällen habe ich ein fertiges Level kopiert und angepasst, ggf. alle Inhalte gelöscht und die Größe erweitert. Als ersten Schritt setze ich Start und Ende auf ihre gewünschte Position und ziehe dann die Wände ein. Zwischendurch habe ich an einer Stelle eine konkrete Idee und platziere da schon Gegner, Schlüssel und Türen. Anschließend wird getestet. Wenn der grobe Aufbau gut genug ist, wird er verfeinert, verbessert und am Ende werden die Tiles gemalt. Die Wand-Objekte sind schließlich unsichtbar und dienen lediglich der Kollisionsabfrage.
Zur Musik: Am Anfang waren nur zwei Lieder geplant. Ein kurzes Lied im Menü und eines im Spiel. Vor einigen Jahren komponierte ich für einen Bekannten ein Dutzend Lieder für ein Spiel, welches nie erschien. Zwar davon nahm ich, komponierte sie um und verwendete andere Instrumente. Das ging relativ flott und klang meiner Meinung nach auch richtig gut. Mit dem wachsenden Inhalt musste ich aber feststellen, dass selbst der beste 2min-Loop nervt, wenn man ihn eine halbe Stunde hört. Also schaute ich in meinem Archiv der selbst komponierten Lieder nach und fand ein paar, die ich dazu mischen konnte. Es ist zwar selbst gemacht, aber, abgesehen von ein paar Anpassungen und dem eigentlichen Mix, nicht in den 72h. Übrigens ist das auch der Grund, warum das Spiel rund 17MB hat. Es stecken mehr als 10min Musik darin.
Wille schafft alles
Mein persönliches Ziel mit dem Spiel war es, ein Projekt abzuliefern, mit dem ich mich nicht blamiere. Außerdem wollte ich sehen, was ich in 72h noch auf die Beine stellen kann, schließlich wird man ja nicht jünger.
Die erste Hälfte ging relativ flott, aber der Levelbau in der zweiten Hälfte raubte mir ziemlich viele Nerven. Hier half eine immer lautere, schnellere Musik, Koffein und der unbedingte Wille, es schaffen zu wollen. Perfekt lief das natürlich nicht ab, beispielsweise musste ich zwischendurch für ein paar Stunden raus um einzukaufen, aber man muss das positiv sehen. Bewegung kurbelt den Kreislauf an und man kann sich Gedanken über Leveldesign, Schwierigkeitsgrad, Lernkurven etc. machen. Ich denke, dass das am Ende auch das Entscheidende war: positive Gedanken. Statt vorab Ausreden für das eigene Scheitern (in Bezug auf verfehlte Ziele) zu suchen, muss man von sich und der Arbeit überzeugt sein.