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:

  • Du kannst Godot gerne herunterladen und für jeden Zweck verwenden: persönlich, gemeinnützig, kommerziell oder sonstiges.
  • Du darfst 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) und dem Namen „Juan Linietsky, Ariel Manzur and the Godot Engine community“ veröffentlicht.

Für Logos und Symbole gilt generell die gleiche „Creative Commons“-Lizenz. Beachte jedoch, dass manche Fremdbibliotheken, 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

Für das Exportieren von Spielen:

  • Windows (und UWP)
  • Mac OS
  • X11
  • Android
  • iOS
  • Web

Sowohl 32- als auch 64-Bit Binaries werden unterstützt, wohingegen 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 Dritt-Anbieter, die an der Kompilierung für bestimmte Konsolen arbeiten.(Laut manchen Nutzern lässt sich Godot auch erfolgreich auf ARM-basierten Systemen mit Linux, wie dem Raspberry Pi kompilieren und verwenden. Außerdem gibt es Ports für Konsolen von Drittanbietern.) 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, Visual Scripting, C# und C++. Genaueres zu jeder Sprache ist in der jeweiligen Unterkategorie im scripting-Abschnitt.

Wenn Du gerade beginnst, Godot oder generell Spielentwicklung zu lernen, empfehlen wir, GDScript zu lernen und zu nutzen, da es nativ von Godot unterstützt wird. Scripting-Sprachen 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 dir GDScript einen schnellen, freundlichen und mächtigen Weg, deine Spiele zu entwickeln.

Beachte, dass die C#-Unterstützung relativ neu ist und deswegen noch einige Probleme auf diesem Weg auftreten können. Unsere freundlichen und hart arbeitenden Entwickler sind immer bereit, neu auftretende Probleme zu beheben, aber da dies ein Open-Source-Projekt ist, empfehlen wir Dir, dass Du dich erst selbst eingehend mit dem Problem beschäftigst. 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 du schon mal etwas in einer Programmiersprache wie Python entwickelt hast, wirst du dich bei GDScript schnell wie zu Hause fühlen. Für Beispiele, eine Versionshistorie und eine komplette Übersicht, was GDScript so bietet, schau dir die GDScript-Anleitung an.

Es gibt mehrere Gründe GDScript zu verwenden – besonders wenn Du einen Prototypen entwirfst, in Alpha- oder Beta-Phasen deines Projektes steckst, oder Du nicht gerade den nächsten AAA-Titel entwickelst – aber der überzeugendste Grund ist die allgemeine Verringerung der 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, da 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 du lieber deine andere Sprache in Godot verwenden möchtest (Liste der unterstützten Optionen oben). Doch wenn du GDScript noch nicht ausprobiert hast, versuche es wenigstens für drei Tage. Sobald du siehst, wie mächtig die Sprache ist und wie schnell sie wächst, sind wir sicher, dass du GDScript mögen wirst und es mit deinen Fähigkeiten wächst.

Weitere Informationen, um sich mit GDScript bzw. dynamisch typisierten Sprachen vertraut zu machen, können im Tutorial GDScript: An introduction to dynamic languages gefunden werden.

Was war die Motivation, GDScript zu entwickeln?

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

  1. Schlechte Thread-Unterstützung in den meisten Skript-VMs (Lua, Python, Squirrel, JS, AS, etc.).
  2. Schlechte Klassenerweiterung in den meisten Skript-VMs, Anpassung an die Funktionsweise von Godot ist sehr ineffizient (Lua, Python, JS).
  3. Viele bestehende Sprachen haben ineffiziente Schnittstellen für die Einbindung von C++, was zu einer großen Menge Code, Bugs, Engpässen und allgemeiner Ineffizienz führt (Lua, Python, Squirrel, JS, etc.). Wir wollten uns auf eine großartige Engine konzentrieren, nicht auf eine große Anzahl von Scriptsprachen.
  4. Keine nativen Vektor-Typen (vector3, matrix4, usw.) → geringere Performance wenn eigene Objekttypen genutzt werden (Lua, Python, Squirrel, JS, AS, etc.).
  5. Der Garbage Collector führt zu Verzögerungen oder unnötig viel Speicherbelegung (Lua, Python, JS, AS, etc.).
  6. Schwierigkeiten bei der Integration in den Code-Editor zur Code-Vervollständigung, Live-Bearbeitung, etc. (all dies). 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 über den OpenCollada Exporter (Maya, 3DSMax).

Solltest Du Blender nutzen, schau Dir unseren Better Collada Exporter an.

Ab Godot 3.0 wird gITF unterstützt.

Das FBX SDK hat eine beschränkende Lizenz, die mit der offenen Lizenz von Godot nicht kompatibel ist. Allerdings könnten Dritt-Entwickler die FBX-Unterstützung als Plugin anbieten. (Siehe Frage zu Plugins unten.)

