Häufig gestellte Fragen

Was kann ich mit Godot machen? Wie viel kostet es? Wie lauten die Lizenzbedingungen?

Godot ist eine freie Open Source Software und verfügbar unter der von der OSI anerkannten MIT-Lizenz. Das bedeutet, sie ist so frei wie "freie Meinungsäußerung" oder "freies Bier."

Zusammengefasst:

  • SIe können Godot frei herunterladen und für jeden Zweck verwenden: persönlich, gemeinnützig, kommerziell oder sonstiges.

  • Sie dürfen Godot nach Herzenslust verändern und weitergeben (auch verändert), egal ob kommerziell oder nicht.

Alle Inhalte dieser Dokumentation werden unter der freizügigen Creative Commons Attribution 3.0-Lizenz (CC-BY 3.0) mit Namensnennung von "Juan Linietsky, Ariel Manzur und der Godot Engine Gemeinschaft" veröffentlicht.

Für Logos und Symbole gilt generell die gleiche "Creative Commons"-Lizenz. Beachten Sie jedoch, dass manche Bibliotheken von Drittanbietern, die im Quellcode Godots enthalten sind, abweichende Lizenzen enthalten können.

Für alle Details siehe die Dateien COPYRIGHT.txt und LICENSE.txt sowie LOGO_LICENSE.txt im Godot-Repository.

Siehe auch Hinweise zur Lizenz auf der Godot-Webseite.

Welche Plattformen werden von Godot unterstützt?

Vom Editor unterstützt:

  • Windows

  • Mac OS

  • X11 (Linux, *BSD)

Für das Exportieren von Spielen:

  • Windows (und UWP)

  • Mac OS

  • X11 (Linux, *BSD)

  • Android

  • iOS

  • Web

Sowohl 32- als auch 64-Bit Binaries werden unterstützt, wobei 64 Bit der Standard ist.

Einige Nutzer berichten, dass sie Godot auch auf ARM-basierten Linux-Systemen – wie dem Raspberry Pi – erfolgreich kompilieren und benutzen konnten.

Darüberhinaus gibt es einige inoffizielle Drittanbieter, die an der Kompilierung für bestimmte Konsolen arbeiten. Allerdings ist nichts davon standardmäßig in den Buildskripten oder Exportvorlagen enthalten.

Mehr dazu in den Abschnitten Exportieren und Godot kompilieren.

Welche Programmiersprachen werden in Godot unterstützt?

Die offiziell unterstützten Sprachen für Godot sind GDScript, VisualScript, C# und C++. Genaueres zu jeder Sprache ist in der jeweiligen Unterkategorie im scripting-Abschnitt.

Wenn Sie gerade beginnen sich mit Godot oder generell Spieleentwicklung zu befassen, empfehlen wir GDScript zu lernen und zu nutzen, da es nativ von Godot unterstützt wird. Skriptsprachen sind insgesamt weniger performant als Sprachen wie C oder Rust, aber zum schreiben von Prototypen, Minimal-Viable-Products und bezogen auf die Time-To-Market bietet GDScript einen schnellen, freundlichen und mächtigen Weg, Spiele zu entwickeln.

Beachten Sie, dass die Unterstüzung für C# relativ neu ist und deswegen noch einige Probleme mit sich bringen kann. Unsere freundlichen und hart arbeitenden Entwickler sind immer bereit, neu auftretende Probleme zu beheben, aber da dies ein Open Source-Projekt ist, empfehlen wir Ihnen, sich erst selbst eingehend mit dem Problem zu beschäftigen. Die offenen Bugmeldungen zu durchforsten ist dabei ein guter Anfang.

Für weitere Sprachen ist das manuelle Einbinden per GDNative / NativeScript / PluginScript gegeben. (siehe hierzu die Frage zu Plugins weiter unten) So werden derzeit unter anderem Schnittstellen zum Einbinden von Python und Nim entwickelt.

Was ist GDScript und warum sollte ich es verwenden?

