Godot 4.1-Update

 (godotengine.org)
1 Punkte von GN⁺ 2023-07-07 | 1 Kommentare | Auf WhatsApp teilen
  • Godot 4.1 ist ein inkrementelles Release nur 4 Monate nach 4.0 und ergänzt neue Funktionen wie verbesserte KI-Navigationsvermeidung und einen abtrennbaren Code-Editor, während es vor allem Stabilität, Performance und Feinschliff verbessert
  • Diese Version behebt mehr als 900 Issues, die bei der Nutzung von Godot 4 gemeldet oder in den Vorab-Releases von 4.1 gefunden wurden, und entstand aus Beiträgen von über 300 Mitwirkenden
  • Eine wichtige Performance-Verbesserung ist die Umstellung des Hinzufügens und Entfernens von Kindknoten auf eine schnelle Hashmap-basierte Methode; dadurch werden komplexe Projekte schneller, allerdings mit Kosten bei einigen seltenen Operationen und beim Node-Speicherverbrauch
  • Scripting- und Editor-Workflows wurden erweitert, unter anderem mit statischen Variablen in GDScript, C# [GlobalClass], GDExtension-Erweiterungen und einem abtrennbaren Skript-Editor
  • Die Migration von 4.0-Projekten auf 4.1 ist im Allgemeinen sicher, aber Nutzer von C# und GDExtension sollten mögliche Inkompatibilitäten sowie Portierung und Neukompilierung vorab prüfen

Überblick über das Godot-4.1-Release

  • Godot 4.1 ist ein Update, das nach 4 Monaten Arbeit seit Godot 4.0 erschienen ist, und setzt die Richtung fort, 4.0 durch häufige inkrementelle Releases zu verbessern
  • Im Mittelpunkt dieses Releases stehen Stabilität, Performance und Finish, daneben enthält es auch neue Funktionen
    • verbesserte KI-Navigationsvermeidung
    • die Möglichkeit, den Code-Editor abzutrennen und auf einem anderen Display zu platzieren
  • Mehr als 900 Issues, die Nutzer bei der Verwendung von Godot 4 gemeldet oder die in den Vorabtests von 4.1 entdeckt wurden, wurden behoben
  • Die meisten mit 4.0 erstellten Spiele und Apps können relativ sicher auf 4.1 migriert werden
    • Nutzer von C# und GDExtension sollten mit einigen Inkompatibilitäten rechnen
    • Vor der Migration ist ein Backup nötig; empfohlen wird, den Projektzustand in einem Versionsverwaltungssystem wie Git zu committen
    • Ein Migrationsleitfaden ist in Vorbereitung
  • Godot 4.1 kann auf der Download-Seite heruntergeladen werden

Community-Beiträge und Entwicklungsfinanzierung

  • Godot ist ein Community-getriebenes Projekt, an dessen Verbesserung des Engines individuelle Mitwirkende beteiligt sind
  • Dank Spenden von Nutzern und Unternehmen konnten in den letzten Jahren einige Kernbeitragende fest angestellt werden, was schnelle Releases ermöglicht hat
  • Die aktuellen monatlichen Ausgaben liegen über den monatlichen Spenden, daher hängt die Entwicklungsfinanzierung weiterhin von großen einmaligen Unternehmensspenden ab
  • Um das Tempo der Godot-4-Updates zu halten und Maintainer einzustellen, die mehr Beiträge prüfen können, werden mehr monatliche Spenden benötigt
  • Neben finanzieller Unterstützung gibt es viele weitere Möglichkeiten, zum Projekt beizutragen
    • detaillierte Bugreports schreiben
    • zum Codebestand beitragen
    • Dokumentation verfassen
    • Guides für die offizielle Dokumentation oder persönliche Websites schreiben
    • Fragen auf Community-Plattformen beantworten und Tipps geben
  • Dieses Release entstand aus Beiträgen von mehr als 300 Mitwirkenden; die vollständige Liste aller Bugfixes und Verbesserungen ist im interaktiven Changelog zu finden

