Hallo Freunde und herzlich willkommen zu meinem ersten Devlog über 'Cavemen'. (Eigentlich zu meinem allerersten Devlog überhaupt!) 'Cavemen' ist der Arbeitstitel eines Prototyps für ein 2D 8-Bit Roguelike RPG Game, das ich derzeit entwickle. Noch steht nicht fest, ob dieses Spiel eine Zukunft hat, aber ich möchte meine Erlebnisse hierzu festhalten und allen Interessierten einen tiefen Einblick hinter die Kulissen des Gamedev geben. Wenn ihr euch gefragt habt, wie es ist ein Game Developer zu sein, welche Gedanken und Gefühle man dabei hat und welchen Stolpersteinen man während der Entwicklung begegnet, dann seid ihr hier genau richtig!

Die ersten Gehversuche

Wer meinen Twitter Account aufmerksam verfolgt, dem dürfte aufgefallen sein, dass ich, vor drei Monaten, die ersten PICO-8-Screenshots zu diesem Prototyp gepostet habe. - Darüber habe ich in einem anderen Blogpost bereits erzählt. Die Kurzfassung: ich bin in der Zeit von Pokemon & Co aufgewachsen und mein Lieblingsgenre sind RPG's in einem Low-Res-Pixel-Style. Seit langer Zeit möchte ich so ein Spiel selbst entwickeln. Bisher hat das nicht geklappt, aber ich denke, das liegt nicht am Mangel an technischen Fähigkeiten, sondern viel eher daran, dass ich meinen Stil noch nicht gefunden und noch keine funktionierende Routine, in der Entwicklung von Spielen, habe. Als ich PICO-8 entdeckt habe, wurde mein Wunsch, ein eigenes Game zu schreiben, auf's neue entfacht!

Nachdem ich einige Sprites fertig hatte, wollte ich diese natürlich direkt ausprobieren. Ich began zu experimentieren. Nach einigen Stunden, hatte ich drei kleine Maps und fünf Charaktere die sich darauf frei bewegen konnten. Aus meinen früheren Berührungspunkten mit der Spieleentwicklung, weiß ich nur zu gut, wie schnell man sich mit einem Projekt überschätzen kann. Ich beschloss daher die Sache klein zu halten und aus dem RPG zunächst ein einfaches Roguelike zu machen. Folgende Ziele hatte ich mir gesetzt:

  • Jeder Spieler hat einen Zug und während dieser ihn ausführt, warten die anderen (turn based)
  • Bisher waren meine drei Maps handgemacht. Die Dungeons (Level) sollten nun prozedural generiert werden, wie es sich für ein echtes Roguelike gehört (außerdem dachte ich, dass das leichter zu realisieren wäre und viel Zeit sparen im Nachgang würde - ein Irrtum, wie sich später herausstellte)
  • Zunächst keine konkrete Storyline, einfach nur auf Erkundung der Dungeons ausgerichtet

Zuerst sollten die Dungeons dran sein. Also programmierte ich einen simplen Generator, der Räume erstellen und Boden-, Wand- und Abgrund-Tiles platzieren konnte. Das stellte sich als schwieriger heraus, als ich zunächst angenommen hatte. Wie es scheint, ist das Thema, Procedural-Map-Generation, eine Wissenschaft für sich und zu allem Übel habe ich so etwas noch nie programmiert. Im Internet gibt es eine Menge Informationsmaterial dazu, aber das lässt sich nicht einfach 1:1 übertragen. Um einen wirklich guten Dungeon-Generator zu programmieren, braucht es viel Erfahrung und vor allem Zeit. Moonman von Ben Porter, mit knapp fünf Jahren Entwicklungszeit, ist das beste Beispiel dafür! Ich liebe dieses Game und verfolge seinen Devlog seit einiger Zeit. Ich habe ihn einmal gefragt, wieviel Code er nach all den Jahren für Moonman angehäuft hat. Ben's Antwort kam prompt:

Umstieg auf eine andere Game-Engine - Home Sweet Home