GDScript ist Godots integrierte Skriptsprache. Sie wurde von Grund auf entwickelt, um das Potential von Godot mit möglichst wenig Code auszuschöpfen, sodass sowohl Anfänger als auch erfahrene Entwickler von Godots Stärken profitieren können. Wenn Sie schon mal etwas in einer Programmiersprache wie Python entwickelt haben, werden Sie sich bei GDScript schnell wie zu Hause fühlen. Für Beispiele, eine Versionshistorie und eine komplette Übersicht, was GDScript so bietet, schauen Sie sich die GDScript-Anleitung an.

Es gibt mehrere Gründe GDScript zu verwenden -- besonders wenn Sie einen Prototypen entwerfen, in Alpha- oder Beta-Phasen eines Projektes stecken, oder Sie nicht gerade den nächsten AAA-Titel entwickeln -- aber der überzeugendste Grund ist die allgemeine Verringerung von Komplexität.

Die ursprüngliche Absicht, eine eng integrierte, benutzerdefinierte Skriptsprache für Godot zu entwickeln, ergab sich aus zwei Gründen: Erstens reduziert sie die Zeit, die für die Inbetriebnahme und den Betrieb mit Godot erforderlich ist, und gibt Entwicklern eine schnelle Möglichkeit, sich mit der Engine mit Produktivitätsfokus auseinanderzusetzen; Zweitens reduziert sie die allgemeine Wartungslast, verringert die Dimensionalität von Problemen und ermöglicht es den Entwicklern der Engine, sich auf das Beheben von Fehlern und die Verbesserung von Funktionen im Zusammenhang mit dem Engine Kern zu konzentrieren, anstatt viel Zeit damit zu verbringen einen kleinen Satz inkrementeller Funktionen über eine große Anzahl von Sprachen hinweg zu nutzen.

Eine stark integrieretes Erlebnis ist wichtiger als die Gewinnung zusätzlicher Benutzer, da es sich bei Godot um ein Open-Source-Projekt handelt. Daher verzichtet Godot darauf, mehr (vertraute) Programmiersprachen zu unterstützen, weil diese zu einem schlechteren Ergebnis führen würde, da sie nicht in der gleichen Weise mit der Umgebung integriert werden können. Wir verstehen, wenn Sie lieber eine andere Sprache in Godot verwenden möchten (Liste der unterstützten Optionen oben). Doch wenn Sie GDScript noch nicht ausprobiert haben, versuchen Sie es wenigstens für drei Tage. Sobald Sie sehen, wie mächtig die Sprache ist und wie schnell Ihre Entwicklung wird, sind wir sicher, dass Sie GDScript lieben werden.

Weitere Informationen, um sich mit GDScript bzw. dynamisch typisierten Sprachen vertraut zu machen, können in der Anleitung GDScript: Eine Einführung in dynamische Programmiersprachen gefunden werden.

Was war die Motivation, GDScript zu entwickeln?

Anfänglich nutzte die Engine noch Lua als Skriptsprache. Lua ist schnell, aber die Sprachanbindung an ein objektorientiertes System zu erstellen (durch Verwendung von Fallbacks) war komplex, langsam und verlangte nach enorm viel Code. Nach einigen Experimenten mit Python stellte sich auch diese Sprache als schwierig einzubetten heraus.