Performance-Verbesserungen

  • Godot-Spiele bestehen aus Node Trees, den grundlegenden Bausteinen für Spielentitäten, und das Hinzufügen sowie Entfernen von Nodes ist im Engine-Betrieb ein sehr häufiger Vorgang
  • In 4.1 wurde der Algorithmus zum Hinzufügen und Entfernen von Kindknoten auf eine schnelle Hashmap-basierte Methode umgestellt, wodurch diese Vorgänge um ein Mehrfaches schneller werden
    • einige seltene Node-Operationen werden etwas langsamer
    • der Speicherverbrauch der Basisklasse Node steigt um 10 %
    • besonders große Vorteile ergeben sich in komplexen Projekten mit vielen Node-Manipulationen
  • Für Szenen wurde experimentelles Multithreading hinzugefügt
    • mit einer neuen Node-Eigenschaft lässt sich steuern, ob Nodes sequentiell oder parallel verarbeitet werden
    • da es noch experimentell ist, sind umfangreiche Tests nötig, um Edge Cases zu finden
    • der Einsatz in der Produktion wird nicht empfohlen
  • Auch beim Multithreaded Loading wurden viele Probleme und Einschränkungen behoben
  • Dem Vulkan-Renderer wurde ein Pipeline-Cache hinzugefügt
    • der bestehende Shader-Cache reduzierte Shader-Kompilierungsruckler, aber die Pipeline-Kompilierung konnte weiterhin Ruckler und lange Ladezeiten verursachen
    • Pipeline-Kompilierungsruckler sind noch nicht vollständig gelöst, aber in Rendering-Backends auf Basis von RenderingDevice können sich die Ladezeiten etwas verkürzen
    • dieser Cache kann in den Projekteinstellungen deaktiviert werden und ist in Godot 4.1 standardmäßig aktiviert
    • da damit nicht alle Ursachen für Hänger behoben sind, wird in zukünftigen Releases weiter daran gearbeitet

Änderungen an der Core Engine

  • Beim Importieren von Modellen in Godot trat häufig das Problem auf, dass Modelle nach hinten zeigten
  • In 4.1 wurden mehrere Änderungen vorgenommen, um dieses Problem zu verringern
    • im Editor wurden die Vorwärts-/Rückwärtsrichtungen der Kamera vertauscht
    • der Funktion look_at() wurde ein Argument hinzugefügt, das Model Space statt der -Z-Achse der Kamera als Vorwärtsreferenz verwendet
    • diese Änderung hilft auch bei der Behebung eines alten Bugs beim Pfadfolgen
  • Godot 4 erhält Frame-Delta-Smoothing
    • dadurch kann die Bewegungsflüssigkeit deutlich verbessert und ein sanfteres Gameplay ermöglicht werden
    • es ist standardmäßig aktiviert
    • es funktioniert nur bei aktiviertem VSync

