I made a Game with cool People

Ich arbeite schon seit einigen Jahren an einem Projekt in Game Maker. Da ich mich nur in meiner Freizeit damit befasse, mache ich nur sehr langsame Fortschritte, aber das ist okay und es wird noch sehr lange dauern, bis daraus ein fertiges Spiel wird. Wenn man aber an einem Projekt arbeitet, welches ewig lange vor sich hin vegetiert, dann wünscht man sich doch vielleicht, mal etwas ganz neues, was man auch fertig machen könnte. Am besten ein kleines Neben-Projekt. Nur dafür braucht es eine Idee. Und Leute, denn Grafiken und Sounds machen kann ich nicht. Genau dafür bietet sich ein Game Jam an. Als kurz darauf der GMTK Game Jam 2018 von Mark Brown, bekannt durch seinen Youttube-Channel Game Maker’s Toolkit, angekündigt wurde und ich auch Zeit dafür hatte, stand für mich die Teilnahme fest.

Meine erste Sorge galt mindestens einen Partner zu finden. Am liebsten wäre mir ein Team aus vier Leuten gewesen – vielleicht sogar fünf, auch wenn man meinen könnte, dass jeweils nur eine Person für Grafik, Coding und Sound, wenn man sich nicht an öffentlichen Sound-Archiven bedienen möchte, reichen sollte. Meine größte Befürchtung war aber, dass mein Team und ich bei der Themen-Verkündung beim Jam-Start keine Idee haben, denn Ideen-Findung kann sehr hart sein. Ich wollte die Situation vermeiden, dass wir in einem (virtuellen) Raum herumsitzen und Löcher in die Luft starren. Vor allem wollte ich auch nicht mehr der Ideengeber sein. Durch mein Solo-Projekt kommt jeglicher Input von mir selber und deshalb wollte ich an einem Projekt beteiligt sein, in dem ich zur Abwechslung stumpf den Eingaben eines anderen nachkommen kann. Ich habe mir also ein etwas größeres Team gewünscht, um mehr Leute zu haben, die über Ideen nachdenken können. Dabei sollten es aber auch nicht zu viele Leute werden, um noch überschaubar zu bleiben und die Entscheidungsprozesse einfach zu halten – bei einem Team von 10 Leuten ohne Hierarchien stelle ich es mir schwer vor, jederzeit die Zustimmung von jedem zu haben. Vier schien mir deshalb eine gute Zahl zu sein.

Aber zunächst galt es, überhaupt einen Partner zu finden. Ich hatte mir vorgenommen, möglichst früh, also zwei Tage vor Beginn im Discord-Channel zu gucken, den Mark Brown für den Jam zugänglich gemacht hatte – sollte kein Problem sein. Es war ein Problem. Es scheint wesentlich mehr Coder als Graphiker zu geben und entsprechend war ich nicht der einzige, der “Looking for an artist” schrieb. Wobei ich keine Erfahrungen mit Unity oder anderen 3D-Engines habe und es deshalb speziell ein 2D-Artist werden musste. Wenn denn mal ein Artist auftauchte, war er schnell vergeben. Zu meiner Erleichterung fand ich einen Tag vor Jam-Beginn einen Partner aus Peru – einen Tag später habe ich ihm abgesagt. Der Zeitunterschied von sechs Stunden hatte mir zu viele Sorgen gemacht. Also machte ich mich, optimistisch wie ich war, wieder auf die Suche nach neuen Partnern, denn schließlich hatte ich noch einen vollen Tag. Den ich mit Fluchen verbracht habe, denn bei der Suche nach einem Artist fühlte ich mich wie bei der Job-Suche – entweder passte es nicht oder war schon vergeben. Erst drei Stunden vor Jam-Beginn fand ich einen Partner. Kmspirit, aus Israel, was einen angenehmen Zeitunterschied von einer Stunde bedeutete. Und kurz darauf fand ich noch einen zweiten Artist – kurz bevor und noch nach Jam-Beginn meldeten sich die Grafiker und ich notierte mir für die Zukunft, bei solchen Veranstaltungen nicht mehr überpünktlich zu sein. Mein zweiter Artist, SmashArtist kam aus den USA, was einen lockeren Zeitunterschied von neun Stunden bedeutete – ist als Karma dafür notiert, dass ich dem Dude aus Peru abgesagt habe. Einen Menschen für den Sound zu finden, war wiederum nicht schwer und mit Jozzua war mein Vierer-Team komplett. Um Elf wurde dann das Video mit dem Thema veröffentlicht – Genre without a Mechanic. Also ein Spiel mit einem beliebigen Genre, bei dem eine bestimmte Mechanik fehlen sollte. Also ein Rennspiel, ohne zu lenken oder ein Shooter, ohne schießen zu können. Kein Problem, also schnell eine Idee finden und dann konnten wir loslegen.