Die Hauptgründe, eine eigene Skriptsprache für Godot zu entwickeln, waren:

  1. Schlechte Threading-Unterstützung in den meisten Skript-VMs und Godot nutzt Threads (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).

  2. Schlechte Unterstützung für Klassenerweiterung in den meisten Skript-VMs und die Anpassung an die Funktionsweise von Godot ist sehr ineffizient (Lua, Python, JavaScript).

  3. Viele bestehende Sprachen haben ineffiziente Schnittstellen zur Anbindung an C++, was zu einer großen Menge Code, Bugs, Engpässen und allgemeiner Ineffizienz führt (Lua, Python, Squirrel, JavaScript, etc.). Wir wollten uns auf eine großartige Engine konzentrieren, nicht auf eine große Anzahl von Skriptsprachen.

  4. Keine nativen Vektor-Typen (vector3, matrix4, usw.), was eine stark reduzierte Performance zur Folge hat, wenn eigene Objekttypen genutzt werden (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).

  5. Der Garbage Collector führt zu Verzögerungen oder unnötig viel Speicherbelegung (Lua, Python, JavaScript, ActionScript, etc.).

  6. Schwierigkeiten bei der Integration in den Code-Editor zur Code-Vervollständigung, Live-Bearbeitung, etc. (alle davon). Dies wird von GDScript unterstützt.

GDScript wurde entworfen, um diese und weitere Probleme zu umgehen.

Welche Arten von 3D-Modellformaten unterstützt Godot?

Godot Unterstützt Collada mit dem OpenCollada Exporter (Maya, 3DSMax). Wenn Sie Blender verwenden, schauen Sie sich unseren eigenen Better Collada Exporter an.

Ab Godot 3.0 wird gITF unterstützt.

FBX wird mit der Bibliothek "Open Asset Import Library (Assimp)" unterstützt. Allerdigs ist es propritär, so dass wir die Verwendung eines anderen Formats aus der obigen Liste empfehlen, sollte es denn für Ihren Workflow geeignet sein.

Wird [proprietäres SDK à la FMOD, GameWorks, etc. hier einfügen] in Godot unterstützt werden?

Das Ziel von Godot ist es, eine freie und quelloffene, MIT-lizensierte Engine, die modular und erweiterbar ist, zu entwickeln. Es gibt keine Pläne der Kernentwickler, irgendwelche proprietäre SDKs einzubinden, da dies dem Ethos Godots widersprechen würde.

Dennoch, da Godot quelloffen und modular ist, hindert Sie nichts daran, diese Bibliotheken als Module hinzuzufügen und Ihr Spiel mit ihnen zu vertreiben - sei es als Open Source oder proprietäre Software.

Wie die Implementierung für Ihr gewünschtes SDK doch umgesetzt werden kann, erfähren Sie in der Fragestellung zu Plugins weiter unten im Text.

Wenn Ihnen nützliche SDKs bekannt sind, die noch nicht von Godot unterstützt werden, aber eine freie und quelloffene Integration erlauben, können Sie gerne selbst an dieser arbeiten. Godot gehört nicht einer Person; es gehört der Allgemeinheit und wächst mit ambitionierten Mitwirkenden aus der Community wie Ihnen.

Warum verwendet Godot Vulkan oder OpenGL anstelle von Direct3D?

Godot strebt in erster Linie plattformübergreifende Kompatibilität und offene Standards an. OpenGL und Vulkan sind die Technologien, die sowohl offen als auch (fast) auf allen Plattformen verfügbar sind. Dank dieser Designentscheidung wird ein mit Godot unter Windows entwickeltes Projekt auch unter Linux, MacOS und anderen Systemen sofort einsatzbereit sein.

Da am Godot-Renderer nur wenige Leute arbeiten, würden wir es bevorzugen, weniger Renderer zu unterstützen. Darüber hinaus bietet eine einzelne, verwendete API auf allen Platformen eine höhere Konsitenz und weniger plattformspezifische Probleme.

Auf lange Sicht könnten wir einen Direct3D 12 Renderer für Godot entwickeln (vor allem für die Xbox), doch Vulkan und OpenGL werden die Standard-Renderer auf allen Plattformen bleiben, auch auf Windows.

Warum ist die Godot Engine darauf aus, ihren Funktionsumfang klein zu halten?

Godot beinhaltet bewusst keine Funktionalität welche als Add-On implementiert werden kann - außer sie wird häufig verwendet. Ein Beispiel hierfür ist die fortschrittliche Funktionalität für künstliche Intelligenz.

