Warum ich bei Godot gelandet bin

Meine Reise der Spieleentwicklung

Hallo, mein Name ist Peter und während ich diesen Artikel schreibe bin ich 30 Jahre alt. Seit ich als Kind mit den ersten Computerspielen auf meinem 80286 Tower PC mit DOS in Berührung kam, habe ich mich sehr für Computerspiele interessiert. Als ich 13 Jahre alt war, bekam ich mein erstes Programmierbuch “Delphi für Kinder” geschenkt. Meine Eltern waren nicht sehr erfreut darüber, dass ich viel Zeit mit dem Computer verbrachte und nur Spiele spielte. Sie sagten mir, ich solle etwas aus meiner Leidenschaft machen, und vielleicht wäre Programmieren etwas, das mir gefallen würde – und sie hatten Recht!

Ich fing an, das Buch immer wieder zu lesen, bis ich ein erstes Verständnis von OOP und der Entwicklung kleiner Anwendungen hatte. Ich begann, mich in genesis3D mit Bindings für Delphi zu vertiefen, um meine eigenen 3D-Computerspiele zu entwickeln – woran ich natürlich scheiterte, weil die Herausforderungen viel zu groß waren. Dann entwickelte ich mit C++, DirectDraw und später Direct3D, bis ich mein Studium der Informatik begann. Aber das war alles nur Prototyping und keine fertigen Produkte. Der letzte, größte Plan war, eine 3D-Schlagzeugsimulation zu entwickeln, bei der man sein eigenes Schlagzeug bauen und es automatisch Schlagzeuglinien aus einer Tabulatur abspielen lassen kann. Alles in C++, Direct3D 9, so dass ich die 3D- und 2D-UI-Engine komplett selbst entwickeln musste – auch das war zu ambitioniert.

Nach meinem Studium arbeite ich nun für t2informatik, einem Dienstleister für Softwareentwicklung aus Berlin. Und natürlich hat sich meine Einstellung von “reines C++ ist das Beste, denn man kann damit alles machen” zu “nimm die Sprache, die für den Zweck am einfachsten ist” geändert. Ein Ansatz, der mir heute als professioneller C#/.NET-Entwickler für Geschäftsanwendungen in Medizin, Pharma, Asset Management und serviceorientierte Architekturen im Allgemeinen hilft.

Die Spiel-Engine-Hölle

Ich liebe es, Spiele mit verschiedenen Techniken auszuprobieren, um zu sehen, wie sie mir helfen, meine Probleme zu lösen. Meine Erwartung ist, dass das Framework oder die Spiele-Engine, die ich benutze, meine immer wiederkehrenden Probleme lösen muss, sonst bin ich nicht überzeugt, meine Freizeit damit zu verschwenden. Ich bin kein Student mehr und möchte Spaß haben und nicht schon wieder ein eigenes UI Framework bauen, weil mir die Engine oder die verwendete Bibliothek keine passende Lösung bietet.

Im Laufe der Zeit habe ich begonnen, mehrere Bibliotheken auszuprobieren. Die allererste war löve2d. Es ist eine schöne, kleine 2d-Spiele-Engine, die auf Lua basiert. Sie ist großartig für Spiele-Jams und eignet sich auch für ziemlich große Titel. Für den einfachen Gebrauch bietet sie viele grundlegende Werkzeuge für Grafik, Sound, Physik und I/O an. Sie lässt sich einfach und flexibel benutzen, so dass ich einige Spiele als Prototyp entwickelt habe und damit ziemlich erfolgreich war, wie der folgende Spiele-Prototyp zeigt:

Dann begann ich, eine der größeren Engines zu verwenden, die erste war natürlich Unity. Vor einigen Jahren war es meine bevorzugte Wahl für das Prototyping, weil ich den Workflow mag, alles in C# ist und es natürlich den sehr nützlichen Asset Store gibt.

Als nächstes warf ich einen sehr kurzen Blick auf Unreal Engine. Um es direkt zu sagen: überhaupt nicht mein Fall. Warum muss man diese Blaupausen verwenden? Wirklich, hauptsächlich C++? Das war mein erster Eindruck, und das war es dann auch schon. Ich hatte von Beginn an das Gefühl, dass diese Engine nicht das Richtige für mich ist. Sie bietet für große Entwickler-Studios immense Vorteile und Produktivität, aber nicht für meinen Ansatz “Ich möchte Spaß haben ohne große Mühe”. Möglicherweise werde ich irgendwann in der Zukunft nochmals einen Blick auf die Unreal Engine werfen und vielleicht ändert sich dann auch meine Meinung. Mal schauen. 😃