Es war ein Problem. Wir hatte drei Stunden später immer noch keine Idee. Wir haben wahllos einige Gedanken in den Raum geworfen, aber nichts schien wirklich haften zu bleiben. Denkbar wäre beispielsweise ein Schleicher gewesen, ohne sich verstecken zu müssen, haha – nein! Nachdem ich seit Jahren sporadisch an meinem Schleicher arbeite, wollte ich nicht noch einen weiteren Schleicher anfangen. Ein Shooter ohne nachladen zu können hätte mich interessiert. Das größte Interesse des Teams konnte aber die Idee eines Plattformers ohne Plattformen verbuchen. Um Bewegungen ins Team zu bringen, habe ich angefangen, lose Konzepte zu machen – per Paint. Hey, wenn Ed Boon seine Fatalities für Mortal Kombat mit Strichmännchen plant, dann sollte Paint völlig legitim sein.

Ich fand die Idee interessant, ein Spiel mit einem leeren Raum zu haben und man würde als Spieler die Plattformen irgendwie erschaffen. Das hatte aber das Problem, dass man am Ende doch wieder Plattformen hätte.

Die nächste Idee war, ein ganzen Spiel mit Wall Climbing aufzubauen. Zu der Zeit hatte ich die Mega Man X-Spiele der Legacy-Collection gespielt, deshalb ist die Wall Climbing-Mechanic bei mir hängen geblieben. Der Spieler könnte zusätzlich in der Luft gleiten. Als Spielfigur könnte man deshalb ein Flughörnchen verwenden – ich hatte dazu vor einiger Zeit auf Twitter ein Video gesehen, welches an das ich denken musste. Bezüglich des Settings kam Splatton als Beispiel auf – also Großstadt. SmashArtist hatte kurz darauf ein Konzept-Bild erstellt, wie dieses Flughörnchen aussehen könnte – es war großartig. Um diese Zeit müsste es ungefähr schon drei Uhr morgens gewesen sein. Kmspirit hatte längere Zeit nichts mehr geschrieben und schien wohl eingeschlafen zu sein – für sie war es auch schon 4:00. Ich fing an, einen ersten Prototypen für ein Jump ‘n Run zu erstellen mit einen kleinen Testraum. Zunächst wollte ich ganz einfache Mechaniken einbauen – also laufen, springen und Kollisionsabfragen mit Wänden und Böden, wobei wir laufen kaum benutzen würden. Wenn diese Basics funktionierten, sollten Air Gliding und dann Wall Climbing drankommen. Bisher hatte ich aber noch nie ein Jump ‘n Run gemacht und dementsprechend auch Probleme damit, die Kollisionen mit dem Boden richtig hinzubekommen – wenn die Spielfigur erschien, ist sie immer durch den Boden gefallen. Es war spät, 4 Uhr morgens und Ideen für die Implementierung wollten mir keine kommen. Ich ging also auch ins Bett. Und dann konnte ich eine ganze Stunde nicht schlafen. Aber dafür kamen mir langsam die Ideen, wie ich den Jump ‘n Run-Prototypen umsetzen könnte – anstelle mich auf das Kollisions-Event von Game Maker zu verlassen, könnte die Figur vor jedem Schritt abfragen, ob der Platz vor ihr (oder unter ihr) frei ist und bewegt sich erst dann in diese Richtung. Um 10 stand ich wieder auf, um kurz zu frühstücken und weiter zu machen. Ich hatte frische Einfälle, die ich umsetzen wollte.