Dafür gibt es mehrere Gründe:

  • Wartung und Fehlersuche. Jedes mal, wenn neuer Code ins Godot Repository hinzugefügt wird, übernehmen die Autoren oft die Aufgabe, sich um ihn zu kümmern. Manche Autoren lassen ihren Code einfach in ruhe, nachdem er Implementiert worden ist, was es schwierig für uns macht, ihn zu pflegen. Dies kann zu schlecht gepflegten Features mit Fehlern führen, die nie behoben worden sind. Über alldem wird die API, die getestet und nach Rezessionen verbessert werden muss, stetig größer.

  • Kleiner Beitrag. Wenn der Code klein und übersichtlich bleibt, geht es schneller und leichter, den Code zu Kompilieren. Das macht es einfacher für neue Entwickler, mit Godot zu starten, ohne High-end Hardware kaufen zu müssen.

  • Halten Sie die Binärgröße für den Editor klein. Nicht jeder besitzt eine schnelle Internet Verbindung. Wenn Sie sicherstellen, dass jeder den Godot-Editor herunterladen, extrahieren und in weniger als 5 Minuten ausführen kann, ist Godot für Entwickler in allen Ländern zugänglicher.

  • Die Größe der Binary für Exportvorlagen klein halten. Dies hat direkten Einfluss auf die Größe von Projekten, die mit Godot exportiert wurden. Auf mobilen und Web-Plattformen ist eine geringe Dateigröße von großer Bedeutung, um eine schnelle Installation und ein schnelles Laden auf leistungsschwachen Geräten zu ermöglichen. Auch hier gilt, dass es viele Länder gibt, in denen Hochgeschwindigkeits-Internet nicht ohne weiteres verfügbar ist. Hinzu kommt, dass in diesen Ländern oft strenge Datennutzungsobergrenzen gelten.

Aus all den oben genannten Gründen müssen wir selektiv auswählen, was wir als Kernfunktionalität in Godot akzeptieren können. Aus diesem Grund möchten wir einige Kernfunktionen in zukünftigen Versionen von Godot auf offiziell unterstützte Add-Ons übertragen. In Bezug auf die Dateigröße hat das auch den Vorteil, dass man nur die wirklich benötigten Funktionen mit im finalen Export hat. So kann die Größe des Export minimiert werden. (In der Zwischenzeit ist es auch möglich :ref: benutzerdefinierte Exportvorlagen mit deaktivierten nicht verwendeten Funktionen zu kompilieren <doc_optimizing_for_size> , um die Verteilungsgröße Ihres Projekts zu optimieren.)

Wie sollten Assets für einen optimalen Umgang mit unterschiedlichen Bildschirmauflösungen und Seitenverhältnissen angelegt werden?

Diese Frage kommt häufig auf und rührt wahrscheinlich von einem durch Apple entstandenen Missverständnisses, als sie damit begannen, eine Verdoppelung der Größe ihrer Bildschirmauflösungen vorzunehmen. Es ließ die Leute in dem Glauben, Assets in verschiedenen Größen bereitzustellen sei eine gute Idee, und so fand diese Praxis immer häufiger Einzug bei Entwicklern. Dies klappte jedoch nur bis zu einem gewissen Grad und ausschließlich für Apple-Geräte, jedoch nicht für Android- und spätere Apple-Produkte, die mit einer deutlich größeren Bandbreite neuer Bildschirmgrößen und DPIs ausgestattet waren.