Kurz zusammengefasst: Ich bin zu bequem, um Bibliotheken wie löve2D oder MonoGame zu benutzen, und es stört mich, dass viele Bibliotheken unterschiedlichste Ansätze und Funktionsumfänge haben. Die großen Spiele-Engines befriedigen nicht meine Sichtweise der Spielentwicklung oder gar des Prototypings. Deshalb habe ich in den letzten Jahren fast keine Spiele implementiert. Aber ich suchte weiter …

Mein erster Kontakt mit der Godot Engine

Von Godot Engine habe ich das erste Mal auf spieleprogrammierer.de, einem deutschen Spieleprogrammierer-Forum, gelesen. Es gab und gibt viele Diskussionen darüber, welche Engine man wählen sollte, und jemand erwähnte Godot Engine für Prototyping. Ich war neugierig und schaute mir das Thema an, auch wenn ich zu Beginn noch nicht überzeugt war. Ich lud die aktuelle Version (2.6, denke ich) herunter und probierte einige der Tutorials aus.

Das Konzept von Godot Engine verwirrte mich etwas, weil es sich sehr von jeder Engine und jedem Framework unterschied, das ich jemals benutzt hatte. Ich war so verwirrt, dass ich sogar aufgehörte, Godot zu benutzen, sondern mich regelmäßig auf die Suche nach Updates machte. Dann las ich, dass Godot eine komplette Überholung der 3D-Engine und der C#-Unterstützung erhalten würde. Ich begann, die Entwicklung der Godot-Engine auf github zu verfolgen. Mir gefiel, wie aktiv und offen die Community war und wie sich alles immer weiter verbesserte. Ein wirklich beeindruckendes Beispiel, das zeigt, wie cool Open Source ist und dass es ein echter Gewinn für alle sein kann.

Wie Godot mich überzeugte

Als Version 3.0 der Godot Engine herauskam, war ich bereit, es eine Woche lang auszuprobieren. Und ich wurde nicht enttäuscht. Ganz im Gegenteil: ich war begeistert und bin es immer noch. Godot ist eine fantastische 3D-Engine! Wenn ich Ihnen einen Tipp geben darf: probieren Sie sie aus. Die verbesserte Dokumentation und die deutlich bessere User Experience vermittelten mir von Beginn an das Gefühl, meine Zeit sinnvoll zu investieren.

Nachdem ich etwas rumgespielt hatte, wollte ich als nächstes mit einem realen Anwendungsfall die Engine und den Editor testen. Ich hatte ein altes Spiel aus einem Game Jam, das ich mit MonoGame und C# bei einem Wettbewerb – zwei Entwickler programmieren in 20 Stunden ein Spiel – am Wochenende implementiert hatte. Ich begann, das Spiel nach Godot zu portieren, um zu sehen, wie es funktioniert und ob es die Probleme automatisch löst, die ich selbst in C# lösen musste. Und ich war überrascht: Es funktionierte super!

Das System half mir, alles in logische Szenen zu strukturieren, ganz so wie ich es mir vorgestellt hatte, ohne jeglichen Nachteil. Die Physik-Engine funktionierte perfekt für meine Anwendungsfälle, und das Animationssystem ist ein so schönes, einfaches Werkzeug. Der erste “warum-zum-Teufel-ist-das-so-einfach”-Moment für mich war das Y-Sortierproblem: In meinem Spiel habe ich eine DepthSortManager-Klasse implementiert, die alle Instanzen kannte und sie in der richtigen Reihenfolge sortiert und rendert. Ich dachte, dass ich dies auch in Godot implementieren muss, aber ich fand heraus, dass es dafür einen Knoten gibt. Alles was ich tun musste, war alle Objekte als Kind zu platzieren. Fertig. Das war der Zeitpunkt, an dem ich begann, so viel wie möglich über Godot herauszufinden – und das ist es, was ich bis heute tue.

Gdskript vs. C#

