LDtk: editor de níveis 2D moderno e gratuito

Montar o nível de um jogo 2D clicando tile por tile é um trabalho que você vai refazer dezenas de vezes antes de a fase ficar boa, e cada passo de iteração que você economiza conta. É aí que entra o LDtk, um editor de níveis 2D gratuito feito pelo mesmo autor do jogo Dead Cells. Ele não roda jogo nenhum: o trabalho dele é desenhar mundo, organizar camadas e cuspir um arquivo que o seu motor lê. A diferença para outros editores está em quanto ele automatiza o trabalho repetitivo, e é por isso que ele virou a alternativa moderna que muita gente compara de cara com o Tiled.

Este guia mostra o que é o LDtk, os conceitos que você precisa entender para usá-lo bem (layers, entities, IntGrid e as auto-layer rules), o fluxo de trabalho básico, e como importar o resultado no Godot 4 com um addon, incluindo um bloco de GDScript tipado acessando os dados de uma entity. No fim, uma comparação direta com o Tiled para você escolher com critério.

O que é o LDtk e por que ele é um editor de níveis 2D diferente

LDtk é a sigla de Level Designer toolkit. É um programa de desktop, gratuito e open source, que roda em Windows, Linux e macOS. Você desenha os níveis dentro dele e salva um arquivo .ldtk, que por baixo é um JSON documentado. Esse arquivo guarda tudo: os tiles pintados, as regras de colisão, a posição dos inimigos, baús, pontos de spawn e qualquer outro dado que você queira anexar a um nível.

A filosofia é a mesma de qualquer editor dedicado: o level design mora fora do motor, como dado, e o seu código cuida da lógica. Isso deixa você versionar os níveis separados, dar o editor para alguém que não mexe no projeto do motor, e trocar de motor sem redesenhar tudo. O que coloca o LDtk num degrau à parte é que ele já vem com ferramentas de automação de desenho embutidas, sem depender de plugin, e trata inimigos e objetos como entidades com campos tipados de verdade, não como retângulos soltos com texto dentro.

Se você ainda não tem a arte dos seus tiles, essa é a etapa anterior. O LDtk parte do princípio de que o PNG do tileset já existe, então vale fechar o desenho primeiro: o guia completo de pixel art para jogos cobre como montar uma spritesheet limpa e exportável antes de você abrir o editor de níveis.

Os conceitos centrais: layers, entities e IntGrid

Dentro de um projeto LDtk, tudo é organizado por layers (camadas), e o LDtk tem quatro tipos, cada um com um papel claro:

• Tiles layer: a camada onde você pinta tiles à mão, célula por célula, igual a qualquer editor de mapas. Serve para decoração e detalhes que você quer controlar manualmente.
• IntGrid layer: uma grade onde cada célula guarda um número inteiro em vez de um tile. É o coração do LDtk. Você pinta valores (por exemplo, 1 = chão, 2 = parede, 3 = água) e usa esses números para definir colisão e para alimentar o auto-tiling.
• Auto-layer: uma camada que desenha tiles sozinha, seguindo regras que olham para a IntGrid. Você pinta só os números e o LDtk escolhe o tile certo.
• Entities layer: onde moram os objetos do jogo, como player start, inimigos, itens e gatilhos. Cada entity é uma instância com campos.

A IntGrid é o que mais confunde quem vem de outros editores, mas a ideia é simples. Em vez de desenhar a parede com o tile bonito já pintado, você desenha a estrutura do nível com números. A célula de chão recebe o valor 1, a parede recebe o 2, e por aí vai. Esses números não aparecem no jogo: eles são a planta baixa do nível. A partir deles, duas coisas acontecem quase de graça: a colisão sai direto da IntGrid (todo valor 2 vira parede sólida) e o visual é preenchido pelas auto-layer rules.

As entities são onde o LDtk brilha para quem programa. Uma entity não é um retângulo com uma string de texto: ela tem campos declarados com tipo. Você define no editor que a entity Inimigo tem um campo vida do tipo inteiro, um campo velocidade do tipo float e um campo patrulha que é uma lista de pontos. Ao colocar o inimigo no nível, você preenche esses valores por instância. No motor, esses dados chegam já estruturados, prontos para virar propriedades do seu nó.

Auto-layer rules: o que mais diferencia o LDtk

As auto-layer rules são o recurso que faz gente migrar para o LDtk. A ideia: você define regras que dizem "quando um grupo de células da IntGrid tiver este padrão, desenhe este tile". O LDtk aplica essas regras em tempo real, enquanto você pinta.

Na prática, você configura uma vez que, por exemplo, uma célula de chão com vazio em cima deve usar o tile de borda superior do terreno, que um canto interno usa o tile de canto, e assim por diante. Depois disso, você nunca mais pinta a borda de um platô à mão. Pinta o bloco de números na IntGrid e o terreno se desenha inteiro, com cantos, bordas e transições no lugar. Mudou o formato da plataforma? Repinta os números e o visual se refaz sozinho. É o mesmo princípio de um terrain autotile, só que configurado por regras visuais dentro do editor e reaproveitável entre todos os níveis do projeto.

Esse é o ganho de iteração de verdade. Em um editor sem auto-tiling, redesenhar o contorno de uma fase depois de uma mudança de layout é um trabalho manual demorado. No LDtk, é repintar a planta baixa.

Fluxo de trabalho básico no LDtk

O caminho para montar um nível do zero segue uma ordem que vale respeitar:

1. Crie o projeto e defina o grid. Ao abrir, você escolhe o tamanho da célula (grid size). Esse valor precisa bater com a grade da sua arte: tiles de 16x16 pedem grid de 16.
2. Carregue o tileset. Em Tilesets, aponte para o PNG e confirme o tamanho do tile. Confira margin e spacing se a sua folha tiver respiro entre os quadros, senão o LDtk fatia no lugar errado.
3. Monte as layers. Crie uma IntGrid layer para a estrutura, associe um tileset a ela e defina os valores (chão, parede, etc.).
4. Configure as auto-layer rules naquela IntGrid, ligando cada padrão de células ao tile correspondente. Esse é o investimento inicial que paga em todos os níveis seguintes.
5. Defina as entities. Crie os tipos (PlayerStart, Inimigo, Item), declare os campos de cada um com tipo, e desenhe os ícones.
6. Pinte o nível. Com tudo configurado, montar a fase é pintar números na IntGrid, ver o terreno aparecer, e espalhar entities por cima.
7. Salve. O .ldtk já guarda tudo. Se você marcar a opção de salvar níveis em arquivos separados, cada nível vira um .ldtkl próprio, o que ajuda no versionamento.

Um projeto LDtk pode ter vários níveis dentro do mesmo arquivo, posicionados num mundo (world) com layout livre, grade ou linear. Isso é prático para jogos com fases conectadas ou mapas estilo metroidvania, onde a posição de cada sala importa.

Importando o nível no Godot 4

A Godot 4 não lê .ldtk de fábrica. O caminho é instalar um addon da asset library, sendo o LDtk Importer o mais usado. Pela Godot, abra AssetLib, procure por LDtk, baixe e instale. Depois, em Project > Project Settings > Plugins, ative o plugin. A partir daí, a Godot passa a reconhecer o arquivo .ldtk como um recurso importável.

Com o plugin ativo, copie o seu .ldtk (e o tileset PNG) para dentro da pasta do projeto. A Godot importa o arquivo e gera uma cena com a estrutura montada: um TileMapLayer para cada layer de tiles e auto-layer, a colisão derivada da IntGrid, e um nó para cada entity que você posicionou, com os campos preenchidos acessíveis por código ou como metadata.

A partir daí, você trata aquilo como qualquer cena da Godot. Instancie o nível, percorra os nós das entities e use os dados para spawnar os objetos reais do jogo. Se o seu projeto é isométrico em vez de top-down ou plataforma, vale também conferir como a Godot lida com esse caso no guia de jogo isométrico com TileMap na Godot, porque a projeção muda o jeito de montar as camadas.

Aqui está um exemplo de GDScript tipado lendo os dados de uma entity importada. O formato exato dos nós depende da versão do addon, mas a ideia de ler campos por nome e instanciar algo a partir deles é a mesma:

extends Node2D

@export var cena_inimigo: PackedScene

func _ready() -> void:
    var camada_entities: Node = $Entities
    for entity in camada_entities.get_children():
        if entity.get_meta("identifier", "") == "Inimigo":
            _spawnar_inimigo(entity)

func _spawnar_inimigo(entity: Node) -> void:
    var vida: int = entity.get_meta("vida", 100)
    var velocidade: float = entity.get_meta("velocidade", 50.0)
    var inimigo: Node2D = cena_inimigo.instantiate()
    inimigo.position = entity.position
    inimigo.set("vida", vida)
    inimigo.set("velocidade", velocidade)
    add_child(inimigo)

O ponto importante: os campos vida e velocidade que você declarou como inteiro e float no LDtk chegam aqui com o tipo certo, e você os lê por nome. Essa é a vantagem concreta das entities tipadas sobre guardar tudo como texto solto.

LDtk ou Tiled: a comparação direta

Os dois editores resolvem o mesmo problema central, são gratuitos e open source, e salvam num formato aberto. A escolha é de ênfase.

O Tiled existe desde 2008. Ele é o padrão de fato, tem mais anos de suporte embutido em motores e frameworks, e um ecossistema de plugins e exportadores maior. Se você precisa de máxima compatibilidade, ou já tem um fluxo que lê .tmx/.tmj, o Tiled é a aposta segura. O guia de como criar mapas 2D com o Tiled cobre esse caminho em detalhe.

O LDtk é mais recente e aposta na iteração. As auto-layer rules e a IntGrid vêm de fábrica e tornam o redesenho de níveis muito mais rápido, e as entities com campos tipados reduzem o trabalho de cola entre o editor e o código. A contrapartida é um ecossistema menor e menos anos de rodagem em produção.

Na prática: projeto novo em Godot 4, equipe pequena, muita iteração de level design? O LDtk tende a dar menos atrito. Precisa de compatibilidade ampla entre motores ou de um recurso específico que só o Tiled tem? Fique no Tiled. Nenhum dos dois é errado, e os dois são de graça, então vale abrir os dois e sentir qual encaixa no seu ritmo.

Essa decisão de ferramenta é pequena perto da escolha de motor, que define quase tudo no resto do projeto. Se você ainda está nesse passo, a comparação de Godot vs Unity ajuda a fechar essa decisão antes de investir tempo montando níveis.

No fim, o LDtk não é mágica: é um editor que automatiza o trabalho repetitivo de desenhar terreno e organiza os dados do nível de um jeito que o código agradece. Para um jogo 2D feito em Godot 4, isso costuma significar menos horas pintando bordas e mais horas ajustando o que de fato faz a fase ser divertida.