Der eleganteste Weg, dies zu erreichen, ist eine Basisauflösung für das Spiel zu verwenden und anschließend mit verschiedenen Bildschirmgrößen umzugehen. Dies wird am meisten für 2D benötigt, denn in 3D ist es im Wesentlichen nur eine Frage der Kamera (XFov und YFov).

  1. Wählen Sie eine einfache Basisauflösung für Ihr Spiel. Selbst zwischen Geräten, die über eine Auflösung von 2K hinausgehen und die nur eine Auflösung von unter 400p unterstützen, erledigt das standardisierte, hardwarebasierte Skalieren einen hervorragenden Job bei gleichzeitig minimalen Performanceeinbußen. Populär sind 1080p (1920x1080) oder 720p (1280x720). Beachten Sie jedoch, je höher die Auflösung und die Texturen sind, desto mehr Arbeitsspeicher wird das Gerät benötigen und desto länger wird es dauern, bis das Spiel fertig geladen ist.

  2. Benutze die Streck-Optionen in Godot. Am besten funktioniert 2D-Strecken, wenn das Seitenverhältnis gleich bleibt (siehe Mehrere Auflösungen).

  3. Setze eine minimale Auflösung und entscheide dann, ob das Spiel horizontal oder vertikal gestreckt werden soll (bei unterschiedlichen Seitenverhältnissen), oder ob um eine fixe Auflösung herum schwarze Balken gezeichnet werden sollen. Das wird auch in Mehrere Auflösungen erklärt.

  4. Um das Verhalten von Steuerelementen im Raum besser zu kontrollieren, sollten Sie diese verankern. Bei komplexeren Benutzeroberflächen ist es ratsam, sich zudem über Container zu informieren.

Und das war's! Das Spiel dürfte nun in mehreren Auflösungen funktionieren.

Ist es gewünscht, das Spiel auf älteren Geräten mit kleinen Bildschirmen (weniger als 300 Pixel horizontal) laufen zu lassen, können die Bilder mit der Export-Option verkleinert werden und für bestimmte Bildschirmgrößen im Google Play Store oder im Apple Store eingesetzt werden.

Wie kann ich Godot erweitern?

Um Godot zu erweitern, zum Beispiel durch das Erstellen von Editorerweiterungen oder die Unterstützung weiterer Sprachen, siehe Plugins und die Tool-Skripte.

Siehe auch die offiziellen Blogeinträge zu diesen Themen (auf Englisch):

Sie können auch einen Blick auf die GDScript Implementierung werfen, die Godot-Module und die inoffizielle Python-Unterstützung für Godot. Dies ist ein guter Startpunkt um zu sehen wie eine weitere Bibliothek von einem Drittanbieter in Godot integriert wird.

Wann erscheint die nächste Godot-Version?

Wenn sie fertig ist! Siehe Wann erscheint die nächste Godot-Version? für weitere Informationen.

Ich würde gerne etwas beitragen! Wie kann ich anfangen?

Super! Als Open Source-Projekt lebt Godot von den Ambitionen und Ideen von Entwicklern wie Ihnen.

Als Erstes können Sie sich die Bugreports anschauen. Finden Sie ein Ticket, das Sie anspricht, dann lesen Sie die Anleitung zum Mitwirken durch, um zu erfahren wie Sie einen Projekt-Fork anlegen, ihn bearbeiten und einen Pull Request (PR) mit Ihren Ergänzungen absenden können.

Ich habe eine tolle Idee für Godot. Wie kann ich sie teilen?

Es mag verlockend sein, Ideen in Godot einzubringen, etwa solche, die zu gravierenden Codeänderungen führen würden, um eine Art Nachahmung einer anderen Game-Engine zu verwirklichen oder alternative Arbeitsabläufe, die in den Editor eingebaut werden sollen. Diesen Enthusiasmus finden wir großartig und sind dankbar dafür, so motivierte Leute dabei zu haben, doch Godots Fokus ist und bleibt die Kernfunktionalität, so wie sie in der Roadmap, squashing bugs and addressing issues und in Diskussionen zwischen Godot-Community-Mitgliedern beschrieben ist.