Hier ein Bild von dem ersten Testraum.

An dieser Stelle möchte ich euch ein kleines Geheimnis verraten: Wir haben uns eigentlich nie wirklich fest auf den Plattformer ohne Plattformen geeinigt. Es war die Idee, mit der wir am meisten arbeiten und uns Konzepte überlegen konnten. Das Problem war aber die Zeit und ich bekam das Gefühl, dass wir zu sehr darauf fixiert waren, die perfekte Idee zu finden. Der Plattformer ohne Plattformen ist vielleicht nicht die grandioseste Idee, aber es war zumindest eine, mit der wir voran kamen. Ohne eine Anfangsidee hatte ich beispielsweise nichts, was ich programmieren konnte. Oder unserem Musiker konnten wir keine Aufgaben geben, weil wir zunächst kein Setting hatten und wir nicht sagen konnten, was für Musik wir bräuchten.

Den ganzen Samstag habe ich jedenfalls damit verbracht, das Spiel im Kern fertig zu implementieren. Air Gliding war ziemlich leicht – drückt der Spieler die Sprung-Taste, während er fällt oder springt, gleitet er, was wiederum bedeutet, dass sich lediglich seine Fall-Geschwindigkeit verringert. Wall Climbing war wiederum hart, da ich es genau wie in den Mega Man X-Spielen haben wollte: Wenn der Spieler in der Luft ist und sich gegen eine Wand drückt, dann sollte er diese Wand runterrutschen und die Möglichkeit haben, nochmal springen zu können. In einer meiner ersten Versionen blieb der Spieler einfach an der Wand haften, wenn er sich gegen diese drückte. Später rutschte er zwar die Wand runter, konnte aber durch den Boden rutschen. Im Verlauf des Tages bekam ich auch die ersten Sprites und einige Soundeffekte, die ich dann noch einbauen musste – wenn das Flughörnchen springt, dann ändert sich nicht nur seine Position in die Y-Richtung, sondern das Sprite muss zum Sprung-Sprite wechseln und ein kurzes Soundfile sollte abgespielt werden.

Zum Nachmittag hin (meiner Zeit), als alle wach und mehr oder weniger ausgeschlafen waren, habe ich eine kleine Demo-Version mit einem Test-Raum erstellt, in dem die Basis-Funktionen funktionierten. Nur dann kam ein ganz neues Problem auf – Kmspirit und Jozzua haben kein Windows, sondern Mac und Game Maker erstellt nur eine lauffähige Mac-Version, wenn man ein entsprechendes Gerät angeschlossen hat. Glücklicherweise hat sich im Discord-Channel ein User gefunden, der Game Maker für Mac benutzt und sich bereit erklärt hat, uns eine Mac-Version zu erstellen.

Hier habe ich zwei Demo-Versionen selber ausprobieren hochgeladen, die aus unterschiedlichen Entwicklungs-Zeitpunkten stammen. Das zip-Archive enthält zwei exe-Datei für Windows und zum spielen muss die jeweilige Datei installiert werden. Zum Deinstallieren muss dann die jeweilige Versionen unter “Made in Game Maker Studio 2” deinstalliert werden.

SmashArtist hat sich um die Sprites gekümmert und Kmspirit sorgte für die Hintergrundgrafiken zu den Levels. Zunächst hatten wir beide ein Tutorial-Level geplant, mit welchem das Spiel beginnen sollte. In meinem Kopf war das Spiel relativ simpel und es ist eigentlich auch recht schnell erklärt, aber ich fürchtete, dass neue Spieler schnell überfordert wären. Der erste Entwurf, den ich von ihr bekommen hatte, sah unglaublich gut aus. Generell muss ich einwerfen, dass alles, was ich von meinem Team bekomme hatte, mich immer tief beeindruckt hatte – egal ob Sprites, Sound-Effekte, Musik oder Hintergründe. Alles klang und sah grandios aus. An dem Tutorial-Level waren aber leider noch einige kleinere Anpassungen notwendig. So mussten beispielsweise die Levels ein Format von 32 x 32-Pixel-großen Kacheln haben, damit die unsichtbaren Kollisions-Boxen passen würden und die erwähnte Sicherheitsplattform fehlte auch noch.