Scripting-Verbesserungen

  • GDScript

    • bisher musste man Ressourcen oder Autoload verwenden, um Daten zwischen mehreren Instanzen desselben Skripts zu teilen
    • ab Godot 4.1 können statische Variablen erstellt und verwendet werden
    • statische Variablen speichern Daten auf Klassenebene statt pro Instanz, sodass alle Instanzen derselben Klasse denselben Wert teilen
    • dafür wird das Schlüsselwort static vor die Variablendefinition am Anfang des Skripts gesetzt
    • auch die mit Godot 4 eingeführte automatische Dokumentationsgenerierung für benannte Klassen wurde verbessert
    • Enums werden als Typen behandelt, wodurch die erzeugte Dokumentation genauer wird
    • zusätzlich zu Docstrings über Variablen- oder Funktionsdefinitionen können nun auch Inline-Docstrings verwendet werden

  • C#/.NET

    • der Fokus für C# in diesem Release liegt darauf, die funktionale Gleichwertigkeit zu GDScript zu erhöhen
    • in GDScript konnte man einem Skript einen globalen Klassennamen geben, um neue im Editor nutzbare Node-Typen zu definieren
    • ab Godot 4.1 ist das auch in C# möglich, indem dem Dateiobjekt das Attribut [GlobalClass] hinzugefügt wird
    • mit dem Attribut [Icon] kann einer globalen Klasse auch ein eigenes Icon zugewiesen werden
    • allerdings können mit C# erstellte Projekte mit Stand 4.1 noch immer nicht auf mobile oder Web-Plattformen exportiert werden
    • die Unterstützung dafür ist in Arbeit
    • die Lösung dieser Einschränkung hängt wahrscheinlich von der Veröffentlichung von .NET 8 Ende 2023 ab
    • die eigentliche Arbeit an der Unterstützung mobiler und Web-Plattformen könnte erst in der zweiten Hälfte von 2023 richtig beginnen

  • GDExtension

    • Godot bietet eine Technologie, mit der sich Low-Level-Sprachen wie C++ als Skriptsprachen für Spiele nutzen lassen, ohne die Engine neu zu kompilieren
    • GDExtension ist in diesem Release weiterhin noch Beta
    • in 4.1 rücken die Scripting-Fähigkeiten von GDExtension näher an GDScript und C# heran
    • neue Visual-Shader-Nodes können implementiert werden
    • mit GDExtension lassen sich Editor-Plugins erstellen
    • es wurde ein Abwärtskompatibilitätssystem implementiert, damit Code für Godot 4.1 auch bei künftigen API-Änderungen weiter funktioniert
    • allerdings war in 4.1 ein größerer Kompatibilitätsbruch nötig, um zentrale Probleme von GDExtension zu beheben
    • bestehende Godot-4.0-Erweiterungen müssen für 4.1 portiert und neu kompiliert werden
    • zudem wurde erneut viel Architekturarbeit geleistet, um die GDExtension-API künftig erweiterbar zu machen

Editor-Workflow

  • Godot 4 unterstützt bereits mehrere Fenster für Projekteinstellungen, Editoreinstellungen und verschiedene Pop-ups
  • Ab 4.1 lassen sich Dokumente als schwebende Fenster abtrennen, und auch der Skript-Editor inklusive Shader-Editor kann abgetrennt und auf einem separaten Monitor platziert werden
  • Der Editor kann Fensterlayouts nachverfolgen und beim Schließen und erneuten Öffnen die vorherige Arbeitsposition wiederherstellen
  • Godot 4.0 unterstützte die Definition und den Export typisierter Arrays sowie den Inspector-Export einzelner Nodes, aber nicht die Kombination beider Funktionen
  • Ab Godot 4.1 können Node-Arrays in den Inspector exportiert werden, was das Verbinden von Spielobjekten untereinander erleichtert
  • Dem Projektmanager wurde die Möglichkeit hinzugefügt, einzelnen Projekten Tags zuzuweisen und nach Tags zu filtern
    • dadurch lassen sich Dutzende oder Hunderte von Godot-Projekten leichter finden

Änderungen beim Rendering

  • Die Partikel-Turbulenz wurde auf Basis von Feedback von Artists überarbeitet und bietet nun mehr kreative Kontrolle
  • Turbulenz wird häufig verwendet, um reichhaltige, weit ausgedehnte Effekte zu erzeugen, wie man sie in modernen Spielen sieht
  • Mit neuen 3D-Noise-Texturen lässt sich die Dichte von volumetrischem Nebel leicht steuern
    • dadurch kann Nebel in bestimmten Bereichen dünner gemacht werden
  • NoiseTexture3D kann auch verwendet werden, um Vektorfelder für Partikel-Attractors zu erstellen
    • das ist nützlich, um Wind zu simulieren, der Partikel beeinflusst
  • Für den Godot-Renderer sind weiterhin viele Verbesserungen geplant, von denen die meisten in zukünftige Releases einfließen sollen
  • Das Rendering-Team und die Mitwirkenden priorisieren Bugfixes und Stabilität gegenüber neuen Funktionen
  • Der 3D-GLES3-Renderer ist noch nicht fertig und wird in den kommenden Monaten noch erheblich weiterentwickelt

