Up to date

This page is up to date for Godot 4.2. If you still find outdated information, please open an issue.

Eigene Plattform-Portierungen

Ähnlich wie Benutzerdefinierte Module in C++ ist die Multiplattform-Architektur von Godot so konzipiert, dass die Erstellung von Plattform-Portierungen ohne Änderung des vorhandenen Quellcodes möglich ist.

Ein Beispiel für eine benutzerdefinierte Plattform-Portierung, die unabhängig von der Engine veröffentlichen wird, ist FRT, die für Einplatinencomputer bestimmt ist. Beachten Sie, dass diese Plattform-Portierung derzeit auf Godot 3.x abzielt; daher verwendet sie nicht die Abstraktion DisplayServer, die in Godot 4 neu ist.

Einige Gründe für die Erstellung benutzerdefinierter Plattform-Ports können sein:

• Sie möchten Ihr Spiel auf Konsolen portieren, möchten aber die Plattformschicht selbst schreiben. Dies ist ein langwieriger und mühsamer Prozess, da er die Unterzeichnung von NDAs mit Konsolenherstellern erfordert, aber er erlaubt Ihnen die volle Kontrolle über den Portierungsprozess für Konsolen.

• Sie möchten Godot auf eine exotische Plattform portieren, die derzeit nicht unterstützt wird.

Wenn Sie Fragen zur Erstellung einer eigenen Plattform-Portierung haben, können Sie diese im #platforms-Kanal des Godot Mitwirkenden-Chat stellen.

Bemerkung

Godot ist eine moderne Engine mit modernen Anforderungen. Selbst wenn Sie nur beabsichtigen, einfache 2D-Projekte auf der Target-Plattform auszuführen, wird eine Menge Speicher benötigt, die es unrentabel macht, auf den meisten Retro-Konsolen zu laufen. In Godot 4 benötigt ein leeres Projekt, bei dem nichts zu sehen ist, etwa 100 MB RAM, um unter Linux zu laufen (50 MB im Headless-Modus).

Wenn Sie Godot auf Plattformen mit stark eingeschränktem Speicher betreiben wollen, haben ältere Godot-Versionen geringere Speicheranforderungen. Der Portierungsprozess ist ähnlich, mit der Ausnahme, dass DisplayServer nicht von dem Singleton OS getrennt wird.

Offizielle Plattform-Ports

Die offiziellen Plattform-Ports können bei der Erstellung eines eigenen Plattform-Ports als Referenz verwendet werden:

• Windows

• macOS