Hier das Konzept für das Tutorial-Level, worauf Kmspirit einen ersten Entwurf erstellte. Anhand dessen habe ich in Game Maker Studios die Kollisionsboxen gesetzt und schließlich folgte von Kmspirit die Endversion mit einigen Änderungen.

Hier muss ich kurz etwas erwähnen, was mir zunächst sehr schwer fiel. Ich bin nämlich irgendwie in so eine Art Lead-Position gerutscht, was mir durchaus liegt. Ich plane, organisiere und manage gerne. Das Team hatte ich zusammengestellt, in dem ich die Leute einzeln ausfindig gemacht hatte. Während des Projekts behielt ich stets im Hinterkopf, was wir noch alles für das fertige Spiel bräuchten. Ich denke, ich bin auch in diese Position gelandet, da alle Materialien im Endeffekt bei mir, dem Coder, landeten und ich alles per Hand im Code einbauen musste. Also wann wird welcher Soundeffekt und welches Sprite verwendet und alle Hintergrundgrafiken mussten mit Kollisions-Boxen versehen werden, damit sie “interaktiv” sind. Mit dieser Position hatte ich aber auch eine Aufgabe, die ich furchtbar fand: Anderen Leuten sagen, was sie tun sollten. Oder noch schlimmer: Ihnen sagen, dass sie etwas anders machen sollen. Oder am schlimmsten: Nachdem ich ihnen sagte, etwas nochmal anders zu machen, zu merken, dass es davor doch besser war. Ich will nicht der Typ sein, der meint, alles besser zu wissen als die anderen und vor allem will ich nicht der Arschloch-Chef sein, von dem man vielleicht mal gehört hat oder den man sogar mal hatte. Prinzipiell denke ich, dass wir eine gute Arbeitsatmosphäre hatten und ich mein Team nicht zu sehr mit Wünschen genervt habe. Aber an dieses Gefühl, anderen Leuten zu sagen, was sie tun sollen, musste ich mich zunächst gewöhnen.

Am Samstag konnten wir jedenfalls das Tutorial-Level abschließen und die Grundfunktionen und die Kamera klappten auch ziemlich gut. SmashArtist arbeitete an weiteren Sprites und Kmspirit nahm die Arbeit an dem ersten richtigen Level auf. Nur für Jozzua hatten wir eigentlich nicht mehr viel zu tun. Nachdem er die Soundeffekte und 2 Musikstücke fertig hatte, war er eigentlich fertig. Dies schien für Musiker keine Seltenheit zu sein. Als ich in den Discord-Channels guckte, fielen mir mehrere Leute auf, die andere Teams musikalisch unterstützen wollten. Ich hätte mir gewünscht, dass wir für Jozzua mehr zu tun gehabt hätten.

Am Sonntag blieben für mich hauptsächlich kleinere Arbeiten übrig. Ich schaute, dass die Grundfunktionen fehlerfrei waren und die Sprites richtig aufgerufen wurden. Ansonsten blieben viele Kleinigkeiten. So passierte zum Beispiel nichts, wenn die Spielfigur starb – in dem Fall verschwand sie nur, aber idealerweise sollte das Level natürlich neu starten. Auch ein Übergang zum nächsten Level fehlte noch. Dann wünschte ich mir, das Spiel mit der Escape-Taste beenden zu können. Unser Grafiker hatte ein Partikel erstellt und daraufhin habe ich zum ersten Mal ein Partikel-System implementiert. Wenn das Flughörnchen an einer Wand runterrutschte, erschienen nun kleine Staubwölkchen.

