Defold für Unity-Nutzer

Wenn du bereits Erfahrung mit Unity hast, hilft dir dieser Leitfaden dabei, schnell produktiv mit Defold zu arbeiten. Er konzentriert sich auf das Wesentliche und verweist auf die offiziellen Defold-Handbücher, wenn du ausführlichere Informationen benötigst.

Einführung

Defold ist eine vollständig kostenlose, durchgehend plattformübergreifende 3D-Game-Engine mit einem Editor für Windows, Linux und macOS. Der vollständige Quellcode ist auf GitHub verfügbar.

Defold ist auf Leistung ausgelegt, auch auf leistungsschwachen Geräten. Es verwendet ein kleines Komponentenmodell, in dem viele Gameplay-Interaktionen durch Code und Nachrichtenübermittlung verarbeitet werden.

Defold ist viel kleiner als Unity. Die Größe der Engine mit einem leeren Projekt liegt auf allen Plattformen zwischen 1 und 3 MB. Du kannst weitere Teile der Engine entfernen und einige Spielinhalte in Live Update auslagern, um sie später separat herunterzuladen. Einen Größenvergleich und weitere Gründe für Defold findest du auf der Webseite „Warum Defold?“.

Um Defold an deine Anforderungen anzupassen, kannst du Folgendes selbst schreiben oder vorhandene Lösungen verwenden:

1. Eine vollständig skriptgesteuerte Rendering-Pipeline (Render-Skript + Materialien/Shader) mit einigen Backends zur Auswahl (OpenGL, Vulkan usw.).
2. Code und Komponenten (components) als native Erweiterungen (C++/C#).
3. Editor-Skripte und UI-Widgets zum Anpassen des Editors.
4. Einen veränderten Build der Engine und des Editors, da der vollständige Quellcode und eine Build-Pipeline verfügbar sind.

Wir empfehlen außerdem ein Video von Game From Scratch über Defold für Unity-Entwickler.

Installation

1. Lade Defold für dein Betriebssystem herunter.
2. Entpacke es und starte es.

Das war’s. Kein Hub, keine Installation zusätzlicher SDKs, Toolchains oder Plattform-Bundles. Deshalb sagen wir, dass Defold keine Einrichtung benötigt.

Weitere Informationen findest du in diesem kurzen Installationshandbuch.

Versionen

Defold wird häufig aktualisiert und hat keinen „LTS“-Versionszweig. Wir empfehlen, immer die neueste Version zu verwenden. Neue Versionen erscheinen regelmäßig, normalerweise monatlich, mit einer öffentlichen Betaphase von etwa zwei Wochen. Du kannst Defold direkt im Editor aktualisieren.

Willkommensbildschirm

Defold begrüßt dich mit einem Willkommensbildschirm ähnlich dem Unity Hub, auf dem du zuletzt verwendete Projekte öffnen kannst:

Oder du beginnst ein neues Projekt mit:

• Templates - grundlegenden leeren Projekten für einen schnelleren Einstieg auf einer bestimmten Plattform oder in einem bestimmten Genre,
• Tutorials - geführten Lerneinheiten, die dir bei deinen ersten Schritten helfen,
• Samples - offiziellen oder von der Community beigetragenen Anwendungsfällen und Beispielen,

Wenn du dein erstes Projekt erstellst und/oder öffnest, wird es im Defold-Editor geöffnet.

Hallo Welt

So kannst du schnell etwas in Defold umsetzen: Befolge die Schritte und kehre anschließend zurück, um den Rest des Handbuchs zu lesen.

1. Wähle unter Templates ein leeres Projekt aus, gib ihm unter Title einen Namen, wähle einen Speicherort und erstelle es mit einem Klick auf Create New Project. Es wird im Defold-Editor geöffnet.
2. Öffne links im Bereich Assets den Ordner main und doppelklicke auf main.collection, um die Datei zu öffnen.
3. Klicke rechts im Bereich Outline mit der rechten Maustaste auf Collection und wähle Add Game Object.
4. Klicke mit der rechten Maustaste auf das erstellte Spielobjekt (game object) go und wähle Add Component und dann Label.
5. Gib darunter auf der linken Seite im Bereich Properties etwas in die Eigenschaft Text ein.
6. Ziehe die Beschriftung in der zentralen Szenenansicht ungefähr an die Position (480,320,0) und lege sie dort ab, oder ändere ihre Position unter Properties: Position.
7. Nachdem du die Position der Beschriftung geändert hast, speichere das Projekt über File -> Save All oder mit der Tastenkombination Ctrl+S (Cmd+S auf dem Mac).
8. Erstelle einen Build deines Projekts über Project -> Build oder mit der Tastenkombination Ctrl+B (Cmd+B auf dem Mac).

Du hast gerade deinen ersten Projekt-Build in Defold erstellt und solltest deinen Text im Fenster sehen. Die Konzepte Spielobjekt und Komponente sollten dir vertraut sein. Sammlungen (collections), Outline, Eigenschaften und der Grund, warum wir die Beschriftung ein Stück nach rechts oben verschieben mussten, werden im Folgenden erklärt.

Überblick über den Defold-Editor

Wir stellen den Defold-Editor hier aus der Perspektive dessen vor, was Unity-Nutzer anfangs wissen möchten. Wir empfehlen dir aber, anschließend das vollständige Handbuch zum Editor zu lesen.

Vergleich der Editoren

Der erste Unterschied zwischen Unity und Defold, der dir auffallen wird, ist das Standardlayout des Editors. Wir zeigen einen Unity-Editor mit einem leicht angepassten Layout, das dem Standardlayout von Defold entspricht. Die Editoren stehen nebeneinander, damit sich die Hauptbereiche leichter visuell vergleichen lassen und du die Unity-Registerkarten leichter wiedererkennst.

Standardmäßig öffnet sich der Defold-Editor mit einer orthografischen 2D-Vorschau. Wenn du an einem 3D-Projekt arbeitest oder eine Ansicht möchtest, die Unity stärker ähnelt, empfehlen wir, von 2D zu 3D zu wechseln, indem du in der Werkzeugleiste den Schalter 2D deaktivierst und die Kameraprojektion auf perspektivisch umstellst, indem du den Schalter Perspective aktivierst:

Du kannst auch die Grid Settings in der Werkzeugleiste anpassen, um wie in Unity die Y-Ebene zu verwenden:

Überblick über die Bereiche in Defold

Der Defold-Editor ist in 6 Hauptbereiche unterteilt.

Im Folgenden werden die Bezeichnungen und funktionalen Unterschiede von Defold verglichen:

Weitere nützliche Bezeichnungen rund um den Editor:

Grundlegende Konzepte

Wenn man sie ausreichend verallgemeinert, sind die grundlegenden Konzepte der meisten Game-Engines sehr ähnlich. Sie sollen Entwicklern das Erstellen von Spielen erleichtern, ähnlich dem Zusammensetzen von Bausteinen, während sie komplexe und plattformbezogene Aufgaben selbst übernehmen.

Bausteine

Defold arbeitet mit nur wenigen grundlegenden Bausteinen:

Weitere Informationen findest du im vollständigen Handbuch zu den Defold-Bausteinen.

Spielobjekte

Defold verwendet ähnlich wie Unity „Spielobjekte“. In beiden Engines sind Spielobjekte Datencontainer mit einem Bezeichner (ID), und alle haben Transformationen: Position, Drehung und Skalierung. In Defold ist die Transformation jedoch integriert und keine separate Komponente.

Du kannst Eltern-Kind-Beziehungen zwischen Spielobjekten erstellen. In Defold ist dies nur im Editor innerhalb einer „Sammlung“ (unten erläutert) oder dynamisch in einem Skript möglich. Spielobjekte können andere Spielobjekte nicht wie in Unity als verschachtelte Objekte enthalten.

Komponenten

In beiden Engines lassen sich Spielobjekte mit „Komponenten“ erweitern. Defold stellt einen minimalen Satz wesentlicher Komponenten bereit. Es wird weniger zwischen 2D und 3D unterschieden als in Unity (z. B. bei Kollidern), daher gibt es insgesamt weniger Komponenten, und einige aus Unity könnten dir fehlen.

Komponenten für Verhalten

In Unity bezeichnet „Komponente“ normalerweise ein MonoBehaviour, das an ein GameObject angehängt ist. Du kannst eigene Komponenten erstellen, indem du von MonoBehaviour erbst, oder integrierte Komponenten wie Light, einige Physikfunktionen und sonstige Dinge verwenden, und so weiter und so fort.

In Defold bezieht sich Komponente ausschließlich auf das, was den integrierten Komponenten in Unity oder Ähnlichem entspricht. Defold behandelt ein Skript jedoch nicht als MonoBehaviour und verlangt außer dem Erstellen von Listener-Ereignissen/Callbacks keine ausdrückliche „Kennzeichnung“, um es an ein Spielobjekt anzuhängen.

Benutzerdefiniertes Gameplay-Verhalten wird normalerweise nicht in Form vieler separater Skriptkomponenten zu demselben Spielobjekt hinzugefügt. Stattdessen wird es üblicherweise in Lua-Modulen implementiert und von einem zentralen .script verwendet oder von einem übergeordneten Systemskript verarbeitet, das viele Objekte steuert. Der Abschnitt zum Schreiben von Code weiter unten erläutert dies ausführlicher.

Lies hier mehr über Defold-Komponenten.

Die folgende Tabelle zeigt ähnliche Unity-Komponenten zum schnellen Nachschlagen, mit Links zum jeweiligen Handbuch der Defold-Komponente:

Erweiterungen und benutzerdefinierte Komponenten

Defold bietet außerdem offizielle Spine- und Rive-Komponenten über Erweiterungen an.

Du kannst mit nativen Erweiterungen auch eigene benutzerdefinierte Komponenten erstellen, wie beispielsweise diese von der Community entwickelte Komponente zur Objektinterpolation.

Einige Unity-Komponenten haben in Defold keine direkt verfügbare Entsprechung, zum Beispiel Audio Listener, Light, Terrain, LineRenderer, TrailRenderer, Cloth oder Animator. Diese gesamte Funktionalität lässt sich jedoch in Skripten implementieren, und es sind bereits Lösungen verfügbar: beispielsweise verschiedene Beleuchtungs-Pipelines, die Mesh-Komponente zum Erzeugen beliebiger Meshes (einschließlich Gelände) oder Hyper Trails für anpassbare Spureneffekte. Defold könnte in Zukunft auch neue integrierte Komponenten hinzufügen, etwa Lichtquellen.

Ressourcen

Einige Komponenten benötigen ähnlich wie in Unity „Ressourcen“ (resources), zum Beispiel benötigen Sprites und Modelle Texturen. Einige davon werden in der folgenden Tabelle verglichen:

Sammlung im Vergleich zur Szene

In Defold können Spielobjekte und Komponenten ähnlich wie Unity-Prefabs in separaten Dateien liegen oder in einer zusammenführenden „Sammlungsdatei“ definiert sein.

Eine Sammlung in Defold ist im Wesentlichen eine Textdatei mit einer statischen Szenenbeschreibung. Sie ist kein Laufzeitobjekt. Sie definiert lediglich, welche Spielobjekte im Spiel instanziiert werden sollen und wie Eltern-Kind-Beziehungen zwischen diesen Objekten hergestellt werden sollen.

Spielwelten

Unity-Szenen teilen standardmäßig denselben globalen Spielzustand und dieselbe Physiksimulation, also effektiv dieselbe Welt (Spielwelt). In Defold hast du zwei Möglichkeiten:

1. Instanziiere Spielobjekte aus einer einzelnen Spielobjektdatei über eine Factory oder aus einer Sammlungsdatei über eine Collection Factory in einer bestimmten, bereits instanziierten Welt, ähnlich wie Prefabs.
2. Erstelle zur Laufzeit eine separate Spielwelt mit eigenen Spielobjekten, einer eigenen Physikwelt, eigenen Engine-Vorgängen und einem eigenen Namensraum für Adressen über eine beim Start geladene Sammlung oder über eine Komponente vom Typ Collection Proxy, einen Sammlungs-Proxy (collection proxy).

Fabriken und Proxy-Komponenten werden ebenfalls weiter unten erläutert. Lies mehr über Sammlungen im Handbuch zu den Bausteinen.

Projektressourcen und Assets

Unity und Defold speichern Spielinhalte beide im Projektverzeichnis, unterscheiden sich aber darin, wie Assets erfasst und vorbereitet werden.

Assets

Unity legt Assets unter Assets/ ab und erzeugt .meta-Dateien. Defold hat keine Metadateien. Das Projekt in Defold entspricht einfach deiner Ordnerstruktur, genau wie auf dem Datenträger, und der Bereich Assets bildet sie immer ab.

Ressourcenformate

Unity importiert Assets und konvertiert sie im Hintergrund in andere Formate. In Defold arbeitest du direkt mit Quellressourcen (.png, .gltf, .wav, .ogg usw.) und weist sie Components zu.

Unity kann ein einzelnes Bild als Sprite verwenden. In Defold lassen sich Bilder direkt für Modelle/Meshes verwenden, aber Sprites/GUI/Kachelkarten/Partikel benötigen einen Atlas (gepackte Texturen) oder eine Kachelquelle (Kacheln auf einem Raster).

Die meisten Defold-Ressourcen werden als Text gespeichert, was sich gut für die Versionsverwaltung eignet.

Bibliotheks-Cache

Unity erzeugt einen Ordner Library/ für importierte Assets. Defold hat kein solches Verzeichnis; Assets werden beim Erstellen von Builds verarbeitet, und die Ergebnisse werden im Build-Ordner zwischengespeichert (sowie optional in lokalen/entfernten Build-Caches).

Code schreiben

Die Defold-Entsprechung zu MonoBehaviour-Skripten ist eine Skriptkomponente, allerdings gibt es einige wissenswerte Unterschiede.

Lua

Defold-Skripte werden in der dynamisch typisierten Multiparadigmensprache Lua geschrieben.

Es gibt mehrere Arten von Lua-Skripten: *.script, *.gui_script, *.render_script, *.editor_script und *.lua-Module.

Teal

Defold unterstützt Transpiler, die Lua-Code erzeugen, zum Beispiel Teal, einen statisch typisierten Lua-Dialekt. Diese Funktionalität ist allerdings stärker eingeschränkt und erfordert zusätzliche Einrichtung. Weitere Informationen findest du im Repository der Teal-Erweiterung.

Native Erweiterungen in C++/C#

In Defold lassen sich native Erweiterungen in mehreren anderen Sprachen schreiben: je nach Zielplattform in C, C++, C#, Objective-C, Java oder JS. Wenn du dich mit C# sehr gut auskennst, ist es technisch möglich, den Großteil deiner Spiellogik in einer C#-Erweiterung zu strukturieren und lediglich aus einem kleinen Lua-Startskript aufzurufen. Dies erfordert jedoch fortgeschrittene API-Kenntnisse und wird Anfängern nicht empfohlen.

Lies mehr über Erweiterungen im Defold-Handbuch zu nativen Erweiterungen.

Von MonoBehaviours zu Lua-Modulen

Unity hat ein offenes Skriptmodell. Da MonoBehaviour der wichtigste Weg ist, Verhalten im Editor hinzuzufügen, beginnen viele Unity-Projekte mit einem Steuerungsskript pro wichtigem GameObject: PlayerController, EnemyController, BulletController, GameManager, EnemyManager und so weiter.

Defold gibt seine Standardarchitektur konkreter vor. Ein Spielobjekt kann ein .script haben, aber du musst nur selten für jedes Spielobjekt ein Skript erstellen. Dank Defolds leistungsfähiger Adressierung und Nachrichtenübermittlung kann ein einzelnes Skript Hunderte oder Tausende anderer Objekte und ihre Komponenten steuern, ohne dass diese eigene Skripte haben. Passend zu jedem Spielobjekt ein Skript zu erstellen, ist selten erforderlich und kann zu kontraproduktiver Komplexität führen.

Für wiederverwendbares Gameplay-Verhalten gehen Unity-Entwickler oft zur Komposition über: kleinere MonoBehaviour-Skripte wie Health.cs, Attack.cs oder EnemyFinder.cs, die an dasselbe GameObject angehängt werden. In Defold behältst du normalerweise ein angehängtes .script als zentralen Koordinator bei und legst wiederverwendbare Logik in gewöhnlichen Lua-Modulen ab.

In Unity könnte diese Komposition so aussehen:

Player
├── PlayerMovement.cs
├── PlayerAttack.cs
├── EnemyFinder.cs
└── Health.cs

In Defold werden dieselben Zuständigkeiten oft zwischen einem angehängten Skript und wiederverwendbaren Modulen aufgeteilt:

player.go
├── sprite
├── collisionobject
└── player.script

modules/
├── player_movement.lua
├── player_attack.lua
├── enemy_finder.lua
└── health.lua

Das angehängte .script wird zum zentralen Koordinator. Die Lua-Module enthalten wiederverwendbare Logik, ähnlich wie kleine MonoBehaviour-Skripte in Unity oft jeweils eine Zuständigkeit abdecken.

local movement = require "modules.player_movement"
local attack = require "modules.player_attack"
local finder = require "modules.enemy_finder"
local health = require "modules.health"

function init(self)
    self.movement = movement.new(self)
    self.attack = attack.new(self)
    self.finder = finder.new(self)
    self.health = health.new(self)
end

function update(self, dt)
    self.movement:update(dt)
    self.attack:update(dt)
    self.finder:update(dt)
end

function on_message(self, message_id, message, sender)
    self.health:on_message(message_id, message, sender)
    self.attack:on_message(message_id, message, sender)
end

Der wichtige Unterschied besteht nicht darin, dass Defold modulare Architektur verhindert, sondern darin, wo die Komposition stattfindet und wie Gameplay-Code kommuniziert:

Das kann sich anfangs ungewohnt anfühlen, insbesondere wenn du Verhalten gewöhnlich durch das Hinzufügen von Komponenten im Inspector konfigurierst. In Defold lassen sich viele Dinge, die du in Unity vielleicht visuell konfigurierst, stattdessen über Code erstellen, verbinden, aktivieren, deaktivieren oder aktualisieren. Defolds Nachrichtensystem hilft, Logik zu entkoppeln: Der Absender sendet Daten an eine Adresse, und der Empfänger entscheidet, was er damit macht.

Obwohl dieser Ansatz empfohlen wird, ist er nicht vorgeschrieben. Du kannst deine Skripte weiterhin so schreiben, wie du möchtest, einschließlich mehrerer Skripte pro Spielobjekt oder eines stärker objektorientierten Programmierstils. Es gibt sogar Bibliotheken, die dich dabei unterstützen (defold-oop oder lua-class).

Bei vielen Objekten desselben Typs, etwa Geschossen, Gegnern, Partikeln, Kacheln oder einfachen interaktiven Elementen, ist es oft besser, sie aus einem System- oder Verwaltungsskript zu steuern, statt jedem Objekt ein separates Skript zu geben. Verwende eigene Skripte pro Objekt, wenn ein Objekt einen eigenen relevanten Zustand und eigenes Verhalten hat. Verwende Module für wiederverwendbare Logik. Verwende Systemskripte, wenn ein Skript viele Objekte effizient steuern kann.

Ein Beispiel dafür, wie du Skripteigenschaften, Fabriken, Adressierung und Nachrichten in Defold zur Steuerung mehrerer Einheiten nutzt, findest du hier.

Nützliche Handbücher zum Schreiben von Code:

• Skripthandbuch
• Code schreiben
• Debugging

Integrierter Code-Editor

Der Defold-Editor enthält einen integrierten Code-Editor mit Codevervollständigung, Syntaxhervorhebung, schnellem Nachschlagen in der Dokumentation, statischer Codeprüfung und einem integrierten Debugger.

VS Code und andere Editoren

Du kannst weiterhin deinen eigenen externen Editor verwenden, wenn du das bevorzugst. Alle Defold-Komponenten und zugehörigen Dateien sind textbasiert, sodass du sie mit jedem Texteditor bearbeiten kannst. Du musst jedoch die korrekte Formatierung und Elementstruktur einhalten, da sie auf Protobuf basieren.

Wenn du VS Code gewohnt bist und damit den Code deines Spiels schreiben möchtest, empfehlen wir, Defold Kit oder Defold Buddy aus dem Visual Studio Marketplace zu installieren.

Du kannst die Einstellungen des Defold-Editors auch so konfigurieren, dass Textdateien standardmäßig in VS Code (oder einem anderen externen Editor) geöffnet werden. Weitere Informationen findest du unter Editoreinstellungen.

Shader - GLSL

Defold verwendet ähnlich wie Unity GLSL (die OpenGL Shading Language) für Shader: Vertex Programs und Fragment Programs. Obwohl Defold keinen Shader Graph wie Unity bietet (was ein Nachteil sein kann), kannst du durch das Schreiben von Code trotzdem entsprechende Shader erstellen.

Lies mehr über Shader im Shader-Handbuch.

Materialien

Defold verwendet das Konzept Material, das .fp- und .vp-Shader, Sampler (Texturen) und weitere Dinge wie Vertex-Attribute oder Konstanten verbindet.

Lies mehr über Materialien im Materialhandbuch.

Nachrichtensystem

In Defold halten Objekte keine direkten Referenzen aufeinander. Es gibt kein GetComponent, keine objektübergreifenden Methodenaufrufe zwischen Skripten und keinen globalen Szenenzugriff wie in Unity.

Stattdessen kommunizieren Skripte über Nachrichtenübermittlung: Du sendest Nachrichten an andere Skripte, anstatt Methoden aufzurufen oder direkt auf Komponenten zuzugreifen. Was diese Objekte mit den Nachrichten tun, entscheiden sie selbst.

Das kann sich anfangs ungewohnt anfühlen, fördert aber lose Kopplung und verringert enge gegenseitige Abhängigkeiten.

Eine Nachricht senden

In Unity sieht die Kommunikation normalerweise so aus:

var enemy = GameObject.Find("Enemy");
enemy.GetComponent<EnemyAI>().TakeDamage(10);

Objekte können also direkt aufeinander verweisen und Methoden in anderen Skripten aufrufen. Alles befindet sich in einem gemeinsamen Szenenraum.

In Defold sendest du eine Nachricht von einem Skript an ein anderes Skript (oder eine andere Komponente):

msg.post("#my_component", "my_message", { my_name = "Defold" })

Und du kannst diese Nachrichten im Skript verarbeiten:

function on_message(self, message_id, messsage)
    if message_id == hash("my_message") then
        print("Hello ", message.my_name)
    end
end

Ignoriere # und hash vorerst, darauf kommen wir später zurück. Der Rest sollte verständlich sein. Du kannst eine Nachricht an jede Komponente (sogar an dasselbe Skript) eines beliebigen instanziierten Spielobjekts senden.

Andere Komponenten als Skripte

Manchmal sendest du Nachrichten beispielsweise an Komponenten vom Typ Sprite oder Collision, um sie etwa zu aktivieren oder zu deaktivieren. Manchmal senden Components Nachrichten an dein Skript, zum Beispiel bei einer Kollision, damit du sie verarbeiten kannst. Defold verwendet intern dasselbe Nachrichtensystem für Engine-Ereignisse und Gameplay-Kommunikation.

Das Nachrichtensystem ähnelt etwas Unitys SendMessage oder Ereignissystemen, allerdings unterscheiden sich die Adressierung und die Konventionen.

Weitere Informationen findest du im Handbuch zur Nachrichtenübermittlung.

Adressierung

Objekte und Komponenten in Defold werden durch Adressen identifiziert, die als URLs bezeichnet werden.

Jedes instanziierte Objekt und jede Komponente hat eine eigene eindeutige Adresse, und du musst keinen Szenengraphen durchlaufen, um sie zu finden. Dadurch ist die Adressierung explizit und direkt.

Eine einfache URL in Defold könnte so aussehen:

"/player"

Dies ist konzeptionell ähnlich wie:

GameObject.Find("player")

Nun erklären wir, warum "/" oder "#" in Adressen verwendet wurden.

Eine Defold-URL besteht ähnlich wie eine URL aus drei Teilen:

socket: /path #fragment

Oder stärker an Defolds Bezeichnungen angelehnt:

collection: /gameobject #component 

Die Leerzeichen in den obigen Beschreibungen dienen nur dazu, diese 3 Teile optisch zu trennen.

Vereinfacht gesagt:

1. collection: identifiziert den Sammlungskontext, mit : am Ende.
2. /path identifiziert das Spielobjekt, mit / vor der ID.
3. #fragment identifiziert die bestimmte Komponente an diesem Objekt (etwa eine Skript-, Sprite- oder Kollisionskomponente), mit # vor der ID.

Statische Adresse

Diese Bezeichner werden beim Erstellen des jeweiligen Elements festgelegt und ändern sich nie, auch wenn du die Eltern-Kind-Beziehungen änderst. Du kannst sie in Dateien über die Eigenschaft Id festlegen oder erhältst sie zur Laufzeit beim Instanziieren durch Aufrufe von factory.create oder collectionfactory.create.

Relative Adressierung

Du musst nicht immer eine vollständige URL verwenden.

Wenn du Nachrichten innerhalb derselben Sammlung (derselben Welt) sendest, kannst du den Socket-Teil weglassen:

/gameobject #component

Wenn du an eine Komponente innerhalb desselben Spielobjekts sendest, kannst du auch den Spielobjekt-Teil weglassen:

#component

Zwei nützliche Kurzformen sind:

• # zum Senden an diese Skriptkomponente
• . zum Senden an alle Komponenten in diesem Spielobjekt

Mit relativer Adressierung und Kurzformen kannst du URLs schreiben, die in unterschiedlichen Kontexten und Spielobjekten wiederverwendbar sind, ohne vollständige Pfade anzugeben.

Nachrichten an GUI und Rendering

Da Defold die GUI-Welt von der Welt der Spielobjekte trennt, kannst du auch Nachrichten aus den .scripts deiner Spielobjekte an .gui_scripts senden.

Du kannst außerdem Nachrichten an spezielle Systemnamensräume senden, indem du einen Bezeichner verwendest, der mit @ beginnt. Das Render-System lässt sich beispielsweise über @render: adressieren. Damit kannst du bestimmte integrierte Rendering-Funktionen steuern, etwa die Projektion im Standard-Render-Skript ändern:

msg.post("@render:", "use_stretch_projection", { near = -1, far = 1 })

Weitere Informationen findest du im Handbuch zur Adressierung.

Prefabs und Instanzen

Unity kann alles in der Szene statisch oder dynamisch instanziieren, und Defold kann das ebenfalls. In Unity nimmst du ein Prefab und rufst Instantiate(prefab) auf. In Defold stehen dir 3 Komponenten zum Instanziieren von Inhalten zur Verfügung:

• Factory - instanziiert ein einzelnes Spielobjekt aus einem vorgegebenen Prototyp: einer *.go-Datei (Prefab).
• Collection Factory - instanziiert eine Gruppe von Spielobjekten mit Eltern-Kind-Beziehungen aus einem vorgegebenen Prototyp: einer *.collection-Datei.
• Collection Proxy - lädt und instanziiert eine neue Welt aus einer *.collection-Datei.

Fabrik

Sobald du eine Komponente vom Typ Factory definiert und ihre Eigenschaft Prototype auf die passende Spielobjektdatei gesetzt hast, genügt zum Erzeugen einer Instanz folgender Codeaufruf:

factory.create("#my_factory")

Dieser verwendet die Adresse der Komponente, in diesem Fall einen relativen Pfad mit dem Bezeichner "#my_factory".

Er gibt den Bezeichner der neu erstellten Instanz zurück. Wenn du ihn später verwenden möchtest, lohnt es sich daher, ihn in einer Variablen zu speichern:

local new_instance_id = factory.create("#my_factory")

Denk daran, dass du Objekte in Defold nicht manuell in Pools verwalten musst. Die Engine übernimmt das Pooling intern für dich.

Weitere Informationen findest du im Handbuch zu Fabriken.

Sammlungsfabrik

Der Unterschied zwischen den Komponenten Factory und Collection Factory besteht darin, dass eine Sammlungsfabrik mehrere Spielobjekte gleichzeitig erzeugen und beim Erstellen die Eltern-Kind-Beziehungen entsprechend der *.collection-Datei festlegen kann.

Diese Unterscheidung gibt es in Unity nicht; es hat kein eigenes Konzept, das Defolds Sammlungsfabrik entspricht. Die ähnlichste Entsprechung ist ein verschachteltes Prefab, das eine Hierarchie von Objekten enthält.

Sie gibt eine Tabelle mit den IDs aller erzeugten Instanzen zurück:

local spawned_instances = collectionfactory.create("#my_collectionfactory")

Weitere Informationen findest du im Handbuch zu Sammlungsfabriken.

Benutzerdefinierte Eigenschaften von Instanzen

Beim Aufruf von factory.create() oder collectionfactory.create() kannst du auch optionale Parameter wie Position, Drehung, Skalierung und Skripteigenschaften angeben. So kannst du genau steuern, wie und wo die Instanz erscheint und wie sie sich verhält, zum Beispiel:

local scale_2d = vmath.vector3(0.5, 0.5, 1.0)
factory.create("#my_factory", my_position, my_rotation, my_properties, scale_2d)

Bei den optionalen Argumenten stehen die Eigenschaften vor der Skalierung. Verwende einen vector3, dessen Z-Wert ausdrücklich auf 1.0 gesetzt ist, wenn du nur die X- und Y-Achse eines 2D-Objekts skalierst; ein numerischer Skalierungsfaktor wird gleichmäßig auf alle drei Achsen angewendet.

Dynamisches Laden

Sowohl in Komponenten vom Typ Factory als auch vom Typ Collection Factory kannst du einen Prototyp für das dynamische Laden von Ressourcen markieren. Seine umfangreichen Assets werden dann nur bei Bedarf in den Speicher geladen und entladen, wenn sie nicht mehr verwendet werden.

Weitere Informationen findest du im Handbuch zur Ressourcenverwaltung.

Sammlungs-Proxy

Der Collection Proxy verweist auf eine bestimmte *.collection-Datei. Statt die Objekte wie Fabriken in die aktuelle Welt einzufügen, lädt und instanziiert er eine neue Spielwelt. Das ähnelt dem Laden einer vollständigen Szene in Unity, allerdings mit strikterer Trennung.

In Unity könntest du eine additive Szene so laden:

SceneManager.LoadSceneAsync("Level2", LoadSceneMode.Additive);

In Defold lädst du die neue Sammlung, indem du einfach eine Nachricht an die Komponente Collection Proxy sendest:

msg.post("#myproxy", "load")

1. Wenn du dem Proxy die Nachricht "load" sendest (oder "async_load" zum asynchronen Laden), weist die Engine Speicher für eine neue Welt zu, instanziiert dort alles aus dieser Sammlung und hält die Welt isoliert.
2. Nach dem Laden sendet der Proxy eine Nachricht "proxy_loaded" zurück, die anzeigt, dass die Welt bereit ist.
3. Anschließend sendest du normalerweise die Nachrichten "init" und "enable", damit die Objekte in dieser neuen Welt ihren normalen Lebenszyklus beginnen.

Für die Kommunikation zwischen den geladenen Welten musst du explizite Nachrichtenübermittlung mit URLs verwenden, die den Weltnamen enthalten (collection:, den ersten Teil der URL).

Diese Isolation kann bei der Implementierung von Levelübergängen, Minispielen oder großen modularen Systemen ein großer Vorteil sein: Sie verhindert unbeabsichtigte Interaktionen und ermöglicht bei Bedarf außerdem eine separate Steuerung des zeitlichen Ablaufs der Aktualisierungen (z. B. für Pausen oder Zeitlupe).

Wenn du in Unity schon einmal mehrere Szenen verwendet hast, die sich unabhängig voneinander verhalten mussten, kannst du dir einen Collection Proxy als Möglichkeit vorstellen, dieses Konzept direkt in Defold umzusetzen.

Weitere Informationen findest du im Handbuch zu Sammlungs-Proxys.

Anwendungslebenszyklus

Du kennst bereits eine Reihe von Unity-Lebenszyklusereignissen: Awake, Start, Update, FixedUpdate, LateUpdate, OnDestroy oder OnApplicationQuit.

Defold hat ebenfalls einen klar definierten Anwendungslebenszyklus, aber die Konzepte und Begriffe unterscheiden sich. Defold stellt die Lebenszyklusphasen über eine Reihe vordefinierter Lua-Callbacks bereit, die von der Engine während der Initialisierung, in jedem Frame und bei der Finalisierung aufgerufen werden.

Hier ein Vergleich:

Initialisierung

Stell dir Defolds init() so vor, dass es Elemente von Unitys Awake(), Start() und OnEnable() in einem einzigen Einstiegspunkt vereint. Dort hat die Engine bereits alles eingerichtet, und du kannst den Zustand deiner Komponente sicher vorbereiten.

Wann werden Nachrichten verarbeitet?

Da du bereits in init() Nachrichten senden kannst, werden Nachrichten erstmals direkt nach der Initialisierung zugestellt.

Anschließend werden Nachrichten nach jeder internen Verarbeitungsschleife verarbeitet, sobald sich etwas in einer Warteschlange befindet. Daher kann on_message() zum Beispiel auch mehrmals in einer Aktualisierungsschleife aufgerufen werden.

Aktualisierungsschleife

In jedem Frame durchläuft Defold eine Folge von Vorgängen: Eingaben verarbeiten, Nachrichten zustellen, Skript- und GUI-Aktualisierungen auslösen, Physik und Transformationen anwenden und zum Schluss die Grafik rendern.

Finalisierung

In Defold ist das Aufräumen immer an das Löschen oder Entladen der Welt gebunden, und der einzige Ausstiegspunkt pro Komponente ist final().

Ein subtiler Unterschied zum Modell von Unity besteht darin, dass nicht zwischen dem Deaktivieren einer Komponente und dem Beenden der gesamten Anwendung unterschieden wird.

Rendering

Das Render-Skript (*.render_script) ist ein Teil der Rendering-Pipeline, der mit eigenen Callbacks für init(), update() und on_message() ebenfalls am Lebenszyklus teilnimmt. Diese laufen jedoch im Render-Thread und sind von der Logik der Spielobjekt- und GUI-Skripte getrennt.

Weitere Informationen findest du im Handbuch zum Anwendungslebenszyklus.

GUI

Defolds GUI ist ein einziges eigenständiges Framework für Benutzeroberflächen: Menüs, Overlays, Dialoge und andere Elemente, ähnlich wie UI Toolkit oder uGUI mit Canvas.

GUI ist eine Komponente und von Spielobjekten und Sammlungen getrennt. Anstelle von Spielobjekten arbeitest du mit GUI-Knoten, die in einer Hierarchie angeordnet sind und von einem GUI-Skript gesteuert werden.

GUI-Knoten

Wenn du in Defold eine Komponentendatei vom Typ *.gui öffnest, siehst du eine Zeichenfläche, auf der du "GUI-Knoten" platzierst. Dies sind die Bausteine der GUI. Du kannst GUI-Knoten der folgenden Typen hinzufügen:

• Box (rechteckige Form mit einer Textur)
• Text (mit beliebiger Schriftart)
• Pie (radial gefülltes Kreissektorelement mit einer Textur)
• ParticleFX
• Template (eine weitere vollständige verschachtelte .gui-Datei, ähnlich einem GUI-Prefab)
• und Spine-Knoten, wenn du die Spine-Erweiterung verwendest.

GUI-Skript

GUI-Komponenten haben eine spezielle Eigenschaft für GUI-Skripte: Du weist jeder Komponente eine *.gui_script-Datei zu, mit der sich das Verhalten der Komponente ändern lässt. Das ähnelt gewöhnlichen Skripten, allerdings wird nicht der Namensraum go.* verwendet (der für Spielobjekt-Skripte vorgesehen ist). Stattdessen wird die API des speziellen Namensraums gui.* verwendet, die nur innerhalb von GUI-Skripten (*.gui_script) funktioniert. Du kannst dir das wie eine separate Szene vorstellen. Unity UI (uGUI) mit Canvas.

GUI-Rendering

GUI-Elemente werden unabhängig von der Spielkamera gerendert, üblicherweise im Bildschirmkoordinatensystem. Dieses Verhalten lässt sich jedoch in benutzerdefinierten Rendering-Pipelines ändern.

Weitere Informationen findest du im GUI-Handbuch.

Wo sind die Sorting Layers?

Dies ist eine sehr häufige Ursache für Verwirrung beim Umstieg von Unity.

GUI-Komponenten haben Layers, was fast genauso funktioniert wie „Sorting Layers“ in Unity. Für andere Komponenten wie Sprites, Tilemaps, Models usw. gibt es aber keine direkte Entsprechung.

Stattdessen kombinierst du normalerweise:

• Eine feine Sortierung über die Z-Achse bei Verwendung einer Standardkamera oder über die Tiefe bei Verwendung einer Kamerakomponente.
• Eine grobe Sortierung über das Render-Skript mit Render-Prädikaten, um anhand von Material-Tags auszuwählen, was gezeichnet werden soll.

Du solltest Unitys Sorting Layers jedoch nicht mit vielen Tags nachahmen, da Tags in Defold ein Mechanismus auf Rendering-Ebene sind. Übermäßige Verwendung kann die Bündelung von Zeichenoperationen (Batching) verhindern und den zusätzlichen Aufwand beim Zeichnen erhöhen.

Wie geht es weiter?

• Defold-Beispiele
• Tutorials
• Handbücher
• API-Referenzen
• FAQ

Wenn du Fragen hast oder nicht weiterkommst, sind das Defold-Forum oder Discord gute Anlaufstellen für Hilfe.