Die meisten Entwickler in der Godot Community werden eher and Dingen interessiert sein, wie:

  • Ihre Erfahrung mit der Software und die Probleme, die Sie haben (uns interessiert das um einiges mehr als die Ideen, wie man die Software verbessern kann).

  • Die Funktionen, die Sie gerne in der Engine implementiert sehen würden, weil Sie sie für ein Projekt benötigt werden.

  • Die Konzepte, die schwierig zu verstehen waren zum Erlernen der Software.

  • Teile von Arbeitsabläufen, die Sie gerne optimiert haben würden.

  • Teile, wo Ihnen verständliche Anleitungen fehlten oder wo die Dokumentation nicht ausführlich genug war.

Bitte haben Sie nicht das Gefühl, dass Ihre Ideen nicht willkommen wären. Versuchen Sie stattdessen zuerst, sie als Problem neu zu formulieren, sodass die Entwickler und die gesamte Community einen festen Bezugspunkt haben, auf dem sie Ihre Idee diskutieren können.

Ein geeigneter Ansatz, Ideen und Probleme mit der Gemeinschaft zu teilen, ist mit einer Reihe praktischer Anwendergeschichten. Beschreiben Sie, was Sie beabsichtigen, welches Verhalten Sie idealerweise dabei erwarten würden und wie es sich aber tatsächlich ereignet hat. Probleme und Ideen auf diese Weise einzugrenzen, wird der Allgemeinheit helfen, sich auf die Verbesserung der Nutzererfahrung als Ganzes zu konzentrieren.

Bonuspunkte gibt es für Bildschirmfotos, konkrete Zahlen, Testfälle oder Beispielprojekte (falls machbar).

Ist es möglich mit Godot Anwendungen zu entwickeln welche kein Spiel sind?

Ja! Godot beinhaltet ein umfangreiches UI System. Die geringe Distributions-Größe von Godot kann es zu einer geeigneten Alternative zu Frameworks wie Electron oder Qt machen.

Wenn Sie eine "nicht spiele" Applikation entwickeln stellen Sie sicher das Sie low-processor mode in den Projekt Einstellungen einschalten um die CPU und GPU Belastung zu verringern.

Dennoch wir empfehlen es nicht mit Godot eine mobile App zu erstellen da der low-processor mode noch nicht auf mobilen Plattformen unterstützt wird.

Besuchen Sie Material Maker und Pixelorama für Beispiele von Open Source Anwendungen welche mit Godot erstellt wurden.

Ist es möglich Godot als Bibliothek zu nutzen?

Godot ist für die Verwendung in seinem eigenen Bearbeitungsprogramm gedacht. Wir empfehlen diesen auszuprobieren, da er Ihnen wahrscheinlich langfristig viel Zeit sparen wird. Es gibt keine Pläne Godot als Bibliothek nutzbar zu machen, da es den Rest der Engine komplizierter mache und somit für normale Benutzer schwieriger zu benutzen.

Wenn Sie eine Render-Bibliothek nutzen möchten, sollten Sie hierfür eine etablierte Render-Engine verwenden. Beachten Sie dabei, dass diese meist kleinere Benutzergruppen als Godot haben, was es schwieriger macht Antworten auf Ihre Fragen zu finden.

Welches UI Toolkit nutzt Godot?

Godot nutzt kein Standart GUI Toolkit wie GTK, Qt oder wxWidgets. Stattdessen nutzt Godot sein eigenes Oberflächen-Toolkit welches mit Open GL oder Vulcan gerendert wird. Dieses Toolkit wird in Form von Control Nodes dargestellt, welche verwendet werden um den Editor zu rendern (welcher in C++ geschrieben wurde). Diese Control Nodes können ebenfalls für Projekte von einer beliebige Skriptsprache welche von Godot unterstützt wird verwendet werden.

Dieses eigene Toolkit macht es möglich von Hardware Beschleunigung sowie einer konsistenten Erscheinung auf allen Plattformen zu profitieren. Zusätzlich muss sie nicht mit LGPL Lizenz Einschränkungen umgehen welche von GTK oder GT kommen. Zuletzt bedeutet das, dass Godot "das eigene Hundefutter isst", da der Editor selbst einer der komplexesten Nutzer von Godots UI System ist.