Am Sonntag hatte ich aber ein ganz schweres Problem, welches ich lösen musste. Scheinbar hatte ich irgendwann irgendwie das ganze Spiel kaputt gemacht. Ich konnte es nicht mehr starten. Immer wenn ich es gestartet habe, hat es sich wieder sofort beendet. Vor allem irritierte mich, dass Game Maker bei der Ausführung keine Fehlernachricht ausgab, wie es sonst der Fall wäre – das muss also ein ganz harter Fehler sein, wenn es dazu noch nicht mal eine Fehlernachricht gab! Im Log fand ich Nachrichten der Art ‘Error – audio conversion failed Audio file not found in cache!’ Aha, also müssen die Audio-Files nicht korrekt sein! Das hatte mich aber sehr verwundert, weil die Audio-Daten die ganze Zeit funktioniert hatten und es bisher keine Probleme gab. Ich habe viele Lösungsmöglichkeiten ausprobiert und sie mit Audacity zu neuen Datei-Typen konvertiert, aber auch das hatte nicht geholfen. Ich probierte dann etwas ganz neues: Ich habe alle Audio-Dateien raus genommen und alles, was mit ihnen zusammenhängen könnte. Das Spiel funktionierte immer noch nicht! Dann waren die Audio-Dateien zu meiner Erleichterung wohl doch nicht das Problem, aber was könnte es dann gewesen sein? In der Softwareentwicklung gibt es das Prinzip “Teile und herrsche.” Wenn man einen Fehler hat und man weißt nicht, wo er liegen könnte, dann deaktiviert man große Teile des Programms und behält zunächst nur die wichtigen Funktionen, mit denen das Programm überhaupt starten kann. Dann aktiviert man nacheinander die Funktionen und guckt, wann der Fehler wieder auftaucht. Das Spiel konnte wieder starten, als ich den Spiele-Manager raus genommen habe. Der Spiele-Manager ist ein internes Objekt, welches die Level-Übergänge macht, das Level bei dem Spieler-Tod neu startet und viele andere, ähnliche Aufgaben übernimmt. Aha, wenn das Spiel wieder läuft, wenn er deaktiviert ist, dann macht er also alles kaputt. Ich guckte mich in seinem Code um und fand diese Stelle:

if (keyboard_check_pressed(vk_escape)) {

part_type_destroy(global.particleDust);
part_system_destroy(global.pSystem);

}

game_end();

Nun, zur Erklärung: Ein Programm, egal ob Java, C++ oder andere Programmiersprachen, geht immer jede Zeile (die meist mit einem Semikolon endet) durch und führt jede Anweisung nacheinander aus. Es gibt dann noch besondere Konstrukte, wie Schleifen. Diese beginnen meisten mit Wörtern wie ‘do’, ‘for’ oder ‘while’ und es wird ein Code-Block solange wiederholt, bis eine bestimmte Bedingung erfüllt ist. Oder if-Abfragen, beziehungsweise Verzweigungen. Dabei wird ein Code-Block nur dann ausgeführt, wenn eine bestimmte Bedingung eintrifft. Wenn wir uns das obige Beispiel angucken, dann haben wir eine solche if-Abfrage. In der Klammer steht die Bedingung keyboard_check_pressed(vk_escape), die überprüft, ob die Escape-Taste gedrückt wurde. Der Code-Block zwischen den geschweiften Klammern wird dann nur ausgeführt, wenn die Escape-Taste gedrückt wurde. Erinnert ihr euch noch an den vorherigen Absatz, in dem ich erwähnte, dass ich das Spiel beenden wollte, wenn man die Escape-Taste drückt? Dieser Code-Schnipsel übernimmt die Aufgabe. Wenn wir uns den Code-Auschnitt aber genauer angucken, fällt uns ein ganz doofer Fehler auf: game_end(), welches das Spiel beendet, steht außerhalb der if-Abfrage von keyboard_check_pressed(vk_escape). Das bedeutet, game_end() wird nicht ausgeführt, wenn der Spieler auf Escape drückt, sondern es wird immer ausgeführt. Deswegen hat sich das Spiel immer beendet, nachdem ich es gestartet habe. Und deswegen gab es auch keine Fehlernachricht, weil es natürlich kein Fehler war – das Spiel hat immer das gemacht, was es tun sollte, nämlich das Spiel wieder zu beenden. Willkommen in der magischen Welt der Programmierung und der Softwareentwicklung, in der solche Fehler gerne passieren können. Für den Fehler habe ich jedenfalls zwei Stunden gebraucht.

