Defold para usuários de Unity

Se você já tem experiência com Unity, este guia ajuda você a se tornar produtivo no Defold rapidamente. Ele foca no essencial e aponta para os manuais oficiais do Defold sempre que detalhes mais profundos forem necessários.

Introdução

O Defold é uma engine de jogos 3D totalmente gratuita e verdadeiramente multiplataforma, com um Editor para Windows, Linux e macOS. O código-fonte completo está disponível no Github.

O Defold é focado em desempenho, mesmo em dispositivos de baixo custo. Ele usa um modelo de componentes pequeno, em que muitas interações de gameplay são tratadas por código e passagem de mensagens.

O Defold é muito menor que o Unity. O tamanho da engine com um projeto vazio fica entre 1-3 MB em todas as plataformas. Você pode remover partes adicionais da engine e mover parte do conteúdo do jogo para Live Update, baixando-o separadamente depois. Uma comparação de tamanho e outros motivos para escolher o Defold são descritos na página Why Defold.

Para personalizar o Defold conforme suas necessidades, você pode escrever por conta própria ou usar algo existente:

1. Pipeline de renderização totalmente programável (script de renderização + materiais/shaders), com alguns backends para escolher (OpenGL, Vulkan etc.).
2. Código e componentes como Native Extensions (C++/C#).
3. Editor Scripts e widgets de UI para personalizar o Editor.
4. Builds alteradas da engine e do editor, já que o código-fonte completo e um pipeline de build estão disponíveis.

Também recomendamos assistir ao vídeo da Game From Scratch sobre Defold para desenvolvedores Unity.

Instalação

1. Baixe o Defold para o seu sistema operacional.
2. Descompacte e execute.

É isso. Sem hub, sem SDK adicional, sem instalação de toolchains ou bundles de plataforma. É por isso que dizemos que o Defold não exige configuração inicial.

Se precisar de mais detalhes, leia este curto manual de instalação.

Versões

O Defold é atualizado com frequência e não tem uma trilha “LTS”. Recomendamos sempre usar a versão mais recente. Novas versões são lançadas regularmente - normalmente todo mês, com cerca de duas semanas de beta público. Você pode atualizar o Defold diretamente pelo Editor.

Tela de boas-vindas

O Defold recebe você com uma tela de boas-vindas semelhante ao Unity Hub, onde é possível abrir projetos recentes:

Ou iniciar um novo a partir de:

• Templates - projetos vazios básicos para uma configuração mais rápida para uma plataforma ou gênero específico,
• Tutorials - tours guiados de aprendizado que ajudam você a dar os primeiros passos,
• Samples - casos de uso e exemplos oficiais ou contribuídos pela comunidade,

Quando você criar seu primeiro projeto e/ou abri-lo, ele será aberto no Defold Editor.

Hello World

Esta é uma forma rápida de fazer algo no Defold: siga os passos e depois volte para ler o restante do manual.

1. Selecione um projeto vazio em Templates, dê um nome em Title, escolha um local e crie-o clicando em Create New Project. Ele será aberto no Defold Editor.
2. No lado esquerdo, no painel Assets, abra a pasta main e dê duplo clique em main.collection para abri-la.
3. No lado direito, no painel Outline, clique com o botão direito em Collection e selecione Add Game Object.
4. Clique com o botão direito no objeto de jogo go criado, selecione Add Component e depois Label.
5. Abaixo, no lado esquerdo, no painel Properties, digite algo na propriedade Text.
6. Na visualização principal e central da cena, arraste, mova e solte o label para uma posição em torno de (480,320,0), ou altere isso em Properties: Position.
7. Depois de alterar a posição do label, salve o projeto clicando em File -> Save All ou usando o atalho Ctrl+S (Cmd+S no Mac).
8. Compile seu projeto clicando em Project -> Build ou usando o atalho Ctrl+B (Cmd+B no Mac).

Você acabou de compilar seu primeiro projeto no Defold e deve ver seu texto na janela. Os conceitos de objeto de jogo e componente devem ser familiares para você. As coleções, outline, propriedades e o motivo de termos movido um pouco o label na direção superior direita são explicados abaixo.

Visão geral do Defold Editor

Apresentaremos o Defold Editor aqui pela perspectiva do que um usuário de Unity talvez queira saber primeiro, mas recomendamos também conferir o manual completo de visão geral do editor depois.

Comparação dos editores

A primeira diferença que você notará entre Unity e Defold é o layout padrão do Editor. Estamos mostrando um Unity Editor com um layout levemente modificado para corresponder ao layout padrão do Defold. Eles estão lado a lado para facilitar a comparação visual dos painéis principais, já que assim você deve reconhecer mais facilmente as abas do Unity.

Por padrão, o Defold Editor abre em uma pré-visualização 2D ortográfica. Se você vai trabalhar em um projeto 3D, ou apenas quer uma experiência mais próxima do Unity, recomendamos mudar de 2D para 3D desmarcando o alternador 2D na barra de ferramentas e alterando a projeção da câmera para perspectiva marcando o alternador Perspective:

Você também pode ajustar as Grid Settings na barra de ferramentas para usar o plano Y, como no Unity:

Visão geral dos painéis do Defold

O Defold Editor é dividido em 6 painéis principais.

Abaixo está uma comparação da nomenclatura do Defold e das diferenças funcionais:

Outras nomenclaturas úteis relacionadas ao Editor:

Conceitos principais

Se você generalizar o suficiente, os conceitos principais por trás da maioria das engines de jogos são muito parecidos. Eles existem para ajudar desenvolvedores a criar jogos com mais facilidade, como montar blocos, enquanto lidam por conta própria com tarefas complexas e relacionadas a plataforma.

Blocos de construção

O Defold trabalha com apenas alguns blocos básicos de construção:

Para mais detalhes, consulte o manual completo sobre blocos de construção do Defold.

Game Objects

O Defold usa “Game Objects”, semelhante ao Unity. Em ambas as engines, objetos de jogo são contêineres de dados com um ID, e todos têm transformações: posição, rotação e escala. Mas no Defold, a transformação é integrada em vez de ser um componente separado.

Você pode criar relações pai-filho entre objetos de jogo. No Defold, isso só pode ser feito no Editor dentro de uma “Collection” (explicada abaixo) ou dinamicamente por script. Objetos de jogo não podem conter outros objetos de jogo como objetos aninhados da mesma forma que podem no Unity.

Components

Em ambas as engines, Game Objects podem ser estendidos com “Components”. O Defold fornece um conjunto mínimo de componentes essenciais. Há menos distinção entre 2D e 3D do que no Unity (por exemplo, colliders), então há menos componentes no geral, e alguns do Unity podem fazer falta.

Componentes de comportamento

No Unity, “component” geralmente significa um MonoBehaviour anexado a um GameObject. Você pode criar o seu herdando de MonoBehaviour ou usar componentes integrados, como Light, alguns itens de física e assim por diante.

No Defold, Component se refere exclusivamente ao equivalente aos componentes integrados do Unity; o Defold não trata um script como um monobehaviour e não exige nenhuma “marcação” explícita para anexá-lo a um game object, além de criar callbacks/eventos de escuta.

Comportamento personalizado de gameplay geralmente não é adicionado como muitos componentes de script separados no mesmo objeto de jogo. Em vez disso, ele costuma ser implementado em módulos Lua e usado por um .script hospedeiro, ou tratado por um script de sistema maior que controla muitos objetos. A seção Escrita de código abaixo cobre isso com mais detalhes.

Leia mais sobre Componentes do Defold aqui.

A tabela abaixo apresenta componentes semelhantes do Unity para consulta rápida, com links para cada manual de componente do Defold:

Extensões e componentes personalizados

O Defold também tem componentes oficiais Spine e Rive disponíveis por extensões.

Você também pode criar seus próprios Components personalizados usando Native Extensions, como este Object Interpolation Component criado pela comunidade.

Alguns componentes do Unity não têm equivalente pronto no Defold, por exemplo: Audio Listener, Light, Terrain, LineRenderer, TrailRenderer, Cloth ou Animator. Porém, toda essa funcionalidade pode ser implementada em scripts, e já existem soluções disponíveis - por exemplo, diferentes pipelines de iluminação, o componente Mesh para gerar malhas arbitrárias (incluindo terreno), ou Hyper Trails para efeitos de trilha personalizáveis. O Defold também pode adicionar novos componentes integrados no futuro, como luzes.

Resources

Alguns Components exigem “Resources”, semelhante ao Unity; por exemplo, sprites e modelos precisam de texturas. Alguns deles são comparados na tabela abaixo:

Collection vs Scene

No Defold, Game Objects e Components podem ser colocados em arquivos separados, como prefabs do Unity, ou definidos em um arquivo combinado de “Collection”.

Uma Collection no Defold é essencialmente um arquivo de texto com uma descrição estática de cena. Ela não é um objeto em tempo de execução. Ela apenas define quais Game Objects devem ser instanciados no jogo e como as relações pai-filho entre esses objetos devem ser estabelecidas.

Game Worlds

Cenas do Unity compartilham por padrão o mesmo estado global do jogo e a mesma simulação física, efetivamente o mesmo world. No Defold, você tem duas opções:

1. Instanciar objetos de jogo a partir de um único arquivo de objeto de jogo por uma Factory, ou de um arquivo de coleção por uma Collection Factory, para um world já instanciado, como prefabs.
2. Criar um world de jogo separado em tempo de execução, com seus próprios objetos de jogo, mundo físico, operações da engine e namespace de endereçamento, por meio de uma coleção carregada no bootstrap ou por um componente Collection Proxy.

Fábricas e componentes Proxy também são explicados abaixo. Leia mais sobre Collections no manual Building Blocks.

Recursos e assets do projeto

Unity e Defold armazenam conteúdo de jogo no diretório do projeto, mas diferem em como assets são rastreados e preparados.

Assets

O Unity mantém assets em Assets/ e gera arquivos .meta. O Defold não tem arquivos meta. O projeto no Defold é apenas sua estrutura de pastas, exatamente como no disco, e o painel Assets sempre a espelha.

Formatos de recurso

O Unity importa e converte assets para outros formatos nos bastidores. No Defold, você trabalha diretamente com recursos-fonte (.png, .gltf, .wav, .ogg etc.) e os atribui a Components.

O Unity pode usar uma única imagem como Sprite. No Defold, imagens podem ser usadas diretamente para Models/Meshes, mas Sprites/GUI/Tilemaps/Particles exigem um atlas (texturas empacotadas) ou um tilesource (tiles em grade).

A maioria dos recursos do Defold é armazenada como texto, o que é amigável para controle de versão.

Library Cache

O Unity gera uma pasta Library/ para assets importados. O Defold não tem esse diretório; assets são processados durante builds, com saídas em cache na pasta de build (e caches de build locais/remotos opcionais).

Escrita de código

Um equivalente do Defold aos scripts MonoBehaviour é um componente Script, mas há algumas diferenças importantes.

Lua

Scripts do Defold são escritos em Lua, uma linguagem dinâmica e multiparadigma.

Há alguns tipos de scripts Lua: *.script, *.gui_script, *.render_script, *.editor_script e módulos *.lua.

Teal

O Defold suporta o uso de transpilers que emitem código Lua, como Teal - um dialeto de Lua com tipagem estática -, mas essa funcionalidade é mais limitada e exige configuração adicional. Detalhes estão disponíveis no repositório da extensão Teal.

Native Extensions em C++/C#

No Defold, Native Extensions podem ser escritas em várias outras linguagens: C, C++, C#, Objective-C, Java ou JS, dependendo da plataforma-alvo. Se você se sente muito confortável com C#, tecnicamente é possível estruturar a maior parte da lógica do jogo em uma extensão C# e apenas chamá-la a partir de um pequeno script Lua de bootstrap, embora isso exija conhecimento avançado de API e não seja recomendado para iniciantes.

Leia mais sobre extensões no manual Defold Native Extensions.

De MonoBehaviours para módulos Lua

O Unity tem um modelo aberto de scripts. Como MonoBehaviour é a principal forma de adicionar comportamento no editor, muitos projetos Unity começam com um script no estilo controlador para cada GameObject importante: PlayerController, EnemyController, BulletController, GameManager, EnemyManager e assim por diante.

O Defold é mais específico sobre sua arquitetura padrão. Um objeto de jogo pode ter um .script, mas raramente você precisa criar um script para cada Game Object, porque um único script no Defold pode controlar centenas ou milhares de outros objetos e seus componentes, mesmo que eles não tenham scripts próprios, graças ao poderoso endereçamento e passagem de mensagens do Defold. Criar scripts para corresponder a cada Game Object raramente é necessário e pode levar a uma complexidade contraproducente.

Para comportamento de gameplay reutilizável, desenvolvedores Unity frequentemente avançam para composição: scripts MonoBehaviour menores, como Health.cs, Attack.cs ou EnemyFinder.cs, anexados ao mesmo GameObject. No Defold, você geralmente mantém um .script anexado como host ou coordenador e coloca a lógica reutilizável em módulos Lua comuns.

No Unity, essa composição poderia ficar assim:

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

No Defold, as mesmas responsabilidades costumam ser divididas entre um script anexado e módulos reutilizáveis:

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

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

O .script anexado se torna o host ou coordenador. Os módulos Lua contêm lógica reutilizável, semelhante a como pequenos scripts MonoBehaviour geralmente contêm uma responsabilidade no Unity.

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

A diferença importante não é que o Defold impeça uma arquitetura modular; é onde a composição acontece e como o código de gameplay se comunica:

Isso pode parecer estranho no começo, especialmente se você está acostumado a configurar comportamento adicionando componentes no Inspector. No Defold, muitas coisas que você talvez configurasse visualmente no Unity podem ser criadas, conectadas, ativadas, desativadas ou atualizadas por código. O sistema de mensagens do Defold ajuda a desacoplar a lógica: o remetente posta dados para um endereço, e o receptor decide o que fazer com eles.

Essa abordagem, embora recomendada, não é imposta, e você ainda pode escrever seus scripts como quiser, inclusive anexando vários scripts por objeto de jogo ou se aproximando de um estilo de programação orientado a objetos. Também existem bibliotecas para ajudar nisso (defold-oop ou lua-class).

Para muitos objetos do mesmo tipo, como projéteis, inimigos, partículas, tiles ou elementos interativos simples, muitas vezes é melhor controlá-los a partir de um script de sistema ou gerenciador em vez de dar a cada objeto um script separado. Use scripts por objeto quando um objeto tiver seu próprio estado e comportamento significativos. Use módulos quando quiser lógica reutilizável. Use scripts de sistema quando um script puder controlar muitos objetos de forma eficiente.

Um exemplo mostrando como usar propriedades de script do Defold, factories, endereçamento e mensagens para controlar várias unidades pode ser encontrado aqui.

Bons manuais sobre escrita de código:

• Manual de Script
• Escrevendo código
• Depuração

Editor de código integrado

O Defold Editor inclui um editor de código integrado com autocompletar, destaque de sintaxe, consulta rápida de documentação, linting e um depurador integrado.

VS Code e outros editores

Você ainda pode usar seu próprio editor externo se preferir. Todos os componentes do Defold e arquivos relacionados são baseados em texto, então você pode editá-los com qualquer editor de texto, mas deve seguir a formatação e a estrutura de elementos corretas, já que eles são baseados em Protobuf.

Se você está acostumado com VS Code e quer usá-lo para escrever o código do seu jogo, recomendamos instalar Defold Kit ou Defold Buddy pelo Visual Studio Marketplace.

Você também pode configurar as preferências do Defold Editor para abrir arquivos de texto por padrão no VS Code (ou qualquer outro editor externo). Veja Editor Preferences para detalhes.

Shaders - GLSL

O Defold usa GLSL (OpenGL Shading Language) para shaders - Vertex Programs e Fragment Programs, semelhante ao Unity. Embora o Defold não ofereça um Shader Graph como o Unity (o que pode ser uma desvantagem), você ainda pode criar shaders equivalentes escrevendo código.

Leia mais sobre shaders no manual de Shaders.

Materials

O Defold usa o conceito de Material, que conecta shaders .fp e .vp, samplers (texturas) e outras coisas como Vertex Attributes ou Constants.

Leia mais sobre materiais no manual de Materials.

Sistema de mensagens

No Defold, objetos não mantêm referências diretas uns aos outros. Não existe GetComponent, não há chamadas de método entre scripts de objetos diferentes e não há acesso global à cena como no Unity.

Em vez disso, scripts se comunicam por passagem de mensagens: você envia mensagens a outros scripts em vez de chamar métodos ou acessar componentes diretamente. O que esses objetos fazem com as mensagens depende deles.

Isso pode parecer estranho no começo, mas promove baixo acoplamento e reduz interdependências rígidas.

Enviando uma mensagem

No Unity, a comunicação geralmente se parece com isto:

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

Assim, objetos podem referenciar diretamente uns aos outros e chamar métodos em outros scripts. Tudo existe em um único espaço de cena compartilhado.

No Defold, você envia uma mensagem de um script para outro script (ou outro componente):

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

E pode tratar essas mensagens no script:

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

Ignore # e hash por enquanto; falaremos disso depois. O restante deve ser direto. Você pode enviar uma mensagem para qualquer componente (até para o mesmo script) de qualquer objeto de jogo instanciado.

Componentes que não são scripts

Às vezes você envia mensagens para componentes como Sprite ou Collision, por exemplo, para ativá-los ou desativá-los. Às vezes Components enviam mensagens para seu script, por exemplo quando uma colisão ocorre, para que você possa tratá-la. Internamente, o Defold usa o mesmo sistema de mensagens para eventos da engine e comunicação de gameplay.

O sistema de mensagens é um pouco semelhante ao SendMessage do Unity ou a sistemas de eventos, embora o endereçamento e as convenções sejam diferentes.

Você pode ler mais detalhes no Manual de Passagem de Mensagens.

Endereçamento

Objetos e componentes no Defold são identificados por endereços, conhecidos como URLs.

Cada objeto e componente instanciado tem seu próprio endereço único, e você não precisa percorrer um grafo de cena para encontrá-los. Isso torna o endereçamento explícito e direto.

Uma URL simples no Defold pode ser assim:

"/player"

Isso é conceitualmente semelhante a:

GameObject.Find("player")

Agora é hora de explicar por que "/" ou "#" foram usados nos endereços.

Uma URL Defold (semelhante a URL) consiste em três partes:

socket: /path #fragment

ou, descrito com a nomenclatura do Defold:

collection: /gameobject #component 

Os espaços nas descrições acima foram adicionados apenas para separar visualmente essas 3 partes.

Em termos simples:

1. collection: identifica o contexto de coleção, com : no fim.
2. /path identifica o Game Object, com / antes do ID.
3. #fragment identifica o componente específico nesse objeto (como script, sprite ou componente de colisão), com # antes do ID.

Endereço estático

Esses identificadores são determinados na criação de cada item e nunca mudam, mesmo que você altere relações pai-filho. Você pode defini-los na propriedade Id dos arquivos, ou obtê-los em tempo de execução por chamadas a factory.create ou collectionfactory.create, ao instanciar.

Endereçamento relativo

Você nem sempre precisa usar uma URL completa.

Se enviar mensagens dentro da mesma coleção (o mesmo world), pode omitir a parte do socket:

/gameobject #component

Se estiver enviando para um componente dentro do mesmo objeto de jogo, também pode omitir a parte do objeto de jogo:

#component

Dois atalhos úteis são:

• # para enviar a este componente Script
• . para enviar a todos os componentes neste Game Object

Endereçamento relativo e atalhos permitem escrever URLs reutilizáveis em diferentes contextos e objetos de jogo sem especificar caminhos completos.

Mensagens para GUI e render

Como o Defold separa o mundo da GUI do mundo dos Game Objects, você também pode enviar mensagens de .scripts de objetos de jogo para .gui_scripts.

Você também pode enviar mensagens para namespaces especiais do sistema usando um identificador que começa com @. Por exemplo, o sistema de renderização pode ser endereçado via @render: e você pode usar isso para controlar certos recursos integrados de renderização, como alterar a projeção no script de renderização padrão:

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

Mais detalhes podem ser encontrados no manual de Endereçamento.

Prefabs e instâncias

O Unity pode instanciar qualquer coisa na Scene de forma estática ou dinâmica, e o Defold pode fazer o mesmo. No Unity, você pega um Prefab e chama Instantiate(prefab). No Defold, há 3 componentes para instanciar conteúdo:

• Factory - instancia um único Game Object a partir de um determinado protótipo: um arquivo *.go (prefab).
• Collection Factory - instancia um conjunto de Game Objects com relações pai-filho a partir de um determinado protótipo: um arquivo *.collection.
• Collection Proxy - carrega e instancia um novo world a partir de um arquivo *.collection.

Factory

Depois de definir um componente Factory com sua propriedade Prototype apontando para o arquivo de Game Object apropriado, instanciar é tão simples quanto chamar no código:

factory.create("#my_factory")

Isso usa o endereço do componente, neste caso um caminho relativo usando o identificador "#my_factory".

Ele retorna o identificador da instância recém-criada, então se você precisar usá-la depois vale armazená-la em uma variável:

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

Lembre-se de que, no Defold, você não precisa criar pools de objetos manualmente - a própria engine faz pooling internamente para você.

Confira mais detalhes no manual de Factory.

Collection Factory

A diferença entre os componentes Factory e Collection Factory é que Collection Factory pode instanciar vários objetos de jogo de uma só vez e definir, na criação, as relações pai-filho conforme definidas no arquivo *.collection.

Essa distinção não existe no Unity; ele não tem um conceito dedicado que corresponda à Collection Factory do Defold. A analogia mais próxima é apenas um Prefab aninhado que contém uma hierarquia de objetos.

Ela retorna uma tabela com os ids de todas as instâncias criadas:

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

Confira mais detalhes no manual de Collection Factory.

Propriedades personalizadas de instâncias

Ao chamar factory.create() ou collectionfactory.create(), você também pode especificar parâmetros opcionais como posição, rotação, escala e propriedades de script, para controlar exatamente como e onde a instância aparece e como ela se comporta, por exemplo:

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

Carregamento dinâmico

Tanto em componentes Factory quanto Collection Factory, você pode marcar um Prototype para carregamento dinâmico de recursos, de modo que seus assets pesados só sejam carregados para a memória quando necessário e descarregados quando não forem mais usados.

Confira mais detalhes no manual de Gerenciamento de Recursos.

Collection Proxy

O Collection Proxy referencia um arquivo *.collection específico, mas em vez de injetar os objetos no world atual (como factories), ele carrega e instancia um novo mundo de jogo. Isso é um pouco semelhante a carregar uma cena inteira no Unity, mas com separação mais rígida.

No Unity, você poderia carregar uma cena aditiva assim:

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

No Defold, você carrega a nova coleção simplesmente enviando uma mensagem ao componente Collection Proxy:

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

1. Quando você envia ao proxy uma mensagem "load" (ou "async_load" para carregamento assíncrono), a engine aloca um novo world, instancia tudo nessa coleção ali e o mantém isolado.
2. Depois de carregado, o proxy envia de volta uma mensagem "proxy_loaded" indicando que o world está pronto.
3. Então você normalmente envia mensagens "init" e "enable" para que os objetos nesse novo world comecem seu ciclo de vida normal.

Para se comunicar entre os worlds carregados, você precisa usar mensagens explícitas com URLs que incluam o nome do world (collection:, a primeira parte da URL).

Esse isolamento pode ser uma grande vantagem ao implementar transições de nível, minigames ou grandes sistemas modulares, porque evita interações não intencionais e também permite controle separado sobre o tempo de atualização, se necessário (por exemplo, para pausa ou câmera lenta).

Se você já usou várias cenas no Unity e precisou que elas se comportassem de forma independente, pense em um Collection Proxy como uma forma de trazer esse conceito diretamente para o Defold.

Confira mais detalhes no manual de Collection Proxy.

Ciclo de vida da aplicação

Você conhece um conjunto de eventos de ciclo de vida do Unity: Awake, Start, Update, FixedUpdate, LateUpdate, OnDestroy ou OnApplicationQuit.

O Defold também tem um ciclo de vida da aplicação bem definido, mas os conceitos e a terminologia diferem. O Defold expõe estágios do ciclo de vida por meio de um conjunto de callbacks Lua predefinidos, chamados pela engine durante a inicialização, a cada frame e na finalização.

Aqui está uma comparação:

Inicialização

Pense no init() do Defold como a combinação de elementos de Awake(), Start() e OnEnable() do Unity em um único ponto de entrada, onde a engine já configurou tudo e você pode preparar com segurança o estado do seu componente.

Quando as mensagens são tratadas?

Como você já pode postar mensagens em init(), as mensagens são despachadas primeiro logo após a inicialização.

Depois, as mensagens são tratadas após cada loop interno de processamento, sempre que há algo em uma fila. Assim, on_message() pode ser chamado, por exemplo, até várias vezes em um loop de atualização.

Loop de atualização

A cada frame, o Defold passa por uma sequência de operações - tratar entrada, despachar mensagens, disparar atualizações de scripts e GUI, aplicar física, transformações e, no fim, renderizar gráficos.

Finalização

No Defold, limpeza está sempre ligada à exclusão ou ao descarregamento do world, e seu único hook de saída por componente é final().

Uma diferença sutil em relação ao modelo do Unity é que não há distinção entre um componente ser desativado e a aplicação inteira ser encerrada.

Renderização

O script de renderização (*.render_script) faz parte do pipeline de renderização, que também participa do ciclo de vida com seus próprios callbacks init(), update() e on_message(), mas eles operam na thread de renderização e são separados da lógica de scripts de objetos de jogo e GUI.

Para mais detalhes, leia o Manual do Ciclo de Vida da Aplicação.

GUI

A GUI do Defold é um framework inteiro e dedicado para interfaces de usuário - menus, sobreposições, diálogos e outros elementos, semelhante ao UI Toolkit ou uGUI com Canvas.

GUI é um Component e é separada de Game Objects e Collections. Em vez de Game Objects, você trabalha com nós de GUI organizados em uma hierarquia, controlados por um script de GUI.

Nós de GUI

Ao abrir um arquivo de componente *.gui no Defold, você vê um canvas onde posiciona "GUI nodes". Eles são os blocos de construção da GUI. Você pode adicionar nós de GUI do tipo:

• Box (forma retangular com uma textura)
• Text (com qualquer fonte)
• Pie (elemento radial de preenchimento tipo fatia com uma textura)
• ParticleFX
• Template (outro arquivo .gui inteiro aninhado, como um prefab de GUI)
• e nó Spine, ao usar a extensão Spine.

GUI Script

O componente GUI tem uma propriedade especial para scripts de GUI: você atribui um arquivo *.gui_script por componente, e isso permite modificar o comportamento do componente. Ele é muito semelhante a scripts comuns, exceto que não usa o namespace go.* (que é para scripts de objeto de jogo). Em vez disso, usa uma API especial no namespace gui.*, que só funciona dentro de scripts de GUI (*.gui_script). Você pode pensar nisso como uma Scene separada. Unity UI (uGUI) com Canvas.

Renderização de GUI

Elementos de GUI são renderizados independentemente da câmera do jogo, normalmente em screen-space, mas esse comportamento pode ser alterado em pipelines de renderização personalizados.

Para mais detalhes, leia o Manual de GUI.

Onde estão as Sorting Layers?

Esta é uma dúvida muito comum na migração a partir do Unity.

Componentes GUI têm Layers, e isso funciona quase da mesma forma que “Sorting Layers” no Unity. Mas para outros componentes, como Sprites, Tilemaps, Models etc., não há um equivalente direto.

Em vez disso, você normalmente combina:

• Ordenação fina pelo eixo Z ao usar uma câmera padrão ou profundidade ao usar um componente Camera.
• Ordenação mais ampla pelo script de renderização usando predicados de renderização - para selecionar o que desenhar por tags de material.

Mas você não deve imitar Sorting Layers do Unity com muitas tags, porque no Defold tags são um mecanismo no nível da renderização. Usá-las em excesso pode quebrar batching e aumentar o custo de draw.

Para onde ir agora?

• Exemplos do Defold
• Tutoriais
• Manuais
• Referências de API
• FAQ

Se você tiver dúvidas ou ficar travado, o Fórum Defold ou o Discord são ótimos lugares para pedir ajuda.