• Linux/*BSD

• Android

• iOS

• Web

Obwohl der Plattformcode normalerweise in sich geschlossen ist, gibt es Ausnahmen von dieser Regel. So befinden sich z.B. Audiotreiber, die von mehreren Plattformen und Rendering-Backends gemeinsam genutzt werden, im Ordner drivers/ des Godot-Quellcodes.

Erstellen einer benutzerdefinierten Plattform-Portierung

Die Erstellung einer benutzerdefinierten Plattform-Portierung ist ein umfangreiches Unterfangen, das Vorkenntnisse über die SDKs der jeweiligen Plattform voraussetzt. Je nachdem, welche Features Sie benötigen, ist der Arbeitsaufwand unterschiedlich hoch:

Erforderliche Merkmale einer Plattform-Portierung

Als mindestes müssen die Methoden des Singletons OS implementiert sein, um für den Headless-Betrieb gebaut und verwendet werden zu können. Ein logo.svg (32×32)-Vektorbild muss ebenfalls im Plattformordner vorhanden sein. Dieses Logo wird im Export-Dialog für jede Export-Vorgabe angezeigt, die auf die betreffende Plattform abzielt.

Siehe diese Implementierung für die Linux/*BSD-Plattform als Beispiel. Siehe auch den OS Singleton Header als Referenz.

Bemerkung

Wenn Ihre Target-Plattform UNIX-ähnlich ist, sollten Sie erwägen, von der Klasse OS_Unix zu erben, um einen Großteil der Arbeit automatisch zu erledigen.

Wenn die Plattform nicht UNIX-ähnlich ist, können Sie den Windows-Port <https://github.com/godotengine/godot/blob/master/platform/windows/os_windows.cpp> als Referenz verwenden.

detect.py-Datei

Eine detect.py-Datei muss im Ordner der Plattform mit allen implementierten Methoden erstellt werden. Diese Datei wird benötigt, damit SCons die Plattform als gültige Option für die Kompilierung erkennen kann. Siehe die Datei detect.py für die Linux/*BSD-Plattform als Beispiel.

Alle diese Methoden sollten in detect.py wie folgt implementiert werden:

• is_active(): Kann verwendet werden, um das Bauen für eine Plattform vorübergehend zu deaktivieren. Diese Funktion sollte normalerweise immer True zurückgeben.

• get_name(): Gibt den für den Benutzer sichtbaren Namen der Plattform als String zurück.

• can_build(): Gibt True zurück, wenn das Hostsystem in der Lage ist, für die Target-Plattform zu bauen, andernfalls False. Fügen Sie hier keine langsamen Checks ein, da dies abgefragt wird, wenn die Liste der Plattformen vom Benutzer angefordert wird. Benutzen Sie stattdessen configure() für umfangreiche Abhängigkeitsüberprüfungen.

• get_opts(): Gibt die Liste der SCons-Build-Optionen zurück, die vom Benutzer für diese Plattform definiert werden können.

• get_flags(): Gibt die Liste der überschriebenen SCons-Flags für diese Plattform zurück.

• configure(): Build-Konfiguration durchführen, wie z.B. die Auswahl von Compiler-Optionen in Abhängigkeit von den gewählten SCons-Optionen.

Optionale Features einer Plattform-Portierung

In der Praxis reicht der Headless-Betrieb nicht aus, wenn Sie etwas auf dem Bildschirm sehen und Eingabegeräte bedienen wollen. Für die meisten Spiele werden Sie auch eine Audioausgabe benötigen.

Einige Links auf dieser Liste verweisen auf die Implementierung für die Linux/*BSD-Plattform als Referenz.

• Ein oder mehrere DisplayServer, mit den implementierten Windowing-Methoden. DisplayServer umfasst auch Features wie Mausunterstützung, Touchscreen-Unterstützung und Tablet-Treiber (für Stifteingabe). Siehe den DisplayServer Singleton Header als Referenz.

  • Für Plattformen, die keine volle Fensterunterstützung bieten (oder wenn es für den Port, den Sie erstellen, nicht relevant ist), können die meisten Fensterfunktionen weitgehend unimplementiert bleiben. Diese Funktionen können so eingerichtet werden, dass sie nur prüfen, ob die Fenster-ID MAIN_WINDOW_ID ist, und bestimmte Operationen wie die Größenänderung können an die Bildschirmauflösung der Plattform gebunden sein (falls relevant). Jeder Versuch, andere Fenster-IDs zu erzeugen oder zu manipulieren, kann zurückgewiesen werden.

• Wenn die Target-Plattform die fraglichen Grafik-APIs unterstützt: Rendering-Kontext für Vulkan, OpenGL 3.3 oder OpenGL ES 3.0.

• Eingabe-Handler für Tastatur und Controller.

• Ein oder mehrere Audio-Treiber. Der Audiotreiber kann sich im platform/-Ordner befinden (dies wird für die Android- und Web-Plattformen gemacht), oder im drivers/-Ordner, wenn mehrere Plattformen diesen Audiotreiber verwenden können. Siehe den AudioServer Singleton Header als Referenz.

• Crash-Handler, für die Ausgabe von Crash-Backtraces, wenn das Spiel abstürzt. Dies ermöglicht eine einfachere Fehlersuche auf Plattformen, auf denen Logs nicht ohne weiteres zugänglich sind.

• Text-to-Speech-Treiber (für Barrierefreiheit).

• Export-Handler (für den Export aus dem Editor, einschließlich Ein-Klick-Auslieferung). Nicht erforderlich, wenn Sie beabsichtigen, nur ein PCK aus dem Editor zu exportieren und dann die Exportvorlagen-Binärdatei direkt auszuführen, indem Sie sie so umbenennen, dass sie der PCK-Datei entspricht. Siehe den EditorExportPlatform-Header als Referenz. run_icon.svg (16×16) sollte im Plattformordner vorhanden sein, wenn Ein-Klick-Auslieferung für die Target-Plattform implementiert ist. Dieses Icon wird am oberen Rand des Editors angezeigt, wenn One-Click-Deploy für die Target-Plattform eingerichtet ist.

Wenn die Target-Plattform die Ausführung von Vulkan, OpenGL 3.3 oder OpenGL ES 3.0 nicht unterstützt, haben Sie zwei Möglichkeiten:

• Verwenden Sie eine Bibliothek zur Laufzeit, um Vulkan- oder OpenGL-Aufrufe in eine andere Grafik-API zu übersetzen. Zum Beispiel wird MoltenVK unter macOS verwendet, um Vulkan zur Laufzeit in Metal zu übersetzen.

• Erstellen Sie einen neuen Renderer von Grund auf. Das ist ein großes Unterfangen, vor allem, wenn Sie sowohl 2D- als auch 3D-Rendering mit fortgeschrittenen Features unterstützen möchten.

Veröffentlichen einer benutzerdefinierten Plattform-Portierung

Warnung

Stellen Sie vor der Veröffentlichung einer benutzerdefinierten Plattform-Portierung sicher, dass Sie den gesamten Code, gegen den gelinkt wird, veröffentlichen dürfen. Konsolen-SDKs stehen in der Regel unter NDAs, die eine Veröffentlichung an die Öffentlichkeit verhindern.

Plattform-Ports sind so konzipiert, dass sie so eigenständig wie möglich sind. Der Großteil des Codes kann in einem einzigen Ordner in platform/ untergebracht werden. Wie Benutzerdefinierte Module in C++ ermöglicht dies eine Rationalisierung des Build-Prozesses, indem es möglich ist, per git clone einen Plattform-Ordner innerhalb des platform/-Ordners eines Godot-Repository-Klons zu erstellen und dann scons platform=<name> auszuführen. Für die Erstellung sind keine weiteren Schritte erforderlich, es sei denn, plattformspezifische Abhängigkeiten von Drittanbietern müssen zuerst installiert werden.

Wenn jedoch ein benutzerdefiniertes Rendering-Backend benötigt wird, muss ein weiterer Ordner in drivers/ hinzugefügt werden. In diesem Fall kann die Plattform-Portierung als Fork des Godot-Repositorys oder als eine Sammlung mehrerer Ordner veröffentlichen werden, die über einen Godot-Git-Repository-Klon hinzugefügt werden können.