Glücklicherweise waren wir aber sehr gut in der Zeit und mussten uns trotz dieser Überraschung nicht zu sehr stressen. Das erste Level, welches nach dem Tutorial kam, musste zwar auch an einigen Stellen angepasst werden, wurde aber rechtzeitig fertig. SmashArist produzierte fleißig weitere Sprites und Animationen. Da Kmspirit und ich nicht mehr viel zu tun hatten, haben wir einen Titel- und Credit-Screen erstellt. Insgesamt hatten wir also ein fertiges, in sich abgeschlossenes Spiel. Hätten wir mehr Zeit gehabt, hätten wir noch mehr Content erstellen können. Also weitere Levels und neue Spielelemente, wie Gegner-Typen, für die sich die natürlichen Feinde von Flughörnchen geeignet hätten – also Schlangen beispielsweise (Lob an Kmspirit, die grundsätzlich zunächst über Flughörnchen recherchiert hatte). Oder Windböen, die dem Spieler Auftrieb beim Gleiten verleihen könnten. Zu meiner Schande muss ich auch gestehen, dass ich genau zwei Bugs nicht fixen konnten, die beide aber keine Game-Breaker sind: Zum einen könnte der Sprite-Wechsel von Wand-Sprung nach rechts zu links (oder umgekehrt) dafür sorgen, dass der Spieler wegen einer Verschiebung der Hitboxen in der Wand landet. Zum anderen gibt es ein Problem, wenn der Spieler auf der Plattform steht, die wir als Sicherheitsnetz im Tutorial eingebaut haben – die Lauf-Animation wird nicht abgespielt und der Spieler kann nicht von der Plattform fallen, sondern schwebt in der Luft.

Leider konnte ich auch nicht mehr unser Mac-Helferlein erreichen, wodurch ich nur eine Windows-Version erstellen und auf itchio hochladen konnte (eine Mac-Version habe ich aber an Jozzua und Kmspirit nachgereicht). Es war weniger als eine Stunde übrig, als der nächste Schreck folgte: Ich habe die Windows-Version zwar hochgeladen, aber keiner konnte auf die Seite zugreifen. Was war da los?! Naja, ich musste die Itchio-Seite für das Spiel einfach nur auf ‘public’ schalten. Damit hatten wir es geschafft und unser Spiel ‘Parkcorn’ rechtzeitig vor Deadline eingereicht.

Die Arbeit hat mir sehr viel Spaß gemacht und ich würde gerne wieder an einem Game Jam teilnehmen. Mein persönliches Ziel, ein fertiges und in sich komplettes Spiel abzuliefern, habe ich erreicht und ich konnte einige neue Sachen lernen, wie beispielsweise das Partikelsystem. Gerne hätte ich noch die beiden Bugs behoben und mehr Content geboten, aber dazu reichte das Zeitlimit einfach nicht. Mit mehr Zeit hätte man auch am Balancing arbeiten können, da ich auch nicht so ganz mit der Platzierung der Kollisions-Boxen zufrieden bin und die Stacheln hätte man vielleicht gefährlicher aussehen lassen können. Erschwert wurde das Projekt auch dadurch, dass wir alle in unterschiedliche Zeitzonen arbeiteten und die 9 Stunden Zeitunterschied waren durchaus spürbar. Es hätte auch geholfen, wenn wir alle auf einer Plattform (in dem Fall Game Maker 2) und mit demselben System gearbeitet hätten und wenn man sich lokal und persönlich gegenüber gestanden hätte. Aber das sind alles insgesamt nur Kleinigkeiten, die die Arbeit lediglich einfacher gemacht hätten, wobei nichts davon ein wirklicher Deal-Breaker war. In jedem Fall war ich sehr glücklich, mit solch talentierten Menschen gearbeitet zu haben, die unglaublich gute Sachen erstellt haben.

Die Windows- und Mac-Version kann hier auf Itch.io runterladen. Eine Installation ist nicht nötig. Hier findet man ein Video über die besten Spiele des GMTK Game Jam 2018.