Dieses eigene UI Toolkit kann nicht als lib verwendet werden, aber Godot kann für "für nicht Spiele" Apps verwenden werden indem der Editor genutzt wird.

Warum verwendet Godot nicht STL (Standard Template Library)?

Wie viele andere Bibliotheken (zum Beispiel QT) verzichtet auch Godot auf den Einsatz der STL. Wir glauben, dass die STL eine großartige Allzweck-Bibliothek ist, allerdings hatten wir besondere Anforderungen für Godot.

  • STL-Vorlagen erzeugen sehr große Symbole und diese führen zu großen Debug-Binärdateien. Wir verwenden stattdessen nur wenige Vorlagen mit sehr kurzen Namen.

  • Die meisten unserer Container sind für spezielle Anforderungen ausgelegt, wie z.B. Vector, welcher Copy on Write verwendet und wir verwenden, um Daten weiterzugeben, oder das RID-System, das O(1)-Zugriffszeit für die Leistung benötigt. Ebenso sind unsere Hash-Map-Implementierungen so konzipiert, dass sie sich nahtlos in die internen Enginetypen integrieren lassen.

  • Unsere Container nutzen "memory tracking", was beim Analysieren des Speicherverbrauchs hilft.

  • Für den Gebrauch von großen Arrays, benutzen wir zusammengelegten Speicher, der entweder einem vorab zugewiesenen Buffer oder einem virtuellen Speicher zugeordnet werden kann.

  • Wir verwenden unsere eigene angepasste String Klasse, da die von STL bereitgestellte zu einfach ist und Internationalisierung nur unzureichend unterstützt wird.

Weshalb verwendet Godot keine "exceptions"?

Wir glauben Spiele sollten nicht Abstürzen, egal was auch passiert. Wenn eine unerwartete Situation auftritt, dann schreibt Godot eine Fehlermeldung, versucht dies danach aber so gut es geht wieder auszugleichen und weiter zu laufen.

Zusätzlich vergrößern "exceptions" die Größe des ausführbaren Programm erheblich.

Weshalb erzwingt Godot keine RTTI?

Godot stellt sein eigenes Type-Casting-System bereit, welches, nach Belieben, von der RTTI internen Gebrauch machen kann. Deaktiviertes RTTI in Godot bedeutet deutlich kleinere Größe, der ausführbaren Programmen, mit dem Nachteil einer wenig schlechteren Leistung.

Warum zwingt Godot seine Benutzer nicht zur Implementierung von DoD (Data oriented Design)?

Während Godot intern versucht, die Cache-Zusammenhänge für viele Aufgaben mit hoher Leistung so gut wie möglich zu nutzen, sind wir der Meinung, dass die meisten Benutzer nicht dazu gezwungen werden müssen, DoD-Methoden zu gebrauchen.

DoD ist größtenteils eine Cache-Zusammenhang-Optimierung, mit welcher nur eine erhebliche Leistungssteigerung erlangt werden kann, wenn diese mehrere tausende Objekte berechnen muss. Wenn wenige Hundert Sprites oder Gegner pro Bild bewegt werden, wird DoD keine Hilfe sein und eine andere Herangehensweise der Optimierung sollte in Erwägung gezogen werden.

Die größte Mehrheit der Spiele brauchen dies nicht und Godot stellt praktische Hilfen bereit, um die Arbeit in den meisten Fällen zu erledigen.

Falls ein Spiel, das wirklich eine solch große Anzahl von Objekten benötigt, wird von uns empfohlen C++ und GDNative für den Hochleistungsteil des Spiels zu gebrauchen und für den Rest GDScript (oder C#).

Wie kann ich die Entwicklung der Godot Engine unterstützen oder einen (finanziellen) Beitrag leisten?

Siehe Möglichkeiten, einen Beitrag zu leisten.

Wer arbeitet an Godot? Wie kann ich euch kontaktieren?

Siehe die dazugehörige Seite auf der Godot-Webseite.