Defold dla użytkowników Unity

Jeśli masz wcześniejsze doświadczenie z Unity, ten przewodnik pomoże ci szybko zacząć pracę w Defold. Skupia się na podstawach i odsyła do oficjalnych instrukcji Defold, gdy potrzebujesz głębszych szczegółów.

Wprowadzenie

Defold to całkowicie darmowy, naprawdę wieloplatformowy silnik 3D do gier z edytorem dla Windows, Linux i macOS. Pełny kod źródłowy jest dostępny na GitHub.

Defold stawia na wydajność, nawet na słabszych urządzeniach. Jego architektura oparta na komponentach i danych jest trochę podobna do podejścia DOTS w Unity.

Defold jest znacznie mniejszy niż Unity. Rozmiar silnika z pustym projektem wynosi od 1 do 3 MB na wszystkich platformach. Możesz odciąć dodatkowe części silnika i przenieść część zawartości gry do Live Update, aby pobierać ją później osobno. Porównanie rozmiarów i inne powody, dla których warto wybrać Defold, opisano na stronie Dlaczego Defold.

Aby dostosować Defold do swoich potrzeb, możesz użyć własnych rozwiązań albo gotowych:

1. W pełni skryptowalny pipeline renderowania (render script + materiały/shadery) z kilkoma backendami do wyboru (OpenGL, Vulkan itd.).
2. Kod i komponenty jako Native Extensions (C++/C#).
3. Skrypty edytora i widżety UI do dostosowywania edytora.
4. Zmodyfikowana wersja silnika i edytora, ponieważ dostępny jest pełny kod źródłowy i pipeline budowania.

Polecamy też film Game From Scratch o Defold dla programistów Unity.

Instalacja

1. Pobierz Defold dla swojego systemu operacyjnego.
2. Rozpakuj go i uruchom.

To wszystko. Bez huba, bez dodatkowych SDK, toolchainów ani pakietów platform. Dlatego mówimy, że Defold ma zerową konfigurację początkową.

Jeśli potrzebujesz więcej szczegółów, przeczytaj krótką instrukcję instalacji.

Wersje

Defold jest aktualizowany często i nie ma gałęzi „LTS”. Zawsze zalecamy korzystanie z najnowszej wersji. Nowe wersje są wydawane regularnie - zwykle co miesiąc, z około dwutygodniową publiczną betą. Defold możesz aktualizować bezpośrednio w edytorze.

Ekran powitalny

Defold wita cię ekranem powitalnym podobnym do Unity Hub, z którego możesz otwierać ostatnie projekty:

Możesz też rozpocząć nowy projekt z:

• Templates - podstawowe puste projekty do szybszego startu dla konkretnej platformy lub gatunku,
• Tutorials - prowadzone ścieżki nauki, które pomagają postawić pierwsze kroki,
• Samples - oficjalne albo społecznościowe przykłady zastosowań i demonstracje,

Gdy utworzysz i/lub otworzysz swój pierwszy projekt, zostanie on otwarty w Defold Editor.

Witaj, świecie

To szybki sposób, aby sprawnie zrobić coś w Defold, wykonać kroki, a potem wrócić do reszty instrukcji.

1. Wybierz pusty projekt z Templates, wpisz nazwę w Title, wybierz lokalizację i utwórz go, klikając Create New Project. Zostanie otwarty w Defold Editor.
2. Po lewej stronie, w panelu Assets, otwórz folder main i kliknij dwukrotnie main.collection, aby go otworzyć.
3. Po prawej stronie, w panelu Outline, kliknij prawym przyciskiem myszy Collection i wybierz Add Game Object.
4. Kliknij prawym przyciskiem myszy utworzony obiekt gry go i wybierz Add Component, a następnie Label.
5. Niżej, po lewej stronie, w panelu Properties wpisz coś we właściwości Text.
6. W głównym, centralnym widoku sceny przeciągnij, przesuń i upuść etykietę tak, aby znalazła się około (480,320,0), albo zmień tę wartość w Properties, w polu Position.
7. Po zmianie pozycji etykiety zapisz projekt, klikając File -> Save All albo używając skrótu Ctrl+S (Cmd+S na Macu).
8. Zbuduj projekt, klikając Project -> Build albo używając skrótu Ctrl+B (Cmd+B na Macu).

Właśnie zbudowałeś swój pierwszy projekt w Defold i powinieneś zobaczyć tekst w oknie. Pojęcia obiektu gry i komponentu powinny być ci już znane. Kolekcje, Outline, Properties oraz to, dlaczego trzeba było przesunąć etykietę trochę w górę i w prawo, wyjaśniamy poniżej.

Przegląd edytora Defold

Tutaj pokażemy Defold Editor z perspektywy tego, co użytkownik Unity może chcieć wiedzieć na początku, ale zachęcamy, aby potem zajrzeć do pełnej instrukcji przeglądu edytora.

Porównanie edytorów

Pierwsza różnica, którą zauważysz między Unity a Defold, to domyślny układ edytora. Pokazujemy Unity Editor z lekko zmodyfikowanym układem, aby odpowiadał domyślnemu układowi Defold. Umieszczono je obok siebie, aby łatwiej porównać główne panele, dzięki czemu łatwiej rozpoznasz zakładki Unity.

Domyślnie Defold Editor otwiera się w ortograficznym podglądzie 2D. Jeśli będziesz pracować nad projektem 3D albo po prostu chcesz wrażenie bliższe Unity, zalecamy przełączenie z 2D na 3D przez odznaczenie przełącznika 2D na pasku narzędzi i zmianę projekcji kamery na perspektywiczną przez zaznaczenie przełącznika Perspective:

Możesz też dostosować Grid Settings na pasku narzędzi tak, aby używały płaszczyzny Y, tak jak w Unity:

Przegląd paneli Defold

Defold Editor jest podzielony na 6 głównych paneli.

Poniżej znajduje się porównanie nazewnictwa i różnic funkcjonalnych:

Inne przydatne nazewnictwo związane z edytorem:

Kluczowe pojęcia

Jeśli wystarczająco uogólnisz, kluczowe pojęcia stojące za większością silników gier są bardzo podobne. Mają pomagać twórcom gier budować je łatwiej, jak z klocków, podczas gdy silnik sam obsługuje złożone zadania zależne od platformy.

Elementy składowe

Defold operuje tylko kilkoma podstawowymi elementami składowymi:

Więcej szczegółów znajdziesz w pełnej instrukcji o elementach składowych Defold.

Obiekty gry

Defold używa “Game Objects”, podobnie jak Unity. W obu silnikach obiekty gry są kontenerami danych z identyfikatorem i wszystkie mają transformacje: pozycję, obrót i skalę, ale w Defold transformacja jest wbudowana, a nie dostarczana przez osobny komponent.

Możesz tworzyć relacje rodzic-dziecko między obiektami gry. W Defold można to zrobić tylko w edytorze, wewnątrz “Collection” (wyjaśnionej niżej), albo dynamicznie w skrypcie. Obiekty gry nie mogą zawierać innych obiektów gry jako zagnieżdżonych obiektów tak, jak ma to miejsce w Unity.

Komponenty

W obu silnikach obiekty gry można rozszerzać o “Components”. Defold udostępnia minimalny zestaw niezbędnych komponentów. Różnica między 2D i 3D jest mniejsza niż w Unity (na przykład przy colliderach), więc komponentów jest ogólnie mniej, a niektórych z Unity może ci brakować.

Więcej o komponentach Defold przeczytasz tutaj.

Poniższa tabela pokazuje podobne komponenty Unity, aby ułatwić szybkie porównanie, wraz z linkami do instrukcji każdego komponentu Defold:

Rozszerzenia i własne komponenty

Defold ma też oficjalne komponenty Spine i Rive dostępne przez rozszerzenia.

Możesz też tworzyć własne niestandardowe komponenty przy użyciu Native Extensions, na przykład taki społecznościowy Object Interpolation Component.

Niektóre komponenty Unity nie mają w Defold gotowego odpowiednika od razu po instalacji, na przykład: Audio Listener, Light, Terrain, LineRenderer, TrailRenderer, Cloth czy Animator. Całą tę funkcjonalność można jednak zaimplementować w skryptach, a gotowe rozwiązania już istnieją - na przykład różne pipeline’y oświetlenia, komponent Mesh do generowania dowolnych siatek (w tym terenu) albo Hyper Trails do konfigurowalnych efektów śladu. Defold może też w przyszłości dodać nowe wbudowane komponenty, takie jak światła.

Zasoby

Niektóre komponenty wymagają “Resources”, podobnie jak w Unity, na przykład sprite’y i modele potrzebują tekstur. Kilka z nich porównano w tabeli poniżej:

Kolekcja kontra scena

W Defold obiekty gry i komponenty mogą być umieszczane w osobnych plikach, podobnie jak prefaby w Unity, albo definiowane w łączącym pliku “Collection”.

Kolekcja w Defold to w praktyce plik tekstowy ze statycznym opisem sceny. To nie jest obiekt działający w czasie działania programu. Definiuje jedynie to, jakie obiekty gry mają zostać utworzone w grze oraz jak mają zostać ustanowione relacje rodzic-dziecko między tymi obiektami.

Światy gry

Sceny Unity domyślnie współdzielą ten sam globalny stan gry i tę samą symulację fizyki, czyli w praktyce ten sam świat. W Defold masz dwie opcje:

1. Utworzyć obiekty gry z pojedynczego pliku obiektu gry przez Factory albo z pliku kolekcji przez Collection Factory w już utworzonym świecie, podobnie jak prefaby.
2. Utworzyć w czasie działania oddzielny świat gry z własnymi obiektami gry, światem fizyki, operacjami silnika i przestrzenią adresową, korzystając z kolekcji wczytanej podczas bootstrapu albo z komponentu Collection Proxy.

Fabryki i komponenty proxy są omówione także niżej. Więcej o kolekcjach przeczytasz w instrukcji o elementach składowych.

Zasoby projektu i assety

Unity i Defold przechowują zawartość gry w katalogu projektu, ale różnią się sposobem śledzenia i przygotowywania zasobów.

Assety

Unity trzyma assety w Assets/ i generuje pliki meta. Defold nie ma plików meta. Projekt w Defold to po prostu struktura twoich folderów, dokładnie taka jak na dysku, a panel Assets zawsze ją odzwierciedla.

Formaty zasobów

Unity importuje i konwertuje assety do innych formatów w tle. W Defold pracujesz bezpośrednio z zasobami źródłowymi (.png, .gltf, .wav, .ogg itd.) i przypisujesz je do Components.

Unity może używać pojedynczego obrazu jako Sprite. W Defold obrazy mogą być używane bezpośrednio przez Model/Mesh, ale Sprite/GUI/Tilemap/Particles wymagają atlasu (spakowanych tekstur) albo tilesource (kafelków opartych na siatce).

Większość zasobów Defold jest przechowywana jako tekst, więc dobrze współpracuje z systemami kontroli wersji.

Pamięć podręczna biblioteki

Unity generuje katalog Library/ dla importowanych assetów. Defold nie ma takiego katalogu; assety są przetwarzane podczas budowania, a wynik trafia do cache’a w katalogu builda oraz opcjonalnych lokalnych lub zdalnych cache’y budowania.

Pisanie kodu

Częstą pułapką dla osób przechodzących z Unity jest traktowanie skryptów Defold jak MonoBehaviour i dołączanie jednego do każdego obiektu gry. Oczywiście można pisać w stylu obiektowym, a nawet istnieją biblioteki, które w tym pomagają, ale zalecanym podejściem, zwłaszcza przy wielu podobnych obiektach gry, jest używanie skryptów jako systemów lub menedżerów. Jeden skrypt może kontrolować setki lub tysiące obiektów i ich komponentów, nawet jeśli same obiekty nie mają własnych skryptów, dzięki silnemu adresowaniu i systemowi wiadomości w Defold. Tworzenie osobnego skryptu dla każdego obiektu jest rzadko potrzebne i może prowadzić do nieproduktywnej złożoności.

Przykład pokazujący, jak wykorzystać właściwości skryptu Defold, fabryki, adresowanie i wiadomości do sterowania wieloma jednostkami, znajdziesz tutaj.

Dobre instrukcje o pisaniu kodu:

• Instrukcja o skryptach
• Pisanie kodu
• Debugowanie

Lua

Skrypty Defold są pisane w dynamicznie typowanym, wieloparadygmatycznym języku Lua.

Istnieje kilka typów skryptów Lua: *.script, *.gui_script, *.render_script, *.editor_script oraz moduły *.lua.

Teal

Defold wspiera używanie transpilerów, które generują kod Lua, takich jak Teal - statycznie typowany dialekt Lua, ale ta funkcjonalność jest bardziej ograniczona i wymaga dodatkowej konfiguracji. Szczegóły są dostępne w repozytorium rozszerzenia Teal.

Native Extensions C++/C#

W Defold możesz pisać Native Extensions w C++ i C#. Jeśli bardzo dobrze znasz C#, technicznie możliwe jest zbudowanie większości logiki gry w rozszerzeniu C# i wywoływanie jej z małego bootstrapowego skryptu Lua, choć wymaga to zaawansowanej znajomości API i nie jest zalecane dla początkujących.

Więcej o rozszerzeniach przeczytasz w instrukcji Native Extensions Defold.

Wbudowany edytor kodu

Defold Editor zawiera wbudowany edytor kodu z podpowiadaniem kodu, podświetlaniem składni, szybkim podglądem dokumentacji, lintingiem i wbudowanym debuggerem.

VS Code i inne edytory

Nadal możesz używać własnego zewnętrznego edytora, jeśli wolisz. Wszystkie komponenty Defold i powiązane pliki są tekstowe, więc możesz edytować je dowolnym edytorem tekstu, ale musisz zachować prawidłowe formatowanie i strukturę elementów, ponieważ są oparte na Protobuf.

Jeśli przywykłeś do VS Code i chcesz używać go do pisania kodu swojej gry, zalecamy zainstalowanie Defold Kit albo Defold Buddy z Visual Studio Marketplace.

Możesz też skonfigurować preferencje Defold Editor tak, aby pliki tekstowe otwierały się domyślnie w VS Code albo w innym zewnętrznym edytorze. Szczegóły znajdziesz w instrukcji preferencji edytora.

Shadery - GLSL

Defold używa GLSL (OpenGL Shading Language) do shaderów - Vertex Programs i Fragment Programs, podobnie jak Unity. Chociaż Defold nie oferuje czegoś takiego jak Shader Graph w Unity, nadal możesz tworzyć równoważne shadery, pisząc kod.

Więcej o shaderach przeczytasz w instrukcji o shaderach.

Materiały

Defold używa pojęcia Material, które łączy shadery .fp i .vp, samplery (tekstury) oraz inne elementy, takie jak Vertex Attributes albo Constants.

Więcej o materiałach przeczytasz w instrukcji o materiałach.

System wiadomości

W Defold obiekty nie trzymają bezpośrednich referencji do siebie nawzajem. Nie ma GetComponent, nie ma wywołań metod między obiektami z poziomu skryptów i nie ma globalnego dostępu do sceny jak w Unity.

Zamiast tego skrypty komunikują się przez przekazywanie wiadomości: wysyłasz wiadomości do innych skryptów zamiast bezpośrednio wywoływać metody albo odwoływać się do komponentów. To, co te obiekty zrobią z wiadomościami, zależy już od nich.

Na początku może to wydawać się nieznane, ale sprzyja luźnemu powiązaniu i zmniejsza ścisłe zależności.

Wysyłanie wiadomości

W Unity komunikacja zwykle wygląda tak:

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

Obiekty mogą więc bezpośrednio odwoływać się do siebie nawzajem i wywoływać metody na innych skryptach. Wszystko istnieje w jednej współdzielonej przestrzeni sceny.

W Defold wysyłasz wiadomość z jednego skryptu do innego skryptu (lub innego komponentu):

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

A potem możesz obsłużyć te wiadomości w skrypcie:

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

Na razie zignoruj # i hash, wrócimy do tego później. Reszta powinna być prosta. Możesz wysłać wiadomość do dowolnego komponentu (nawet do tego samego skryptu) dowolnego utworzonego obiektu gry.

Komponenty inne niż skrypty

Czasem wysyłasz wiadomości na przykład do komponentów Sprite albo Collision, aby je włączyć lub wyłączyć. Czasem Components wysyłają wiadomości do twojego skryptu, na przykład gdy dochodzi do kolizji, abyś mógł ją obsłużyć. Defold wewnętrznie używa tego samego systemu wiadomości zarówno do zdarzeń silnika, jak i do komunikacji w rozgrywce.

System wiadomości jest do pewnego stopnia podobny do Unity SendMessage albo systemów zdarzeń, choć adresowanie i konwencje są inne.

Więcej szczegółów znajdziesz w instrukcji o przekazywaniu wiadomości.

Adresowanie

Obiekty i komponenty w Defold są identyfikowane przez adresy, znane jako URL-e.

Każdy utworzony obiekt i komponent ma własny unikalny adres i nie musisz przechodzić po grafie sceny, aby go znaleźć. Dzięki temu adresowanie jest jawne i bezpośrednie.

Prosty URL w Defold może wyglądać tak:

"/player"

To jest pojęciowo podobne do:

GameObject.Find("player")

Teraz czas wyjaśnić, dlaczego w adresach użyto "/" albo "#".

URL Defold (podobny do URL) składa się z trzech części:

socket: /path #fragment

albo, opisując to bardziej w nazewnictwie Defold:

collection: /gameobject #component 

W powyższych opisach spacje dodano tylko po to, aby wizualnie rozdzielić te 3 części.

W skrócie:

1. collection: identyfikuje kontekst kolekcji, z : na końcu.
2. /path identyfikuje obiekt gry, z / poprzedzającym identyfikator.
3. #fragment identyfikuje konkretny komponent na tym obiekcie, na przykład skrypt, sprite albo komponent kolizji, z # poprzedzającym identyfikator.

Adres statyczny

Te identyfikatory są ustalane przy tworzeniu każdego z nich i nigdy się nie zmieniają, nawet jeśli zmienisz relacje rodzic-dziecko. Możesz je ustawić we właściwości Id w plikach albo otrzymać w czasie działania z wywołań factory.create lub collectionfactory.create, podczas instancjowania.

Adresowanie względne

Nie zawsze musisz używać pełnego URL.

Jeśli wysyłasz wiadomości w obrębie tej samej kolekcji (tego samego świata), możesz pominąć część socket:

/gameobject #component

Jeśli wysyłasz do komponentu w tym samym obiekcie gry, możesz pominąć także część obiektu gry:

#component

Dwa przydatne skróty to:

• # do wysyłania do tego komponentu Script
• . do wysyłania do wszystkich komponentów w tym Game Object

Adresowanie względne i skróty pozwalają pisać URL-e, które można ponownie wykorzystać w różnych kontekstach i obiektach gry bez podawania pełnych ścieżek.

Wiadomości do GUI i renderowania

Ponieważ Defold oddziela świat GUI od świata obiektów gry, możesz też wysyłać wiadomości z komponentów .script w świecie obiektów gry do .gui_script.

Możesz również wysyłać wiadomości do specjalnych przestrzeni nazw systemu, używając identyfikatora zaczynającego się od @. Na przykład system renderowania można adresować przez @render: i użyć tego do sterowania niektórymi wbudowanymi funkcjami renderowania, takimi jak zmiana projekcji w domyślnym skrypcie renderowania:

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

Więcej szczegółów znajdziesz w instrukcji o adresowaniu.

Prefaby i instancje

Unity może tworzyć instancje wszystkiego w scenie statycznie albo dynamicznie, a Defold może zrobić to samo. W Unity bierzesz Prefab i wywołujesz Instantiate(prefab). W Defold masz 3 komponenty do tworzenia instancji zawartości:

• Factory - tworzy instancję pojedynczego Game Object z danego prototypu: pliku *.go (prefaba).
• Collection Factory - tworzy instancję zestawu Game Objectów z relacjami rodzic-dziecko z danego prototypu: pliku *.collection.
• Collection Proxy - ładuje i tworzy instancję nowego świata z pliku *.collection.

Factory

Gdy zdefiniujesz komponent Factory i ustawisz jego właściwość Prototype na odpowiedni plik obiektu gry, tworzenie instancji sprowadza się po prostu do wywołania w kodzie:

factory.create("#my_factory")

Używa to adresu komponentu, w tym przypadku - względnej ścieżki z identyfikatorem "#my_factory".

Zwraca identyfikator nowo utworzonej instancji, więc jeśli potrzebujesz użyć go później, warto zapisać go w zmiennej:

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

Pamiętaj, że w Defold nie musisz ręcznie tworzyć puli obiektów - silnik sam obsługuje pooling wewnętrznie.

Więcej szczegółów znajdziesz w instrukcji o fabryce.

Collection Factory

Różnica między komponentami Factory i Collection Factory polega na tym, że Collection Factory może jednocześnie utworzyć wiele obiektów gry i zdefiniować przy tworzeniu relacje rodzic-dziecko zgodnie z plikiem *.collection.

Takiego rozróżnienia nie ma w Unity - nie ma tam dedykowanej koncepcji odpowiadającej Collection Factory w Defold. Najbliższą analogią jest po prostu zagnieżdżony Prefab, który zawiera hierarchię obiektów.

Zwraca table z identyfikatorami wszystkich utworzonych instancji:

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

Więcej szczegółów znajdziesz w instrukcji o Collection Factory.

Własne właściwości instancji

Wywołując factory.create() lub collectionfactory.create(), możesz też podać opcjonalne parametry, takie jak pozycja, obrót, skala i właściwości skryptu, aby dokładnie kontrolować, gdzie i jak pojawi się instancja oraz jak będzie się zachowywać, na przykład:

factory.create("#my_factory", my_position, my_rotation, my_scale, my_properties)

Dynamiczne wczytywanie

Zarówno w komponentach Factory, jak i Collection Factory możesz oznaczyć Prototype do dynamicznego wczytywania zasobów, aby ciężkie assety były ładowane do pamięci tylko wtedy, gdy są potrzebne, i zwalniane, gdy przestają być używane.

Więcej szczegółów znajdziesz w instrukcji zarządzania zasobami.

Collection Proxy

Collection Proxy odnosi się do konkretnego pliku *.collection, ale zamiast wstrzykiwać obiekty do bieżącego świata (jak robią to fabryki), ładuje i tworzy instancję nowego świata gry. Jest to trochę podobne do wczytywania całej sceny w Unity, ale z silniejszym rozdzieleniem.

W Unity możesz wczytać scenę addytywną na przykład tak:

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

W Defold nową kolekcję wczytujesz po prostu, wysyłając wiadomość do komponentu Collection Proxy:

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

1. Gdy wysyłasz do proxy wiadomość "load" (albo "async_load" w przypadku wczytywania asynchronicznego), silnik alokuje nowy świat, instancjuje tam wszystko z tej kolekcji i izoluje go.
2. Gdy wczytywanie się zakończy, proxy odsyła wiadomość "proxy_loaded", sygnalizując, że świat jest gotowy.
3. Następnie zwykle wysyłasz wiadomości "init" i "enable", aby obiekty w tym nowym świecie rozpoczęły swój normalny cykl życia.

Aby komunikować się między wczytanymi światami, musisz używać jawnych wiadomości z URL-ami, które zawierają nazwę świata (collection:, czyli pierwszą część URL).

Takie odseparowanie może być ogromną zaletą przy implementowaniu przejść między poziomami, minigierek lub dużych modularnych systemów, ponieważ zapobiega niezamierzonym interakcjom, a dodatkowo pozwala w razie potrzeby osobno sterować tempem aktualizacji, na przykład na potrzeby pauzy albo spowolnienia czasu.

Jeśli kiedykolwiek używałeś wielu scen w Unity i potrzebowałeś, żeby działały niezależnie, potraktuj Collection Proxy jako sposób przeniesienia tej koncepcji bezpośrednio do Defold.

Więcej szczegółów znajdziesz w instrukcji o Collection Proxy.

Cykl życia aplikacji

Znasz już zestaw zdarzeń cyklu życia Unity: Awake, Start, Update, FixedUpdate, LateUpdate, OnDestroy albo OnApplicationQuit.

Defold również ma jasno określony cykl życia aplikacji, ale pojęcia i terminologia są inne. Defold udostępnia etapy cyklu życia przez zestaw predefiniowanych wywołań zwrotnych Lua, które są wywoływane przez silnik podczas inicjalizacji, każdej klatki i finalizacji.

Oto porównanie:

::: sidenote Pamiętaj, że Defold nie gwarantuje żadnej kolejności wykonywania między komponentami, gdy kilka z nich jest inicjalizowanych, aktualizowanych albo usuwanych naraz. Zachęca się do projektowania odseparowanego.

Inicjalizacja

Można myśleć o init() w Defold jako o połączeniu elementów Awake(), Start() i OnEnable() z Unity w jeden punkt wejścia, w którym silnik już wszystko przygotował i możesz bezpiecznie ustawić stan komponentu.

Kiedy obsługiwane są wiadomości?

Ponieważ wiadomości można już wysyłać w init(), są one rozsyłane jako pierwsze tuż po inicjalizacji.

Wiadomości są następnie obsługiwane po każdej wewnętrznej pętli przetwarzania, za każdym razem, gdy coś znajduje się w kolejce, więc on_message() może zostać wywołane na przykład nawet kilka razy w jednej pętli aktualizacji.

Pętla aktualizacji

W każdej klatce Defold wykonuje sekwencję operacji - obsługę wejścia, rozsyłanie wiadomości, uruchamianie aktualizacji skryptów i GUI, stosowanie fizyki, transformacji, a na końcu renderowanie grafiki.

Finalizacja

W Defold czyszczenie jest zawsze powiązane z usunięciem lub zwolnieniem świata, a jedynym punktem wyjścia dla pojedynczego komponentu jest final().

Subtelna różnica względem modelu Unity polega na tym, że nie ma rozróżnienia między wyłączeniem komponentu a zamknięciem całej aplikacji.

Renderowanie

Skrypt renderowania (*.render_script) jest częścią pipeline’u renderowania, który również uczestniczy w cyklu życia za pomocą własnych callbacków init(), update() i on_message(), ale działają one na wątku renderowania i są odseparowane od logiki skryptów obiektów gry i GUI.

Więcej szczegółów znajdziesz w instrukcji o cyklu życia aplikacji.

GUI

GUI w Defold to pojedynczy, dedykowany framework dla interfejsów użytkownika - menu, nakładek, okien dialogowych i innych elementów, podobnie jak UI Toolkit albo uGUI z Canvas.

GUI jest komponentem i jest odseparowane od obiektów gry oraz kolekcji. Zamiast obiektów gry pracujesz z węzłami GUI ułożonymi w hierarchię i sterowanymi przez skrypt GUI.

Węzły GUI

Gdy otworzysz plik komponentu *.gui w Defold, zobaczysz płótno, na którym umieszczasz "GUI nodes". To podstawowe elementy budujące GUI. Możesz dodawać węzły GUI typu:

• Box (prostokątny kształt z teksturą)
• Text (z dowolną czcionką)
• Pie (element w postaci wycinka koła z radialnym wypełnieniem i teksturą)
• ParticleFX
• Template (cały zagnieżdżony plik .gui, jak prefab GUI)
• Spine node, gdy używasz rozszerzenia Spine.

Skrypt GUI

Komponent GUI ma specjalną właściwość dla skryptów GUI - przypisujesz jeden plik *.gui_script do każdego komponentu i pozwala to modyfikować zachowanie komponentu, więc jest to bardzo podobne do zwykłych skryptów, z tą różnicą, że nie używa przestrzeni nazw go.* (która służy do skryptów obiektów gry). Zamiast tego korzysta ze specjalnego API w przestrzeni nazw gui.*, które działa tylko wewnątrz skryptów GUI (*.gui_script). Można o tym myśleć jak o osobnej scenie Unity UI (uGUI) z Canvas.

Renderowanie GUI

Elementy GUI są renderowane niezależnie od kamery gry, zwykle w przestrzeni ekranu, ale to zachowanie można zmienić w niestandardowych pipeline’ach renderowania.

Więcej szczegółów znajdziesz w instrukcji o GUI.

Gdzie są Sorting Layers?

To bardzo częste źródło nieporozumień podczas migracji z Unity.

Komponenty GUI mają Layers i działa to niemal tak samo jak “Sorting Layers” w Unity, ale dla innych komponentów, takich jak Sprites, Tilemaps, Models itd., nie ma bezpośredniego odpowiednika.

Zamiast tego zwykle łączy się:

• precyzyjne porządkowanie wzdłuż osi Z przy użyciu domyślnej kamery albo głębokości przy użyciu komponentu Camera,
• zgrubne porządkowanie przez skrypt renderowania z użyciem render predicates - aby wybierać, co ma być rysowane na podstawie tagów materiałów.

Nie próbuj jednak naśladować Sorting Layers z Unity za pomocą wielu tagów, ponieważ w Defold tagi są mechanizmem na poziomie renderowania. Nadużywanie ich może zepsuć batching i zwiększyć narzut rysowania.

Co dalej?

• Przykłady Defold
• Samouczki
• Instrukcje
• Dokumentacja API
• FAQ

Jeśli masz pytania albo utkniesz, Forum Defold albo Discord to świetne miejsca, żeby poprosić o pomoc.