OMG! 120.000 Zeilen Code!!! 😱 Nichts, dass man eben mal aus dem Ärmel schüttelt. Selbst wenn mein Generator kleiner und einfacher werden sollte, so war er immer noch viel zu unzuverlässig. Angesichts des (scheinbar) unüberwindbaren Problems, beschloss ich zwei Sachen zu unternehmen: (1) Ich musste PICO gegen eine bessere Engine tauschen, die mir nicht so viele Einschränkungen auferlegen würde - eine offensichtliche Alternative war Codea. (2) Ich musste den Generator entweder ganz aufgeben oder ihn so lassen, wie er ist und manuelles Eingreifen ermöglichen. In diesem Fall müsste ich einen eigenen Map-Editor schreiben!

Obwohl alles in PICO-8 angefangen hat, blieb es nicht die Game-Engine meiner Wahl. Wenn ich an die mögliche Zukunft des Spiels dachte, konnte PICO den Umfang einfach nicht stemmen. Außerdem war ich schon immer eng mit Codea verbunden und kenne mich darin sehr gut aus! Letzteres ist die wichtigste Voraussetzung für eine Engine, um damit Prototypen (oder gar komplette Games) zu erstellen. Was Prototypen sind und wofür man sie benötigt, erfahrt ihr in diesem höchst interessanten Artikel von Laurent Victorino.

Ich hatte also die Engine gewechselt. Die Idee des Dungeon-Generators wurde vorerst aus dem Sinn verbannt und vom ersten Prototyp, den ich in PICO erstellt hatte, blieben nur noch die Sprites, die ich zunächst aus PICO herausbekommen musste, um sie in Codea verwenden zu können. Um das zu bewerkstelligen habe ich mir einen Exporter geschrieben. Zurück in Codea, wieder bei Null, hatte ich gute Lust diesmal alles perfekt zu machen. Wenn es nach mir ginge, würde ich am liebsten PICO-8's Pixel- und Map-Editor in Codea replizieren und könnte damit genauso wie in PICO, nur eben ohne Limitationen, arbeiten. Aber das überstieg bei weitem den Umfang des Projekts und würde die Entwicklungszeit enorm verlängern. Einen Map-Editor brauchte ich dennoch.

Developer Tools: Open-World Map-Editor

Wenn ich schon dabei wäre, würde ich ihn auf keine feste Map-Größe beschränken, sondern offen gestalten. Die Map kann also so groß sein, wie sie will (Open-World) und der Editor kümmert sich um's dynamische Erstellen und Nachladen von Tiles. Im besten Fall lässt sich der Editor für jedes andere Pixel-Game wiederverwenden und die Map kann auf beliebige Arten interpretiert werden. So könnte man, beispielsweise, Platzhalter Tiles in die Map setzen, die im Spiel zu Dynamic Lights, Constraints oder Trigger Objekten umgewandelt werden können. Im Editor wären solche Platzhalter nur visueller Natur. Andere Tiles wären Artwork. Und so weiter... Ein wahnsinniges Vorhaben, aber noch im Bereich des Möglichen (zumindest in greifbarerer Nähe als der Dungeon-Generator von Moonman)! Wenn man für den Map-Editor eine clevere Datenstruktur erfindet, so könnte er im Grunde sehr einfach sein und dennoch sehr mächtig und vielseitig. Aber genau hier liegt der Knackpunkt!

