Um meine Faszination für das „Spiele-selber-bauen“ zu erklären muss ich aber zunächst mit drei Spielen anfangen. Ich liebe die Spiele von Zachtronics und den Höhepunkt dieser Spiele stellt für mich OpusMagnum dar. In Opus Magnum geht es darum kleine Maschinen zusammen zu bauen, die nach bestimmten Regeln aus bestimmten Elementen bestimmte Moleküle herstellen. Schon in diesem Spiel fand ich es unendlich faszinierend meinen eigenen, relativ komplexen Maschinen zuzugucken und sie dabei zu beobachten wie sie genau das tun was sie sollen. Ich liebte dieses befriedigende Gefühl längere Zeit an einer Maschine getüftelt zu haben und sie dann irgendwann laufen zu sehen.
Nach Opus Magnum wollte ich gerne mehr davon haben und bei der Recherche stieß ich auf Screeps. Dabei handelt es sich um ein Sandbox MMO, dessen Spielmechanik darin besteht die AI der eigenen Einheiten zu programmieren, die dann wiederum gemäß der Programmierung handeln, auch wenn ich selbst offline bin. Von der Spielidee war ich völlig geflasht: „Meine eigenen Einheiten Programmieren und ihnen zugucken wie sie immer komplexere Aufgaben erledigen. Später zurück kommen und sehen was sie in der Zwischenzeit alles tolles bewerkstelligt haben“ so dachte ich. Leider nutzt Screeps JavaScript. Ich habe in der Schule ein bisschen Borland Pascal gelernt und im Studium mal ein Semester lang C++ gelernt, bin also durchaus Programmier-affin, aber zu JavaScript habe ich leider nicht so schnell einen Zugang gefunden wie ich mir erhofft habe. Und das zu lernen, in einer Umgebung voller Cracks, die das wahrscheinlich besser sprechen, als ihre Muttersprache war mir dann doch zu scary. Also gab ich das Projekt Screeps wieder auf, trauerte der Idee aber immer mal wieder nach.
Den Ausschlaggebenden Punkt mich selbst der Spieleentwicklung zuzuwenden gab schließlich Slay the Spire. Was habe ich dieses Spiel geliebt. Die unendlichen Möglichkeiten immer wieder ein neues, komplett anderes Deck zu bauen. Jeder Durchgang, der anders ist als der davor. Besonders fasziniert hat mich aber mit welch relativ einfachen Mitteln dieses Spiel einen solch immensen Wiederspielwert erreicht. Sowas wollte ich auch machen. Slay the Spire, aber wie Bard’s Tale, also als Partyrollenspiel mit unterschiedlichen Karten für jede Charakterklasse, die nochmal unterschiedliche Interaktionen miteinander haben, ein bisschen wie die Elemente in Divinity Original Sin. Das wollte ich machen. „Kann ja nicht so schwer sein“ dachte ich Trottel und begab mich auf die Suche nach einer game engine, die mich schlussendlich bei Godot landen ließ.
Godot ist eine Open Source game engine mit einer sehr aktiven Community und einer eigenen script Sprache, ähnlich Python, aber Objektorientiert. Ich lud mir Godot also runter, öffnete es, und raffte erst mal gar nichts.
Also tat ich das was Menschen in meinem Alter oftmals tun wenn sie nichts verstehen: Ich kaufte mir ein Buch: Godot Engine Game Development von Chris Bradfield. Was für ein Kauf! Mit Hilfe dieses Buches baute ich in kürzester Zeit Spiele nach wie Dodge the Creeps oder SpaceRocks
Viel wichtiger aber war: ich lernte in kürzester Zeit wie Godot funktioniert und wie einfach GDscript ist. Nach 3 Projekten in dem Buch fing ich an, mein eigenes Spiel zu erstellen.
Natürlich kam ich nicht weit, aber schon mein erstes Spiel lehrte mich einige wichtige Lektionen:
1. Mit Godot bin ich in der Lage, in relativ kurzer Zeit Lösungen für verschiedene Probleme zu finden und einzelne Spielabschnitte so zu realisieren, wie ich mir das vorstelle
2. Coden macht Spaß
3. Code tendiert dazu in relativ kurzer Zeit relativ komplex zu werden
4. Mit dem Ergebnis, dass ich in relativ kurzer Zeit meinen eigenen Code nicht mehr verstehe.
Außerdem stellte ich fest, dass das was ich mir zuerst toll vorstellte wahrscheinlich keinen Spaß machen wird. Also stellte ich das Projekt ein und überlegte mir was Neues. Mir war klar: Diesmal muss ich von Anfang an darauf achten, keinen Spaghetti-Code zu schreiben. Außerdem wollte ich das Projekt überschaubar halten. Der naheliegende Gedanke war dann natürlich: Civilization, aber mit Karten und in kleiner. Also legte ich los, der Arbeitstitel war CardCiv
Mit CardCiv hatte ich sehr lange sehr viel Spaß, das Spiel hatte schon eine ganze Menge spannender Elemente:
- eine prozedural erstellte Karte
- eine sich gut anfühlende Mechanik wenn man mit der Maus über die Karten gleitet: jede Karte hebt sich und senkt sich wieder wenn der Mauszeiger weiter wandert. Daran habe ich lange gesessen.
- Maussensitive Kartenfelder, die beim mouse over den Namen und die Funktion des Feldes angezeigt haben
- eine funktionierende Drag and Drop Mechanik, um die Karten zu spielen und eine darauf reagierende map (Gebäude werden gebaut, können wieder zerstört werden, etc.)
- ein funktionierendes Rohstoffsystem
- angreifende Gegner mit unterschiedlichen Mechaniken
- ein gut lesbares user interface
Leider war das Spiel bis dahin wieder so komplex, dass ich das Projekt aufgab. Damals war mir noch nicht klar wie mächtig Signale sind und wie ich sie sinnvoll nutze. Daher hatten die einzelnen Elemente zu viele Verzahnungen miteinander und ich hatte ein System geschaffen, das drohte zusammen zu brechen, wenn ich auch nur ein kleines Rädchen änderte. Ich traute mich nicht mehr daran rumzufuhrwerken, da ich auf das bisherige Ergebnis ein bisschen stolz war und ich wollte es nicht kaputt machen. Außerdem tat ich mir sehr schwer eigene Grafiken zu erstellen und Godot hat keinen Asset Store. Zudem dachte ich mir: wenn ich schon programmieren lerne, dann kann ich auch gleich eine Sprache lernen die mir nutzt, wenn die AFD an die Macht kommt und ich das Land verlassen muss. Diese Überlegungen führten mich also dazu zu Unity zu wechseln.
Gleiches Procedere wieder: Unity runterladen, öffnen, überwältigt sein, Buch kaufen und mit Hilfe von 1-2 Projekten und einem Kurs auf Udemy zumindest grundlegend C# lernen. Auch hier ließ ein erstes eigenes Projekt nicht lange auf sich warten. Diesmal sollte es eine Variation von „Die Gilde“ werden. Aber mit Karten!
Nachdem ich mich in Unity reingefuchst hatte war ich zunächst einmal vom hauseigenen Assetstore geflasht. Was es da nicht alles gibt. Für kleines Geld konnte ich dort 3d Modelle aller Art bekommen, weshalb ich beschloss eine Art 3d Draufsicht Welt zu erstellen:
Natürlich wurde auch dieses Projekt irgendwann zu komplex und außerdem merkte ich, dass ich es hasse user interface Fenster zu erstellen. Das ist jedes Mal ein riesiges Gefummel und der Teil der wenig kreativ ist. Meist weiß ich schon, wie es aussehen soll und dann muss ich es aber immer noch mühsam zusammenbauen und dabei immer unterschiedliche Auflösungen im Kopf haben (in meinem Kopf entwickelte ich damals noch immer für eine kritische steam-Kundschaft). Also gab ich das Projekt auf.
Mit Unity zu arbeiten fühlte sich aber unfassbar gut an. Ich hatte mittlerweile 2 Bildschirme. Links war immer Visual Studio auf, um Code zu schreiben und rechts Unity um direkt auszuprobieren und zu testen. Der Workflow fühlte sich dadurch sehr kreativ an und ich kam immer mehr in den Legomodus. Kurz nach Abbruch des aktuellen Projektes stolperte ich über ein kleines Video von Sebastian Lague in seiner Reihe Coding Adventures: https://www.youtube.com/watch?v=r_It_X7v-1E&t=329s Darin stellt er verschiedene Programmierexperimente vor und im konkreten Fall ein kleines Ökosystem mit Hasen und Füchsen, die umher laufen, sich vermehren und Gene weitergeben. Dabei zeigen sich über einen langen Zeitraum, dass sich je nach Start- und Umweltbedingungen bestimmte Gene durchsetzen. Sebastian hat also eine kleine Vererbungssimulation geschrieben und ich dachte mir das versuche ich auch mal.
Dieses Projekt war das Erste, das ich nur für mich entwickelt habe und das ich in dem vollen Wissen entwickelt habe, dass ich es tue, weil es mir Spaß macht es zu tun. Ich wollte nie etwas damit bezwecken, es sollte nie veröffentlicht werden, ich wollte nur wissen, ob es funktioniert. In diesem Projekt habe ich, glaube ich, am meisten gelernt und schlussendlich hatte ich eine Insel, auf der Pflanzen wuchsen, die sich entweder über den Wind oder nach dem Gefressen werden der Karnickel als Ausscheidung vermehren konnten. Ich hatte Kaninchen, die fressen, trinken und sich vermehren wollten und sich je nach ihrem inneren Status Futter, Wasser oder einen Sexualpartner gesucht haben. Sowohl Pflanzen, als auch Kaninchen konnten unterschiedliche Eigenschaften vererben und wenn ich die Simulation eine Weile laufen ließ veränderte sich die Welt, bestimmte Pflanzen siedelten sich eher in den Höhenlagen an, andere eher in der Tiefebene und bei den Kaninchen fingen je nach Startbedingungen bestimmte Eigenschaften an, sich durchzusetzen. Leider gab es einen Bug, der dazu führte dass alle Kaninchen über kurz oder lang ausgestorben sind, so dass ich nie dazu kam, Raubtiere zu entwickeln. Trotzdem werfe ich das Projekt auch heute noch ab und an und schaue meinen Kaninchen zu, wie sie über die Insel hoppeln.
Danach habe ich noch ein weiteres Projekt gestartet, in dem ich mich mit pathfinding und autonom agierenden Lebewesen beschäftigt habe, das aber wieder an meiner Unliebe user interfaces zu designen scheiterte. Doch auch hier hatte ich zwischenzeitlich eine Welt erschaffen, in der autonome kleine Blops umherwandern, sich einen Bauernhof bauen und Felder anlegen – und zwar in einer Art und Weise die so komplex war, dass ich nicht vorhersagen konnte wer was wann wo bauen würde – das finde ich bis heute faszinierend.
All diese Projektchen haben mir aber gezeigt was für ein tolles Hobby Spieleentwicklung sein kann und welch unendlich viele Möglichkeiten die verschiedenen game engines bieten sich kreativ auszutoben, eigene Sachen zu erschaffen und ihnen dann befriedigt zuzugucken und ich hoffe mit meinem kleinen post ist es mir gelungen, dem einen oder anderen dieses tolle Hobby ein bisschen näher zu bringen und hier vielleicht sogar einen kleinen Austausch darüber zu starten.
