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 gerne 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) 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. Beachten Sie 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 (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 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, VisualScript, C# und C++. Genaueres zu jeder Sprache ist in der jeweiligen Unterkategorie im scripting-Abschnitt.

Wenn Sie gerade beginnen, 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 GDScript einen schnellen, freundlichen und mächtigen Weg, Spiele zu entwickeln.

Beachten Sie, 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 Ihnen, dass Sie sich erst selbst eingehend mit dem Problem 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 die GDScript-Anleitung an.

Es gibt mehrere Gründe GDScript zu verwenden -- besonders wenn Sie einen Prototypen entwirfen, in Alpha- oder Beta-Phasen eines Projektes stecken, oder Sie nicht gerade den nächsten AAA-Titel entwickelen -- 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, 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 sie wächst, sind wir sicher, dass Sie GDScript mögen werden und es mit Ihren Fähigkeiten wächst.

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 beanspruchte enorm viel Code. Nach einigen Experimenten mit Python stellte auch sie sich 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, JS, AS, 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, JS).
  3. Viele bestehende Sprachen haben ineffiziente Schnittstellen zum Binding mit 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.), resultierend in stark reduzierter 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. (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. Wenn Sie Blender verwenden, schauen Sie sich unseren eigenen Better Collada Exporter an.

Ab Godot 3.0 wird gITF unterstützt.

FBX wird mit Open Asset Import library unterstützt. Allerdigs ist es propritär, so dass wir empfehlen ein anderes Format aus der obigen Liste zu verwenden, wenn es für Ihren Workflow geeignet ist.

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 Sie nichts daran, diese Bibliotheken als Module hinzuzufügen und Ihr Spiel mit ihnen zu vertreiben - sei es als Open- oder Closed Source.

Wie die Implementierung für Ihr gewünschtes SDK auch noch 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 Gemeinschaft wie Ihnen.

Why does Godot use Vulkan or OpenGL instead of Direct3D?

Godot aims for cross-platform compatibility and open standards first and foremost. OpenGL and Vulkan are the technologies that are both open and available (nearly) on all platforms. Thanks to this design decision, a project developed with Godot on Windows will run out of the box on Linux, macOS, and more.

Since Godot only has a few people working on its renderer, we would prefer having fewer rendering backends to maintain. On top of that, using a single API on all platforms allows for greater consistency with fewer platform-specific issues.

In the long term, we may develop a Direct3D 12 renderer for Godot (mainly for the Xbox's purposes), but Vulkan and OpenGL will remain the default rendering backends on all platforms, including Windows.

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 einfache 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 Drittanbieter Library mit Godot integriert.

When is the next release of Godot out?

When it's ready! See Wann erscheint die nächste Godot-Version? for more information.

Ich würde gerne mitwirken! 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-Gemeinschaft werden eher daran interessiert sein, über Dinge 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 einfach noch 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 Gemeinschaft 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 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.

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.