Construir um jogo como projeto paralelo enquanto trabalha como desenvolvedor senior durante o dia é um exercício de tomada de decisão deliberada. Cada decisão de ferramenta tem consequências compostas. A engine errada ou a linguagem errada vai custar centenas de horas ao longo da vida de um projeto. Passei cerca de três meses pesquisando e prototipando antes de me comprometer com Godot 4 com C# para meu RPG tático, e quero documentar esse processo de decisão honestamente, incluindo o que me surpreendeu, tanto positiva quanto negativamente. Os números deste post são um retrato tirado em fevereiro de 2026: 123+ scripts, 334+ testes entre as suítes de unidade, integração e performance, e 28 shaders.
A Decisão da Engine: Unity vs Unreal vs Godot
Quando comecei este projeto, avaliei três engines seriamente: Unity, Unreal Engine 5 e Godot 4. Não avaliei GameMaker ou outras engines focadas em 2D porque meu jogo tem uma visão isométrica 3D com uma quantidade significativa de trabalho customizado de shaders, e eu precisava de uma engine com um pipeline 3D forte.
Unity era o primeiro candidato óbvio. Tem o maior ecossistema, mais tutoriais, mais conteúdo na asset store e uma comunidade massiva. Tenho colegas que juram por ela. Mas investiguei Unity com a saga da taxa de runtime ainda fresca: anunciada em setembro de 2023, suavizada em poucas semanas e cancelada em setembro de 2024. Mesmo com a taxa fora do caminho, o incidente revelou algo que não pude ignorar: Unity é uma empresa de capital aberto com obrigações para acionistas que podem entrar em conflito com os interesses dos desenvolvedores. Para um projeto pessoal de longo prazo onde estou investindo tempo significativo, preciso de confiança na estabilidade da plataforma e no alinhamento com meus interesses como desenvolvedor indie.
Unreal Engine 5 é genuinamente impressionante do ponto de vista tecnológico. Nanite, Lumen, o novo sistema de animação. A engenharia é extraordinária. Mas UE5 é projetada para equipes com artistas técnicos em tempo integral, animadores especializados e múltiplos programadores. A sobrecarga de complexidade para um desenvolvedor solo construindo um RPG tático é enorme. A engine é otimizada para jogos de ação AAA em primeira ou terceira pessoa 3D. Usá-la para um jogo tático baseado em turnos com perspectiva isométrica significaria lutar contra as premissas da engine a cada passo.
Godot 4 foi a escolha com que me comprometi, e as razões foram: é totalmente open source sob licença MIT (sem preocupações de licenciamento, sem mudanças de política que possam me afetar retroativamente), é arquiteturalmente adequada ao tipo de jogo que estou construindo, e o lançamento da versão 4.0 trouxe melhorias significativas especificamente para o pipeline 3D e para a integração com C#.
Por Que C# Em Vez de GDScript
A linguagem nativa de scripting do Godot é GDScript, e é excelente para muitos casos de uso. A sintaxe é próxima de Python, profundamente integrada com a engine, e o ferramental melhorou substancialmente no Godot 4. Se eu estivesse construindo um jogo casual 2D como primeiro projeto de jogo, provavelmente usaria GDScript.
Para meu projeto, C# foi a escolha certa por várias razões específicas ao meu background e à complexidade do que estou construindo.
Primeiro: segurança de tipos em escala. Um RPG tático tem muitos sistemas interagindo. Um sistema de combate, um sistema de movimento, um sistema de cálculo de stats, uma árvore de decisão de IA, um sistema de inventário, um sistema de equipamento, um sistema de habilidades, um sistema de progressão de unidades. Quando esses sistemas interagem, erros de tipo são uma fonte importante de bugs. C# com sua tipagem estática forte captura categorias inteiras de bugs em tempo de compilação que GDScript revelaria em runtime, frequentemente em um caso limite obscuro durante a gameplay. Com 123+ scripts no projeto, o dividendo da segurança de tipos é significativo.
Segundo: ferramental. Trabalho no JetBrains Rider, que tem suporte de primeira classe a C#. Refatoração, navegação de símbolos, find usages, documentação inline. Essas ferramentas funcionam em capacidade total para C#. O suporte a GDScript em editores externos está melhorando mas ainda é significativamente inferior. Para um projeto onde posso refatorar uma estrutura de dados central que é referenciada em 40 arquivos, bom ferramental não é luxo.
Terceiro: padrões transferíveis. Meu background é TypeScript e Angular. C# é sintaticamente próximo de TypeScript e compartilha muitos padrões. Generics, LINQ é similar a métodos de array, async/await, interfaces, conceitos de dependência. A curva de aprendizado foi gerenciável porque eu estava aprendendo os padrões do Godot, não um paradigma de programação inteiramente novo e uma nova linguagem simultaneamente.
// Example: A typed unit stat system in C#
public sealed partial class UnitStats : Resource
{
[Export] public int BaseHealth { get; set; } = 100;
[Export] public int BaseAttack { get; set; } = 10;
[Export] public int BaseDefense { get; set; } = 5;
[Export] public int BaseMovementRange { get; set; } = 4;
[Export] public int BaseActionPoints { get; set; } = 2;
public int ComputeEffectiveHealth(IReadOnlyList<StatModifier> modifiers)
{
var total = (float)BaseHealth;
foreach (var modifier in modifiers.Where(m => m.Stat == StatType.Health))
{
total = modifier.Type == ModifierType.Flat
? total + modifier.Value
: total * (1f + modifier.Value / 100f);
}
return Mathf.RoundToInt(total);
}
}O Que Me Surpreendeu Sobre Godot 4
Há coisas sobre Godot que eu esperava e coisas que genuinamente me surpreenderam. Esperava o sistema de cenas. Esperava nodes e signals. Esperava uma engine mais leve que Unity ou Unreal. Aqui está o que não esperava.
A linguagem de shaders é excelente. Escrevi 28 shaders para este projeto, incluindo shaders procedurais de terreno, efeitos de contorno de unidades, overlays de destaque de tiles, implementação de fog of war e vários shaders de efeitos visuais. A linguagem de shaders do Godot é um dialeto GLSL bem documentado e bem comportado. Entrei esperando que desenvolvimento de shaders seria uma parte dolorosa do projeto. Tem sido uma das partes mais prazerosas.
O sistema de Resources é mais poderoso do que parece à primeira vista. Resources no Godot são containers de dados que podem ser serializados, referenciados entre cenas e estendidos com comportamento customizado. Uma vez que entendi como usar Resources tipados como objetos de configuração, essencialmente game design dirigido por dados, desbloqueou um padrão que tornou o jogo dramaticamente mais mantenível. Definições de habilidades, templates de unidades, tipos de terreno, blueprints de equipamento: todos são Resources armazenados como arquivos .tres, editáveis no inspector do Godot sem tocar em código.
A integração com C# é boa, mas tem arestas. O fato de que GDScript e C# coexistem no mesmo projeto significa que há pontos de fricção de interoperabilidade ocasionais. Signals funcionam através da fronteira de linguagem mas requerem sintaxe diferente dependendo de qual lado você está. Algumas features do Godot que são de primeira classe em GDScript são acessadas por APIs um pouco desajeitadas em C#. A aresta que realmente limita a decisão é o suporte a plataformas: o Godot 4 não consegue exportar um projeto C# para a web de jeito nenhum, e a exportação C# para Android e iOS ainda é experimental. Se uma build para navegador faz parte do seu plano, GDScript é a única opção hoje. Eu miro desktop, então aceitei essa troca de olhos abertos, mas é a primeira coisa a verificar antes de se comprometer com o caminho C#.
A Escolha do Gênero RPG Tático
Quero explicar por que escolhi construir um RPG tático especificamente, porque a escolha do gênero tem implicações significativas para a complexidade de engenharia do projeto.
Sou fã do gênero desde que joguei Final Fantasy Tactics quando criança e depois descobri Fire Emblem, Disgaea e Into the Breach. RPGs táticos são um gênero onde a profundidade de design vem da interação de sistemas em vez de volume de conteúdo. Um RPG tático bem projetado pode fornecer centenas de horas de gameplay significativa a partir de um conjunto de conteúdo relativamente pequeno, porque o espaço de combinações de unidades, habilidades, inimigos e terreno gera complexidade emergente.
Do ponto de vista de engenharia, RPGs táticos são jogos pesados em sistemas. Eles requerem: um sistema de movimento baseado em grid com pathfinding e cálculo de alcance de movimento, um sistema de ordem de turnos, um sistema de cálculo de combate com múltiplas variáveis interagindo, um sistema de decisão de IA para unidades inimigas, um sistema de habilidades e abilidades com efeitos diversos e interativos, um sistema de progressão de unidades, e um sistema de inventário e equipamento. Todos esses sistemas precisam interagir uns com os outros corretamente. Esse é exatamente o tipo de problema que acho genuinamente interessante de uma perspectiva de design de software.
Estado Atual do Projeto
Em fevereiro de 2026, o projeto tem 123+ scripts, 334+ testes entre as suítes de unidade, integração e performance, e 28 shaders. Essa contagem de testes é algo que quero comentar explicitamente: escrevo testes para lógica de jogo, e estou convicto de que é a abordagem certa para um projeto de jogo complexo mesmo não sendo a norma da indústria para jogos indie.
Cálculos de combate, resultados de pathfinding, empilhamento de modificadores de stats, cálculos de ordem de turnos. Tudo isso é lógica determinística que pode e deve ser testada. Toda vez que faço uma mudança no sistema de combate, minha suite de testes me diz imediatamente se quebrei algo em outro lugar. Em um jogo onde cada classe de unidade, habilidade e tipo de terreno pode interagir com todas as outras, a complexidade combinatória de testes manuais não é tratável. Testes automatizados não são opcionais nessa escala. São como mantenho confiança no sistema conforme ele cresce.
Dois frameworks cobrem essa suíte, e a linha entre eles é o engine. Lógica pura, as classes que nunca tocam um node, uma cena ou um Resource, roda sob xUnit puro sem nenhum processo do Godot, que é o que o teste abaixo faz. Tudo que encosta no engine roda sob GdUnit4 dentro do Godot.
// Movement range calculation, pure logic suite (xUnit, no Godot runtime)
public class MovementRangeCalculatorTests
{
private readonly MovementRangeCalculator _calculator;
private readonly InMemoryGrid _testGrid;
public MovementRangeCalculatorTests()
{
// InMemoryGrid implements the same IGridQuery interface as the
// GridMap-backed service the battle scene uses at runtime
_testGrid = GridMapFactory.CreateFlat(10, 10);
_calculator = new MovementRangeCalculator(_testGrid);
}
[Fact]
public void GetReachableTiles_BasicMovement_ReturnsCorrectDiamond()
{
var origin = new Vector2I(5, 5);
var movementRange = 3;
var result = _calculator.GetReachableTiles(origin, movementRange);
Assert.Equal(25, result.Count); // Diamond with range 3
Assert.Contains(new Vector2I(5, 8), result); // North
Assert.Contains(new Vector2I(8, 5), result); // East
Assert.DoesNotContain(new Vector2I(5, 9), result); // Out of range
}
[Fact]
public void GetReachableTiles_WithObstacle_ExcludesBlockedTiles()
{
_testGrid.SetCellTerrain(new Vector2I(5, 6), TerrainType.Impassable);
var origin = new Vector2I(5, 5);
var result = _calculator.GetReachableTiles(origin, movementRange: 3);
Assert.DoesNotContain(new Vector2I(5, 7), result); // Behind obstacle
}
}A Avaliação Honesta Após Meses de Desenvolvimento
Godot 4 com C# é uma escolha genuinamente excelente para um desenvolvedor solo construindo um jogo complexo e pesado em sistemas. A natureza open source remove uma categoria real de risco de longo prazo. A engine é capaz, melhorando rapidamente e bem adequada ao tipo de desenvolvimento que estou fazendo. O ferramental C# me dá a infraestrutura de produtividade que preciso para gerenciar um projeto dessa complexidade.
O que subestimei: o tempo necessário para construir ferramental robusto para o jogo. O jogo em si requer plugins customizados de editor para coisas como edição de mapas, colocação de unidades e configuração de encontros. Construir essas ferramentas como scripts de editor em C# leva tempo real e não é algo que qualquer tutorial te prepara adequadamente. Ferramental é pelo menos 20% do esforço total do projeto, e estava mais perto de 10% nas minhas estimativas iniciais.
Escolher uma engine é escolher um conjunto de restrições. A pergunta não é qual engine é melhor. É quais restrições você consegue conviver e quais se alinham com o que você está tentando construir.
Se você é um desenvolvedor vindo de um background de web ou software enterprise considerando desenvolvimento de jogos, Godot 4 com C# é um ponto de entrada acessível e poderoso para jogos de desktop. Os padrões são diferentes do desenvolvimento web mas não alienígenas, especialmente se você já está confortável com TypeScript e arquiteturas baseadas em componentes. O investimento de aprendizado é real, mas é tratável, e o retorno criativo de construir um jogo do zero é diferente de qualquer coisa que experimentei no desenvolvimento profissional de software.
Referências
- Godot MIT license. https://godotengine.org/license/
- Godot C# documentation. https://docs.godotengine.org/en/stable/tutorials/scripting/c_sharp/index.html
- Godot 4.5 release notes. https://godotengine.org/releases/4.5/
- Exporting for the web. C# projects cannot be exported to the web in Godot 4. https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_web.html