Meine Idee für den Editor ist in Grundzügen die folgende:

  • Der Editor bekommt nur ein einziges Spritesheet übergeben. Codeas Maximum für Texturen liegt, meines Wissens nach, bei 2048x2048 Pixel. Wenn ein Spiel nun Tiles, in einer Auflösung von 32x32 Pixel, verwendet, hätte man auf dem Spritesheet Platz für 4.096 Tiles. (In meinem Fall sind es, bei 8x8px, sogar 65.536 Tiles!) Für die meisten Spiele wäre das wohl mehr als ausreichend, selbst wenn man die Platzhalter Tiles einbezieht. Und wenn nicht, kann man den Editor immer noch erweitern, damit er mit mehreren Spritesheets unterstützt.
  • Der Editor kann Maps von unendlicher Größe erstellen und anzeigen (Open-World). Das hängt natürlich vom Speicherplatz des Gerätes ab. Das Laden der erstellten Map geschieht automatisch und dynamisch. D.h. es wird nur der sichtbare Teil der Map geladen.
  • Das Spritesheet beinhaltet Tiles für das Artwork und spezielle Platzhalter Tiles, die später im Spiel zu besonderen Objekten werden (Lichter, Aktionen, etc). Um dem Editor mitzuteilen welche Tiles speziell sind, kann man diese Tiles einfach mit einem Flag markieren. Im Übrigen kann man mit Flags auch Ebenen simulieren. Beispiel: alle Tiles mit einem Flag '13' würden automatisch zu einer 'Ebene' zusammengefasst. Technisch wäre es keine Ebene, aber aufgrund des Flags könnte man es so interpretieren. Jedes dieser Tiles kann nun durch eine bestimmte Klasse initialisiert werden und aufgrund der Klasse weiß das Spiel wie sich diese Tiles verhalten. Wäre jedes Tile ein Enemy (Gegner Spieler) dann würde die Klasse Enemies jedes Tile in ein Objekt mit Fähigkeiten konvertieren.

Mit diesen Features im Kopf, habe ich begonnen den Editor zu implementieren. Aus irgendeinem Grund, habe ich beschlossen mit dem User Interface zu beginnen. Das war kein besonders kluger Schachzug! Codea hat, selbst auf einem iPad Pro, sehr wenig Platz und so muss man viel hin und her scrollen, wenn das Projekt größer wird. Allein die UI des Editors nahm etwa 1000 Zeilen Code in Anspruch! Wenn man bedenkt, dass hierbei noch nicht einmal etwas funktioniert, ist das enorm viel. Zu meinem Unglück, hatte ich einige Klassen und Hilfsfunktionen (Kameras, Animierte Sprites, Mathematische Funktionen, etc) für den Editor, aus alten Codea-Projekten importiert habe, um nicht völlig bei Null anzufangen. Viele Methoden dieser Klassen wurden gar nicht benötigt und manche waren nicht für so eine Aufgabe ausgelegt und wurden deshalb in der nächsten Klasse wieder überschrieben. Deshalb quoll der Editor schon bald, wie Hefeteig, auf. Ein Re-write stand demnach kaum mehr außer Frage.

Und noch einmal, weil es so schön war!

Es gab zwar den einen oder anderen Anzeige-Fehler beim Malen von Tiles, aber zu diesem Zeitpunkt hätte ich den Editor bereits für das Game verwenden können. Viele Entwickler schreiben Tools von kurzer Hand, wissen über ihre Schwachstellen bescheid und arbeiten einfach damit (siehe DelvEdit des Spiels 'Delver'). Leider ist das keine Option für mich. Ich kann mich mit Bugs einfach nicht anfreunden! 😔 Zudem hatte ich ein Problem mit dem Rendering, weil ich fand, dass es nicht besonders performant und durchdacht war. Und so kam es, wie es kommen musste: ich began das Monster umzuschreiben. Ein kompletter Rewrite des Editors.

Abschlussgedanke

Der Rewrite wirft mich im (nicht vorhandenen) Zeitplan zurück, dennoch habe ich wieder einiges gelernt und hoffe, dass ich nie wieder die selben Fehler mache. Gamedev ist eben nichts für Nasenbohrer, weshalb ich kaum Menschen verstehen kann, die selbstständige Spieleentwickler werden. Wie schaffen sie es? Oft kommt man nur mühselig voran und kann nicht wirklich etwas planen - und Zeit ist bekanntlich Geld. Woher nehmen sie also das Geld um sich jahrelang, Vollzeit, einem Projekt zu widmen? Hm...

In diesem Sinne verabschiede ich mich von euch. Bis zum nächsten Eintrag!