Como Migrar da Unity para a Godot: Guia Honesto Para Quem Vem da Unity

Se você chegou até aqui, provavelmente já decidiu que quer testar a saída, ou pelo menos entender como seria migrar da Unity para a Godot na prática. Este guia é para desenvolvedores que já programam, já entregaram algo na Unity e agora querem saber, sem hype, o que muda de verdade. A boa notícia: muito do que você sabe transfere. A notícia honesta: a Godot não é uma Unity com outra pintura, ela pensa o jogo de um jeito diferente, e é justamente esse jeito que você precisa entender antes de escrever a primeira linha.

Por que devs estão saindo da Unity

Não vou inventar números. Os motivos que mais aparecem em conversas reais são: mudanças no modelo de licenciamento e cobrança que geraram desconfiança, o peso e a complexidade do editor para projetos pequenos, e o desejo de usar uma engine de código aberto onde nada some da noite para o dia. A Godot entra como alternativa leve, gratuita, sem royalties e com um editor que abre rápido.

Isso não significa que a Unity seja ruim. Ela continua sendo uma ferramenta poderosa, com recursos que a Godot ainda não tem no mesmo nível, principalmente em 3D pesado e em pipelines de estúdio grande. A escolha aqui é de contexto, não de torcida. Se você quer o comparativo completo, sem lado, escrevi um separado sobre Godot e Unity ponto a ponto. Este texto assume que você já quer migrar e precisa do mapa.

O modelo mental: nós no lugar de GameObjects e componentes

Essa é a mudança mais importante, e a que mais confunde no começo. Guarde bem.

Na Unity, você tem um GameObject vazio e pendura componentes nele: um Transform, um Rigidbody, um AudioSource, um script MonoBehaviour. O GameObject é um saco de componentes.

Na Godot, não existe esse saco genérico. Existe o Node, e cada tipo de nó já é uma coisa com função definida. Um Sprite2D mostra imagem. Um AudioStreamPlayer toca som. Um CollisionShape2D define colisão. Você não adiciona um componente de som a um objeto, você adiciona um nó filho que toca som. A composição acontece pela árvore de nós, não por uma lista de componentes.

Então onde a Unity tem um GameObject com quatro componentes, a Godot tem um nó pai com quatro nós filhos, cada um responsável por uma parte. Um personagem vira algo como: um CharacterBody2D como raiz, com um Sprite2D, um CollisionShape2D e um AudioStreamPlayer2D pendurados abaixo dele.

O equivalente ao prefab é a cena (.tscn). Uma cena é uma árvore de nós salva em arquivo, e pode ser instanciada quantas vezes quiser, exatamente como um prefab. E aqui vem um detalhe elegante: na Godot tudo é cena. A fase inteira é uma cena, o inimigo é uma cena, o botão do menu é uma cena, e você aninha cenas dentro de cenas. Não existe a distinção rígida entre "cena de jogo" e "prefab" que a Unity faz.

O MonoBehaviour também some como conceito central. Na Godot, um script é anexado a um nó e estende o tipo daquele nó. Você não cria um componente separado, você especializa o comportamento do nó ali mesmo.

O mapa de tradução

Com o modelo mental no lugar, o resto é quase um dicionário. Aqui está o que você mais vai usar.

Ciclo de vida

Os métodos de ciclo de vida têm equivalentes diretos:

• Start() vira _ready(), chamado quando o nó entra na árvore e está pronto.
• Update() vira _process(delta), chamado todo frame.
• FixedUpdate() vira _physics_process(delta), chamado no passo fixo de física.

O delta funciona igual: tempo desde o último frame, para você multiplicar movimento e não depender do framerate. Um exemplo lado a lado, para sentir a distância:

// Unity, C#
public class Player : MonoBehaviour
{
    public float speed = 200f;

    void Update()
    {
        float x = Input.GetAxis("Horizontal");
        transform.Translate(Vector3.right * x * speed * Time.deltaTime);
    }
}

# Godot, GDScript com tipos estáticos
extends CharacterBody2D

@export var speed: float = 200.0

func _process(delta: float) -> void:
    var x: float = Input.get_axis("ui_left", "ui_right")
    position.x += x * speed * delta

Note três coisas: o script extends o tipo do nó, o @export (falo dele já já) e os tipos estáticos no GDScript, que você deve sempre usar. Tipar deixa o código mais rápido e o editor te ajuda mais.

Instanciar em runtime

Na Unity você faz Instantiate(prefab). Na Godot são dois passos: você carrega a cena e depois instancia.

// Unity
public GameObject enemyPrefab;
Instantiate(enemyPrefab, position, Quaternion.identity);

# Godot
const EnemyScene: PackedScene = preload("res://enemy.tscn")

func spawn() -> void:
    var enemy: Node = EnemyScene.instantiate()
    add_child(enemy)

Use preload quando o caminho é fixo e conhecido em tempo de compilação (fica em memória cedo) e load quando você decide o caminho em runtime. Depois de instantiate(), o nó existe mas não está na árvore, então você precisa do add_child() para ele aparecer e rodar. Esse passo do add_child é o que mais gente esquece na primeira semana.

Inspector e variáveis expostas

[SerializeField] e campos public que aparecem no Inspector da Unity viram @export na Godot:

@export var vida_maxima: int = 100
@export var arma: PackedScene
@export var cor: Color = Color.RED

Qualquer variável marcada com @export aparece no Inspector da Godot para você ajustar sem tocar no código, exatamente como você já faz. Vale para números, cenas, cores, referências a outros recursos.