Verbesserungen bei der Navigation

  • Godot 4.0 führte Echtzeitvermeidung für KI-Navigation ein, war aber auf eine einzelne Ebene beschränkt
  • Godot 4.1 enthält einen vollständig neu geschriebenen Vermeidungsalgorithmus
    • er bietet besseres Verhalten und mehr Kontrolle
    • Vermeidung funktioniert jetzt in 2D oder 3D
    • fliegende Agents können sich über bodengebundene Agents hinweg bewegen
  • Mit Layers lässt sich steuern, welche Agents welchen anderen Agents ausweichen
  • Durch Prioritäten kann festgelegt werden, dass einige Agents andere verdrängen
  • Das verbesserte Navigationsverhalten ist in der aktualisierten Dokumentation beschrieben

Plattformunterstützung und Web-Einschränkungen

  • Der Umfang der Plattformunterstützung in Godot 4.1 ist derselbe wie in Godot 4.0
  • Sowohl mit der Standard-Engine als auch mit der .NET-Version kann auf alle Desktop-Plattformen exportiert werden
  • Wenn im Projekt kein C# verwendet wird, ist auch ein Export auf mobile und Web-Plattformen möglich
  • Mit Stand 4.1 gibt es beim Web-Export Einschränkungen wegen fehlender Herstellerunterstützung für einige moderne Funktionen
    • Probleme treten in Browsern mit schwacher WebGL-2-Unterstützung auf, etwa Chrome auf macOS
    • ohne Änderungen durch Google oder erheblichen Aufwand für einen dedizierten WebGL-1-/GLES2-Renderer ist das schwer zu lösen
  • Auf Hosting-Plattformen, auf denen sich die für SharedArrayBuffer nötigen CORS-Header nicht setzen lassen, ist die Einrichtung von Webspielen kompliziert
    • dieses Problem hängt vor allem von der Umsetzung des Headers coep:credentialless in Safari ab
    • Chromium-basierte Browser und Firefox funktionieren bereits gut
    • bei einer Veröffentlichung auf itch.io funktioniert es besonders gut
    • mögliche Workarounds werden untersucht

Bekannte Probleme und nächstes Release

  • In Godot 4.1 gibt es noch Probleme, die vor dem Release nicht mehr gelöst werden konnten
  • Der Bugtracker ist unter Godot GitHub issues einsehbar
  • Eines der bestätigten Hauptprobleme ist, dass die neue API zum Definieren benutzerdefinierter Konfigurationseigenschaften für Export-Presets Benutzerkonfigurationen nicht beibehält
    • nach einem Neustart des Editors werden die Konfigurationsoptionen zurückgesetzt und verschwinden
    • ein Fix soll in 4.1.1 bereitgestellt werden
    • die zugehörige PR ist GH-79025
  • Die Arbeit an Godot 4.2 hat bereits begonnen und die Veröffentlichung ist in 4 Monaten geplant
  • Godot hält an einem stabilen Release-Zyklus fest, damit Nutzer nicht lange auf die nächsten Verbesserungen und neuen Funktionen warten müssen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-07-07