Etwas, das viele Entwickler von Godot abhalten könnte, ist die benutzerdefinierte Skriptsprache namens Gdskript (Godot-Skript). Um ehrlich zu sein, dachte ich anfangs auch, dass das etwas völlig Unnötiges ist, bis ich eine Erklärung des Hauptentwicklers Juan Linietsky las. Sein Hauptargument war, dass die Integration von Skriptsprachen schwierig ist und dass man sich bei der Wahl von Programmiersprachen wie Lua mit allem befassen muss, was nicht zu seinen Anwendungsfällen passt, z.B. Multi-Threading und benutzerfreundliche Integration der funktionalität der Engine. Zufällig erging es mir genau so, als ich versuchte, Lua als Skriptsprache für mein System zu verwenden, um es an mein C#-Entitiy-Komponenten-System anzubinden. Juan Linietsky hatte Recht.

Gerne wird darüber hinaus gesagt, dass Gdskript eine sehr einfache Sprache ist, mit der man in nur wenigen Stunden viel erreichen kann. Tatsächlich kann ich das bestätigen. Es ist wirklich einfach, sich in die Sprache einzuarbeiten, und auch die Unterstützung und Integration in den Code-Editor von Godot ist sehr gut. Wenn Sie es ausprobieren, bin ich mir sicher, dass Sie ähnliche Erfahrungen machen werden. Und falls Sie wirklich nicht zufrieden sind, dann nutzen Sie einfach wie gehabt C#.

Aktuelle Entwicklungstrends von Godot

Godot 4.0 verspricht weitere große Verbesserungen, auf die ich schon warte. Voraussichtlich wird die neue Version folgende Neuigkeiten bieten:

• Vulkan Renderer
• Echte Mehrfenster-Unterstützung für Dialoge und Dockfenster
• Überarbeitung des Gdscript hinsichtlich Performance
• Verbesserungen der Navigation mit Kollisionsvermeidung

Aus meiner Sicht sind das die wichtigsten Merkmale von Godot Engine 4.0. Aber natürlich wird es noch viel mehr geben. Wenn Sie einen Blick auf github werfen und/oder einigen Leuten wie bspw. Juan Linietsky, Rémi Verschelde, dem Projektmanager von Godot Engine, oder Godot Engine auf Twitter folgen, sollten Sie leicht auf dem Laufenden bleiben können.

Fazit

Ich habe diesen Artikel geschrieben, weil ich Godot wirklich klasse finde. Ich liebe die Art der Entwicklung, die Denkweise der Köpfe hinter dem Produkt, und die Idee, wie es sich in Zukunft entwickeln soll. Ich kann nur jedem ans Herz legen, der sich mit der Entwicklung von Spielen beschäftigt, dass er sich ernsthaft mit dem Thema beschäftigt und mit der Engine herumspielt. Der Aufwand besteht nur darin, eine etwa 50mb kleine exe von der Website herunterzuladen und es kann losgehen! Die wenigsten Produkte sind so schnell startklar.

Zum Start würde ich empfehlen, mit einer kleiner Projektidee in 2D zu beginnenn, Godot zu nehmen und einfach zu versuchen, Probleme damit zu lösen. Ich verspreche Ihnen, dass Sie nicht enttäuscht sein werden. Und falls doch, wenden Sie sich an die Community. Meistens führt das zu einem von zwei Ergebnissen: Sie haben etwas übersehen und es ist leicht zu lösen. Oder sie sind auf ein Problem oder einen neuen, interessanten Anwendungsfall gestoßen, und helfen den Godot Engine Entwicklern bei der Weiterentwicklung. Win-Win sozusagen.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Wir suchen Softwareentwickler. Berufseinsteigerinnen, Entwickler mit einigen und Expertinnen mit vielen Jahren Erfahrung.

Ich könnte einen weiteren Artikel schreiben, in dem ich nur über die Merkmale, die architektonischen Aspekte und den allgemeinen Entwicklungsprozess der Engine selbst berichte. Gerne möchte ich Sie stattdessen auf einen Blogbeitrag auf medium aufmerksam machen. Er beschreibt viele dieser Punkte sehr gut.

Peter Friedland hat hier im t2informatik Blog einige weitere Beiträge veröffentlicht:

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.