Coroutines

As IEnumerator com yield return new WaitForSeconds(1f) da Unity não existem na Godot. O substituto é mais limpo: await combinado com sinais ou um Timer.

// Unity
IEnumerator Explodir()
{
    yield return new WaitForSeconds(1f);
    Destroy(gameObject);
}

# Godot
func explodir() -> void:
    await get_tree().create_timer(1.0).timeout
    queue_free()

O await pausa a função até o sinal disparar. Sinais, aliás, são o sistema de eventos da Godot e vão virar seu pão com manteiga: você conecta um sinal (parecido com um UnityEvent ou um Action) a uma função e reage a ele.

Física e corpos

O mapeamento de física é próximo:

• Rigidbody / Rigidbody2D viram RigidBody3D / RigidBody2D, para objetos guiados pela simulação física.
• Para personagens controlados por código (o clássico "não quero que a física empurre meu herói"), a Godot tem o CharacterBody2D e o CharacterBody3D, com o método move_and_slide() que resolve colisão e deslize de forma direta.

Variantes de prefab

As prefab variants da Unity têm um equivalente muito natural: a herança de cena. Você salva uma cena base (um inimigo genérico) e cria cenas herdadas que mudam só o que precisa (um inimigo mais rápido, outro com sprite diferente). Alterou a base, as herdadas acompanham.

A questão da linguagem: C# ou GDScript

Essa é a dúvida número um de quem vem da Unity, e a resposta honesta é: depende do que você quer aproveitar.

Você pode continuar em C#. A Godot tem uma versão com suporte a .NET que roda C# de verdade, com seu conhecimento de sintaxe, LINQ, tipos e boa parte do ecossistema. O que muda não é a linguagem, é a API: você deixa de chamar transform, Instantiate e GetComponent e passa a chamar a API da Godot. Ou seja, você mantém a linguagem e reaprende a biblioteca.

A outra opção é GDScript, a linguagem própria da Godot. Para quem já programa, ela é rápida de pegar: sintaxe parecida com Python, integrada à engine, com menos cerimônia para tarefas comuns de jogo. A vantagem é o encaixe perfeito com os nós e sinais e a documentação que assume GDScript por padrão. A desvantagem é performance bruta em cálculos pesados e a falta do ecossistema de bibliotecas do C#.

Minha recomendação prática: se seu jogo tem lógica pesada de CPU ou você depende de bibliotecas .NET, comece em C#. Se você quer a curva mais suave dentro da Godot e a maioria dos tutoriais fazendo sentido de primeira, aprenda GDScript, custa pouco para quem já domina uma linguagem. Detalhei o trade-off completo em C# contra GDScript na Godot.

O que transfere e o que não transfere

Vale ser cru sobre isso, porque é onde a expectativa errada machuca.

Transfere:

• Seu raciocínio de programação. Loops, estados, arquitetura, padrões, tudo continua valendo.
• C# como linguagem, se você escolher o build .NET.
• Matemática e vetores. Produto escalar, interpolação, ângulos, física básica, é o mesmo conhecimento.
• Seus assets de arte e áudio. PNG, JPG, WAV, OGG, modelos em glTF, tudo importa direto na Godot.
• A forma de pensar em prototipagem, game feel, tuning de valores.

Não transfere:

• O código em si. Não existe importação de projeto, você reconstrói a estrutura.
• A API. Todo GetComponent, Instantiate, Coroutine e afins precisa ser reescrito no vocabulário da Godot.
• O sistema de componentes. Você troca por nós e árvore, e forçar o modelo antigo só atrapalha.
• A Asset Store gigante. A AssetLib da Godot existe e cresce, mas o volume de plugins prontos é menor. Se você dependia muito de assets de terceiros, sinta isso antes.

Um plano de migração prático

Não migre seu jogo comercial de cara. O caminho que menos gera frustração é este:

1. Instale as duas versões e escolha a linguagem. Baixe a Godot padrão (GDScript) ou a versão .NET (C#). Decida com base na seção acima e siga em frente sem remoer.
2. Refaça um jogo bobo que você já domina. Um Pong, um Flappy, um coletor de moedas. Como você já sabe as regras, sua cabeça fica livre para aprender os nós e não a mecânica.
3. Force o modelo de nós. No primeiro projeto, resista a recriar componentes. Toda vez que pensar "onde ponho esse componente", pergunte "que nó filho faz isso". É esse reflexo que você está treinando.
4. Aprenda sinais e o @export bem. São os dois recursos que mudam mais a forma de estruturar o código na Godot. Investir neles cedo economiza retrabalho.
5. Só então traga um projeto real. Comece pelo protótipo da sua próxima ideia, não pela migração do seu jogo de anos. A Godot brilha em começar do zero com a cabeça certa.

Uma semana de dedicação real costuma bastar para o desconforto virar fluidez. Se você está pesando se todo esse esforço vale a pena para a sua situação, tem um texto direto sobre quando aprender Godot compensa de verdade.

Fechando

Migrar da Unity para a Godot não é começar do zero, é traduzir. Você já tem o mais difícil, que é saber programar e pensar como quem faz jogo. O que a Godot pede é uma troca de vocabulário: componentes viram nós, prefabs viram cenas, Start vira _ready, Instantiate vira preload mais instantiate. Aceite o modelo de nós em vez de brigar com ele, escolha sua linguagem sem drama e refaça algo pequeno antes de mover o que importa. Feito isso, o resto do caminho é surpreendentemente curto.