Wird [Closed-Source-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 nicht-quelloffene/proprietäre SDKs einzubinden, da dies dem Ethos Godots widersprechen würde.

Das heißt, da Godot quelloffen und modular ist, hindert Dich nichts daran, diese Bibliotheken als Module hinzuzufügen und Dein Spiel mit ihnen zu vertreiben - sei es als Open- oder Closed Source.

Wie die Implementierung für dein gewünschtes SDK auch noch umgesetzt werden kann, erfährst du in der Fragestellung zu Plugins weiter unten im Text.

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

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 einfachste Weg, dies zu erreichen, ist eine einfache Basis-Auflösung für das Spiel zu verwenden und nur mit verschiedenen Bildschirm-Größen klarzukommen. Dies wird am meisten für 2D benötigt, denn in 3D ist es einfach eine Frage der Kamera (XFov und YFov).

  1. Wähle eine einfache Grundauflösung für Dein 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). Beachte jedoch, je höher die Auflösung und die Texturen, 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 Multiple resolutions).
  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 Multiple resolutions erklärt.
  4. Um das Verhalten von Steuerelementen im Raum besser zu kontrollieren, solltest Du 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):

Du kannst 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 dritt anbitter Library mit Godot integriert.

Ich würde gerne mitwirken! Wie kann ich anfangen?

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

Als Erstes kannst du dir die Bugreports anschauen. Finde ein Ticket, das dich anspricht, dann lies dir die Anleitung zum Mitwirken durch, um zu lernen wie Du einen Projekt-Fork anlegen, ihn bearbeiten und einen Pull Request (PR) mit Deinen Ergänzungen absenden kannst.

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 Workflows, die in den Editor eingebaut werden sollen. Diesen Enthusiasmus finden wir großartig und sind dankbar dafür, solch 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-Gemeinschaft werden eher daran interessiert sein, über Dinge wie:

  • Deine Erfahrung mit der Software und die Probleme, die Du hast (uns interessiert das um einiges mehr als die Ideen, wie man die Software verbessern kann).
  • Die Funktionen, die Du gerne in der Engine implementiert sehen würdest, weil sie für ein Projekt benötigt werden.
  • Die Konzepte, die schwierig zu verstehen waren zum Erlernen der Software.
  • Teile von Arbeitsabläufen, die Du gerne optimiert haben würdest.
  • Teile, wo Ihnen verständliche Tutorials fehlten oder wo die Dokumentation einfach noch nicht ausführlich genug war.

Bitte habe nicht das Gefühl, dass deine Ideen nicht willkommen wären. Versuche stattdessen zuerst, sie als Problem neu zu formulieren, sodass die Entwickler und Gemeinschaft einen festen Boden haben, auf dem sie deine Idee diskutieren können.

Ein geeigneter Ansatz, Ideen und Probleme mit der Gemeinschaft zu teilen, ist mit einer Reihe praktischer Anwendergeschichten. Beschreibe, was Du beabsichtigst, welches Verhalten Du idealerweise dabei erwarten würdest 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).

Why does Godot not use STL (Standard Template Library)

Like many other libraries (Qt as an example), Godot does not make use of STL. We believe STL is a great general purpose library, but we had special requirements for Godot.

  • STL templates create very large symbols, which results in huge debug binaries. We use few templates with very short names instead.
  • Most of our containers cater to special needs, like Vector, which uses copy on write and we use to pass data around, or the RID system, which requires O(1) access time for performance. Likewise, our hash map implementations are designed to integrate seamlessly with internal engine types.
  • Our containers have memory tracking built-in, which helps better track memory usage.
  • For large arrays, we use pooled memory, which can be mapped to either a preallocated buffer or virtual memory.
  • We use our custom String type, as the one provided by STL is too basic and lacks proper internationalization support.

Why does Godot not use exceptions?

We believe games should not crash, no matter what. If an unexpected situation happens, Godot will print an error (which can be traced even to script), but then it will try to recover as gracefully as possible and keep going.

Additionally, exceptions significantly increase binary size for the executable.

Why does Godot not enforce RTTI?

Godot provides its own type-casting system, which can optionally use RTTI internally. Disabling RTTI in Godot means considerably smaller binary sizes can be achieved, at a little performance cost.

Why does Godot not force users to implement DoD (Data oriented Design)?

While Godot internally for a lot of the heavy performance tasks attempts to use cache coherency as best as possible, we believe most users don’t really need to be forced to use DoD practices.

DoD is mostly a cache coherency optimization that can only gain you significant performance improvements when dealing with dozens of thousands of objects (which are processed every frame with little modification). As in, if you are moving a few hundred sprites or enemies per frame, DoD won’t help you, and you should consider a different approach to optimization.

The vast majority of games do not need this and Godot provides handy helpers to do the job for most cases when you do.

If a game that really needs to process such large amount of objects is needed, our recommendation is to use C++ and GDNative for the high performance parts and GDScript (or C#) for the rest of the game.

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

Siehe Ways to contribute.

Wer arbeitet an Godot? Wie kann ich euch kontaktieren?

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