Hacker-News-Kommentare

  • Ich bin vor Kurzem fast vollständig von Unity auf Godot 4.0 umgestiegen, und obwohl ich kein professioneller Spieleentwickler bin, sondern eher kleine Indie-/itch.io-artige Spiele mache, bin ich wirklich sehr zufrieden damit.
    Es ist leichtgewichtig, schnell und einfach zu lernen, und es kann 90 % von dem leisten, was ein Solo-/Indie-Entwickler braucht.
    Allerdings kann ich Unity noch nicht komplett aufgeben, weil es einen Bug gibt, bei dem das Laden zu lange dauert, wenn macOS-Nutzer ein Spiel auf itch.io öffnen, sodass sie denken, es sei kaputt, und den Tab schließen.
    Die Spiele, die ich mache, sind oft für Bildungszwecke oder richten sich an Kinder, die iPads/MacBooks verwenden, daher ist es viel einfacher, einfach einen itch.io-Link zu geben, als lokale Installation zu erklären und die Gerätebesitzer zu überzeugen.
    Auf Godot-Seite wird angeblich an einer Lösung gearbeitet, aber bis dahin muss ich für einige Projekte weiter Unity verwenden. Wenn dieses Problem gelöst wird, könnte Godot bei itch.io/Game Jams groß herauskommen.

    As of 4.1 web exports still have some limitations due to poor vendor support of certain modern features. Browsers with bad WebGL 2 support, such as Chrome on macOS, unfortunately suffer from issues which we cannot address without a fix from Google or a significant amount of effort put into supporting a dedicated WebGL 1 / GLES2 renderer.
    We are also aware of the complexity setting up web games on hosting platforms which don’t let you set the required CORS headers for SharedArrayBuffer support. This mostly depends on Safari implementing the coep:credentialless header support, while Chromium-based browsers and Firefox already work fine (especially if you publish on itch.io). There is a possible workaround that we are investigating.

    • Ich war in einer ähnlichen Situation und habe schließlich gemerkt, dass Godot 3.5.2 immer noch die LTS-Version ist und Web-Exporte ebenfalls sehr gut funktionieren. Das Beispiel, das mich zum Umstieg überzeugt hat, ist dieses hier: https://yet-another-lucas.github.io/plumbing-adventure/
      Danach bin ich von Godot 4.0 C# auf Godot 3.5.2 + GDScript gewechselt und bin zufrieden damit.
      Ich habe außerdem eine CI/CD-Pipeline eingerichtet, die bei jedem Commit auf master automatisch auf GitHub Pages baut und deployt; so eine Pipeline ist ziemlich gut.
      https://www.reddit.com/r/godot/comments/q25riu/hosting_on_gi...
    • Dieses Jahr habe ich mit Godot 3.5 fünf kleine browserbasierte, Game-Jam-artige Spiele gemacht[1], und insgesamt war die Erfahrung gut. Bis die Web-Exporte von Godot 4 ordentlich funktionieren, kann man mit Godot 3.5 vollkommen zufrieden sein.
      Godot 4 bringt Sprachverbesserungen mit, auf die ich mich freue, etwa bessere Typunterstützung und Verbesserungen, die dafür sorgen, dass man weniger Magic Strings verwenden muss, zum Beispiel die Möglichkeit, Signale über ihren Namen zu referenzieren.
      Wenn das allerdings ein großes Hindernis ist, ist Warten vielleicht besser.
      Manchmal finde ich es frustrierend, dass das Godot-4-Team die macOS-Probleme eher als Chrome-Bug und nicht als Regression in Godot betrachtet[2].
      Das ist eher eine Frage von Semantik und Prioritäten, aber wenn eine Funktion, auf die man sich in Godot 3 verlassen hat, in Godot 4 kaputt ist, fällt es schwer, das nicht als Regression zu sehen.
      Trotzdem bin ich sehr dankbar für all die Arbeit, die in Godot 4 und die früheren Versionen geflossen ist, und freue mich auf den Tag, an dem ich Godot 4 einsetzen kann.
      [1] Falls es jemanden interessiert: alle sind auf https://eieio.games/
      [2] https://github.com/godotengine/godot/issues/70691
    • Der Teil mit „Browsern mit schlechtem WebGL-2-Support wie Chrome auf macOS“ ist mir aufgefallen.
      Ich hatte bisher nie WebGL2-Probleme unter Chrome/macOS, daher würde mich interessieren, um welche konkreten Probleme es geht.
      Ich vermeide allerdings auch bekannte problematische WebGL2/GLES3-Features. Das sind vor allem Uniform Buffers oder Buffer-Update-Muster, die nativ gut funktionieren, aber unter WebGL nicht, zum Beispiel „buffer orphaning“.
    • Ich frage mich, wie es um den VR-Support von Godot steht. Ich habe UE4 neun Jahre lang benutzt und mag Unity nicht besonders, aber Godot würde ich gern einmal ausprobieren.
    • Ich entwickle auf macOS Spiele mit Godot und veröffentliche sie auf itch.io, habe dieses Problem aber noch nie erlebt. Kannst du ein Beispiel nennen, bei dem das auftritt, und Informationen zu den Build-Export-Einstellungen geben?

  • Godot ist wirklich ein beeindruckendes Tool. Wenn ich einen Grund hätte, ein neues Spieleprojekt zu starten, würde ich es gern intensiver lernen, und wenn man sieht, was ein vergleichsweise kleines Team erreicht hat, ist das Unity fast schon peinlich.
    Beeindruckend ist auch, dass „über 900 gemeldete Probleme aus der Nutzung von Godot 4 und aus Tests der 4.1-Pre-Release behoben wurden“.
    Schon die Tatsache, dass bei gleichzeitiger weiterer Verbesserung von Performance und Stabilität so viele Probleme behoben wurden, verdient Lob.

    • 900 behobene Probleme sind definitiv beeindruckend, aber Godot ist wahrscheinlich auch eines der Repositories mit den meisten offenen Issues auf GitHub. Selbst jetzt sind noch über 5.000 offen.
      Natürlich ist die Zahl offener Issues kein guter Maßstab, um die Softwarequalität zu beurteilen.

  • Ich mag Godot, habe aber ein paar Kritikpunkte. GDScript ist nicht Python, und es fehlen einige der kleinen Features, die Python großartig machen, etwa Listen-/Dictionary-Comprehensions, .items(), Sets usw.
    Für die Spieleentwicklung ist es trotzdem völlig ausreichend, und weil es gut zur Umgebung passt, etwa mit nativen Typen, ist es eine ziemlich gute Sprache.
    Ich habe GDNative benutzt und sollte wohl auch GDExtension noch mehr ausprobieren, aber bisher fühlt sich C++ für Godot ziemlich rau an. Man muss überall Godot-Typen und new() verwenden, was die Handhabung nicht gerade einfach macht.
    Deshalb ist Godot eher keine echte C++-Engine, sondern eher etwas, bei dem man die meiste Zeit eine Skriptsprache nutzt und nur dann in C++ optimiert, wenn das Skript nicht schnell genug ist.
    Ich würde auch gern genauer wissen, wie schnell GDScript im Vergleich zu anderen Sprachen tatsächlich ist, und ob Mono/.NET schneller ist. Dass es eine Sprache ist, die perfekt in die Umgebung integriert ist, gefällt mir, aber ich frage mich, ob es dafür Verbesserungspläne gibt.
    Ich plane einen Multiplayer-FPS, und Godot scheint Netzwerkvorhersage nicht bereitzustellen, was ich mir wünschen würde.
    Sorgen macht mir auch die künftige OpenGL-Unterstützung. Sie ist noch nicht vollständig beendet, und ich fürchte, dass sie sich wegen der starken Unterschiede zu neuen APIs wie Vulkan oder DX12 nur schwer sauber umsetzen lässt.
    Insgesamt ist Godot das Beste, was Open Source und der Spieleentwicklung passiert ist. Spieleentwicklung war ein Bereich, in dem sich Open Source nur schwer etablieren konnte, und Godots leichtgewichtiges Design ist im Vergleich zu riesigen Tools wie Unreal oder Unity eine große Erleichterung.

    • Das ist auch das größte Problem bei Godot. Allerdings nicht, weil GDScript kein Python ist, sondern weil es keine Allzwecksprache ist. Das ist auch fast das Einzige, was ich an Unity vermisse.
      Ich würde natürlich wahrscheinlich nicht direkt Python wählen; ich mag die Sprache zwar, würde aber eher etwas nehmen, das stärker auf Performance fokussiert ist. Go könnte ebenfalls eine gute Wahl sein.
      GDScript an sich ist nicht schlecht, und wenn man es nicht mit anderen Sprachen vergleicht, ist es sogar ziemlich hervorragend. Aber im Vergleich zu einer Allzwecksprache verliert man einfach zu viel.
      Ich weiß, dass es Bindings gibt, aber ich hatte mit Raylib eine ähnliche Erfahrung, und dort war inoffizielle Sprachunterstützung praktisch so gut wie keine. Selbst das offizielle Mono-Binding ist ziemlich schlecht.
    • .NET ist schneller.
      Allerdings verwenden selbst AAA-Spiele für die Spiellogik oft langsame Skriptsprachen. In vielen Spielen ist die Spiellogik nicht der Teil, der besonders viel CPU frisst, daher ist das oft nicht entscheidend.
    • Ich frage mich, wie Netzwerkvorhersage in einem Game-Framework konkret aussieht. Legt man fest, welche Eigenschaften eines Objekts interpoliert werden sollen, und die Engine kümmert sich dann um den Rest?

  • Gibt es einen Anwendungsfall dafür, Godot statt so etwas wie Electron für plattformübergreifende App-Entwicklung zu verwenden?

  • Einer der wichtigsten Mitwirkenden/Entwickler von Godot hat auch ein praktisches kleines Tool veröffentlicht, mit dem sich alles, was mit Godot erstellt wurde, vollständig dekompilieren lässt.
    https://github.com/bruvzg/gdsdecomp

    • Tolles Tool, aber Godots Haupt-/Lead-/zentraler Entwickler ist reduz, also Juan Linietsky.

  • Godot ist wirklich großartig. Ich bin tief beeindruckt vom Fortschritt des Teams und von der generellen Ausrichtung des Projekts
    Ich hatte schon immer großes Interesse an der Spieleentwicklung, und ein wesentlicher Grund, warum ich Informatik studiert und Softwareingenieur geworden bin, war, dass ich Spiele machen wollte. Ich wollte selbst kleine Spiele entwickeln, aber in der Praxis hat das nie besonders gut geklappt
    Nachdem ich Vollzeit-Softwareingenieur geworden war, hatte ich weder die Zeit noch die passenden Werkzeuge, um nebenbei als Hobby kleine Spiele zu machen
    Vor Kurzem habe ich Bevy entdeckt und ausprobiert. ECS ist ein gutes Konzept, aber Bevy ist eher eine Bibliothek, und es ist ziemlich schwer, damit ein ausgereiftes Spiel zu bauen, ähnlich wie wenn man etwas wie SDL verwendet
    Als ich Godot entdeckt und ausprobiert habe, war ich wirklich beeindruckt. Es ist einsteigerfreundlich und trotzdem schnell genug, und auch die Community ist großartig. Es ist genau das, wonach ich gesucht habe, und ich freue mich sehr, dass es existiert, und bin gespannt auf seine weitere Entwicklung
    Ein kleiner Wermutstropfen ist die native und „offizielle“ Sprachauswahl. GDScript ist in Ordnung und eine ziemlich gute Python-artige Sprache für Einsteiger und schnelles Prototyping, und C# kann für Leute, die von Unity kommen, ebenfalls gut sein
    Persönlich wäre ich mit besserer C++-Unterstützung oder etwas anderem glücklicher gewesen. Ich weiß auch, dass es die GDNative-Schnittstelle gibt und dass sie in 4.0 verbessert wurde
    C# ist eine gute Sprache, aber ich habe das Gefühl, dass ihre starke Präsenz in der Spieleentwicklung vor allem an Unity liegt. Sie ist zu wortreich, und auch die Tool-Unterstützung außerhalb von Visual Studio ist insgesamt nicht besonders gut
    Vielleicht ist der Teil des „eigentlichen Programmierens“ in der Spieleentwicklung aber auch gar nicht so wichtig, und vielleicht sollte ich es einfach akzeptieren und GDScript verwenden

  • Godot wird es vielleicht schwer haben, gegen Unreal anzutreten, aber ich unterstütze definitiv den Versuch, Unity zu ersetzen
    Es ist eine großartige Engine, und immer mehr Entwickler erkennen ihr Potenzial richtig

    • Unity ist auf andere Weise als Unreal ein eigenes Ökosystem. Unity unterstützt als Plattform die Monetarisierung auf Mobilgeräten auf eine Weise, die andere Plattformen nicht leisten, und Godot wird dieses Ökosystem nicht so schnell verdrängen
      Wenn wir aber über Indie-Entwicklung sprechen, stimme ich vollkommen zu. Godot ist das Framework, das sich viele von Unity gewünscht haben: leichtgewichtig, nicht störend und darauf ausgelegt, dass man sofort loslegen kann. Für diesen Zweck ist Godot deutlich besser
    • Es wäre vermessen, mit Unreal konkurrieren zu wollen, einer auf AAA-Spiele fokussierten Engine mit jahrzehntelanger Geschichte und riesigen Vollzeit-Teams. Für ein Open-Source-Projekt ist es schwer, einem solchen beweglichen Ziel zu folgen
      Zum Glück ist Unreal Engine für viele Arten von Spielen keine gute Wahl, und Godot schafft sich im Bereich 2D-Spiele und einfachere 3D-Spiele gut seine eigene Nische
      Der Markt für 2D-Spiele ist immer noch groß, und überraschenderweise gibt es nicht viele Engines mit wirklich guter 2D-Unterstützung. Godot gehört hier ganz klar zur Spitzenklasse
    • Wenn man den Marketplace kopieren könnte, wäre wohl auch Konkurrenz zu Unity möglich

  • Godot ist wirklich cool, und ich habe großen Respekt vor allen, die ihre Zeit investieren, um solche Software und Werkzeuge wie Blender so großartig zu machen

  • Godot wird mit jeder Veröffentlichung wirklich besser. Es gibt Funktionen, die ich künftig gern in Godot sehen würde
    FSR2, großartige Wayland-Unterstützung und LLM-Integration. LLMs könnten NPCs vielleicht realistischer machen

    • Bei der LLM-Integration bin ich mir nicht sicher. Das wirkt eher wie eine spielspezifische Funktion als etwas, das direkt zu einer Game Engine gehört. LLM-Integration ließe sich im Spiel vermutlich per Scripting umsetzen
      Im Hinblick auf KI-Integration wäre KI-gestütztes Design interessanter. Man beschreibt Terrain, Charaktere oder Szenarien, die KI erzeugt etwas, und danach kann der Benutzer es anpassen und verfeinern
      Aber selbst das wäre wahrscheinlich besser außerhalb der eigentlichen Core-Game-Engine aufgehoben
    • Hardwarebeschleunigtes Raytracing?

  • Gibt es ein empfehlenswertes Godot-Tutorial?
    Ich habe einen kleinen RPG-Prototyp, der in der Konsole läuft, und würde gern eine echte GUI oder Sprite-Grafiken daran anbinden

    • Es gibt ein kostenloses Tutorial für Godot 4, mit dem man in etwa zwei Stunden von Null bis zu einem fertigen Spiel kommt: https://quiver.dev/tutorials/create-your-first-godot-4-game/
      Zur Transparenz: Ich bin Gründer des Unternehmens, das diesen Kurs erstellt hat. Das Tutorial ist aber kostenlos, und die darin verwendeten Custom-Assets stehen ebenfalls unter einer großzügigen Lizenz zur Verfügung
    • GD Quest gilt derzeit gewissermaßen als Standard. So etwas wie das W3Schools von Godot
      Allerdings finde ich als jemand, der von Unity zu Godot wechselt, dass das Tutorial-Ökosystem von Godot noch deutlich hinterherhinkt
    • Ich habe einen der Kurse von Heartbeast gemacht und kann ihn empfehlen
      Vor Kurzem hat er auch einen speziellen Kurs für Godot 4 veröffentlicht
      https://www.youtube.com/watch?v=M8-JVjtJlIQ
    • Ich habe auf YouTube eine Playlist mit meinen Programmier-Tutorials, darunter auch ein paar zu Godot
      https://www.youtube.com/playlist?list=PLwYfcDZR0fFcROLjkiyBW...
      Viele der Tutorials, auf die du stoßen wirst, sind für Godot 3, daher ist es besser, gezielt nach Godot 4 zu filtern
      Andernfalls musst du den Tutorial-Code selbst an deine Godot-Version anpassen, was an sich auch eine lehrreiche Erfahrung sein kann
    • Die offizielle Dokumentation[0] ist definitiv der klassische Einstieg
      [0] https://docs.godotengine.org/en/stable/getting_started/intro...