- É totalmente possível desenvolver jogos de forma fácil e divertida mesmo sem um engine de jogo comercial
- A maior parte dos recursos dos grandes engines não é necessária e, ao criar suas próprias ferramentas, você ganha mais flexibilidade e eficiência no desenvolvimento
- Com C# moderno e bibliotecas open source, é possível ter um ambiente de desenvolvimento plenamente adequado independentemente do tamanho da equipe
- Combinando bibliotecas como FMOD, SDL3 e Dear ImGui com ferramentas próprias, dá para montar um pipeline sob medida para as suas necessidades
- Em termos de desenvolvimento multiplataforma, manutenção e portabilidade, um framework leve construído por você mesmo traz muitas vantagens
Prefácio: reflexões de um desenvolvedor de jogos com 20 anos de carreira
- Mesmo em 2025, continuo desenvolvendo videogames sem um engine de jogo comercial
- Muitas pessoas ao meu redor se surpreendem com o fato de eu não usar um engine comercial
- Os recursos básicos de grandes engines como Unity ou Unreal são menos satisfatórios do que implementá-los diretamente e, no fim, muitas partes acabam precisando ser refeitas
- Ao usar engines comerciais, você fica exposto a problemas causados por mudanças frequentes de política comercial ou atualizações
- Criar diretamente pequenas ferramentas sob medida para cada projeto é mais eficiente e, no longo prazo, também facilita a manutenção
Escolha da linguagem de programação necessária para desenvolvimento de jogos
- Há muito tempo uso C# como linguagem principal
- O C# moderno melhorou bastante em desempenho, sintaxe e experiência de desenvolvimento em comparação com o passado
- Há recursos de hot reload como dotnet watch, que são extremamente convenientes para modificar e testar código em tempo real
- Até pessoas não desenvolvedoras conseguem se aproximar com facilidade, o que aumenta a divisão de funções e a eficiência da colaboração entre membros da equipe
- O recurso embutido de reflection é uma grande vantagem na criação de editores e ferramentas
Bibliotecas multiplataforma e implementação de renderização e entrada
- Uso o SDL3 para implementar todas as funções básicas, como janelas, renderização, controles e suporte multiplataforma
- A abstração de GPU do SDL3 facilita o suporte a ambientes diversos como DirectX, Vulkan e Metal
- Aproveito uma camada em C# escrita por cima do SDL (por exemplo, Foster) como utilitário compartilhado
- Uso o FMOD como a última ferramenta comercial de áudio remanescente; fora isso, monto um pipeline baseado em open source
- No passado, também tive experiência implementando OpenGL/DirectX diretamente, mas a estabilidade do SDL é uma vantagem considerável
Como lidar com assets
- Ao usar um engine próprio, basta carregar de forma simples apenas os arquivos necessários para o jogo
- Em jogos de pixel art e outros com assets de pequena escala, todos os arquivos são carregados de uma vez na inicialização
- Em projetos maiores, apenas os assets necessários são carregados sob demanda, e a memória é liberada nas transições de cena
- Quando é necessário converter arquivos, basta escrever scripts de processamento automático na compilação
Editor de fase e ferramentas de UI
- É fácil integrar dados com editores de fase open source como LDtk, Tiled e Trenchbroom
- Na maioria dos casos, implemento diretamente um editor personalizado para cada projeto
- Em vez de escrever toda a UI do zero, faço amplo uso da GUI em modo imediato do Dear ImGui
- A combinação de reflection em C# com ImGui permite visualizar em tempo real o estado dos objetos do jogo
- Quando necessário, misturo ferramentas externas adequadas ao objetivo com ferramentas próprias
Multiplataforma e portabilidade para consoles
- No passado, a necessidade de portar para consoles tornava a escolha de C++ mais importante, mas isso foi resolvido com a chegada do C# Native-AOT
- Frameworks open source como o FNA também estão ampliando ativamente o suporte a consoles
- Aproveitando a camada de abstração genérica oferecida pelo SDL3, é possível operar praticamente o mesmo codebase na maioria dos sistemas
Ambiente de desenvolvimento: ecossistema aberto com foco em Linux
- Migrei minha principal plataforma de desenvolvimento para Linux, que combina muito bem com toolchains open source
- Ainda existe certa dependência de softwares comerciais específicos (por exemplo, vscode e github), mas, à medida que o ecossistema open source se amplia, o suporte também cresce
- Pessoalmente, venho montando o mesmo ambiente de trabalho em várias plataformas baseadas em Linux, como o Steam Deck
Q&A adicional e casos práticos
- Pergunta sobre usar Godot: se houver necessidade de desenvolvimento centrado em um engine open source, recomendo Godot; fora isso, prefiro ferramentas customizadas
- Trabalho em 3D: grandes engines têm vantagens, mas para projetos pequenos e especializados, um framework sob medida já é suficiente
- Exigências de tecnologias de alto desempenho: dependendo do nível de exigência, usar grandes engines como Unreal também é perfeitamente válido
- Mudança de engine em equipes: é adequado para desenvolvimento solo ou em pequena escala, e até estúdios de médio e grande porte vêm aumentando os casos de migração para engines customizados para evitar riscos de longo prazo
- Workflow de assets: arquivos do Aseprite podem ser convertidos automaticamente em animações usando tags e timing embutidos
Conclusão
- Fazer jogos sem um engine de jogo comercial é uma escolha que depende do gosto e da forma de trabalhar
- Basta escolher o método mais adequado para você, colocando suas necessidades e diversão em primeiro lugar
5 comentários
Ótima iniciativa.
Eu fui um desenvolvedor de jogos da primeira geração.
Antes do surgimento da Unreal, naturalmente os estúdios
desenvolviam seus próprios motores,
e isso era justamente a sua competitividade.
No desenvolvimento de motores, a maior parte do trabalho era criar ferramentas
com base em core, kernel, renderização e outras entradas e saídas.
Na época, eu era responsável pelas ferramentas de partículas, som, camadas e objetos,
e, reunindo uma equipe de 7 pessoas, acho que passávamos tranquilamente de cerca de 20 ferramentas.
A partir de certo momento, com o surgimento da Unreal e a enxurrada de jogos produzidos em escala,
pararam de investir no desenvolvimento de motores.
Acho que foi nessa época que muita gente se tornou independente e abriu suas próprias empresas.
Já faz 27 anos essa história.
Eu também acabei envelhecendo e hoje trabalho em outra área que não é jogos.
Isso me faz lembrar com nostalgia da época em que fazíamos trabalho de core
de acordo com a placa de vídeo, em modos de DirectX e OpenGL.
Força...
Como recentemente venho procurando há muito tempo uma engine para fazer um jogo de estratégia, cheguei a pensar que seria melhor criar uma eu mesmo; ver um caso de alguém que colocou isso em prática e teve sucesso me enche de coragem.
Comentários do Hacker News
Depois de passar 5 anos desenvolvendo sozinho um engine 2D e trabalhando em projetos pagos relacionados, quero explicar um ponto importante que muita gente não conhece
o engine é a parte fácil
o que realmente importa é o tooling ao redor do engine, o conteúdo e o pipeline de assets
importar texturas, áudio e arquivos de modelo (
gltf,fbx, animações etc.) a partir de várias fontes e formatos de dadosfunções básicas de edição no app do editor, como recortar, copiar, colar, desfazer, refazer, salvar e deletar
visualização e funcionalidades que permitam ao desenvolvedor criar e manipular dados reais no editor (entidades, animações, cenas, grafo de áudio, suporte a scripting etc.)
empacotamento e pré-processamento de dados, como baking de geometria estática, compilação de shaders, reamostragem e empacotamento de textura/áudio, criação de asset packs de conteúdo do jogo
quando tudo isso termina, a parte de runtime de fato (ou seja, o main loop do jogo e seus subsistemas) é só uma pequena parte do sistema inteiro
por isso, em estúdios de games, há poucos responsáveis pelo engine e a maioria dos programadores trabalha criando ferramentas
engine detonator: https://github.com/ensisoft/detonator
É importante focar em criar um engine adequado ao seu jogo, em vez de buscar algo genérico
UI, compressão etc. podem ser resolvidos com bibliotecas e frameworks
o fato de o OP usar bibliotecas pequenas como
imGUItambém é um bom exemplocomo você não está tentando fazer um engine para todo tipo de jogo, acaba havendo muita coisa que na prática nem precisa ser feita
O engine é como um pequeno runtime anexado a um pipeline de assets
hoje em dia, até os compiladores de shader estão ficando mais importantes do que as APIs 3D
a parte interessante está se concentrando no compilador de shader, enquanto a API 3D fica só com o papel de executar shaders e passar dados
Quando as pessoas falam em engine, muitas vezes estão incluindo também o pipeline de assets e o editor
um engine hoje em dia não é só main loop + funções de API 3D
mesmo usando um engine como Unity, são pouquíssimos os desenvolvedores que escrevem só código de renderização
claro que usar Unity/Unreal não significa que você nunca mais vai precisar usar ferramentas de asset por conta própria
Concordo muito com isso, especialmente depois de reescrever o engine de uma sequência recente
como escrevi no post-mortem, quando se fala em engine a maioria pensa no código incluído no executável do jogo, mas na prática acho que o grosso está no código que não é distribuído junto com o jogo, como editor de fases, pipeline de conteúdo, debugging/profiling e fluxo de trabalho de desenvolvimento
desenvolver ferramentas é mais tedioso e desgastante do que desenvolver o engine
é por isso que tantos projetos de jogos com engine customizado acabam parando no meio
post-mortem: https://ruoyusun.com/2025/04/18/game-sequel-lessons.html
Fazer um editor do zero é um trabalho considerável
se possível, eu aproveito editores já existentes
por exemplo, a combinação TrenchBroom (editor de Quake) +
func_godot, ou Tiled no caso de 2Dpara gerenciar dados do jogo também havia o CastleDB, mas agora ele está integrado ao Hide (um editor 3D completo)
depois de criar as ferramentas, projetar o jogo e produzir conteúdo vira outra etapa principal
Há alguns anos, com SDL2 e um pouco de C++, fiz uma classe simples de "sprite" e acrescentei funções básicas como colisão
se eu fosse chamar o que fiz de engine, seria mais como uma assistência de bicicleta elétrica
o ponto é que o "engine" muitas vezes acaba guiando o projeto/o jogo como um todo
com frequência você acaba adaptando o jogo ao engine, por isso sempre evito usar engines grandes como Unity
no fim, esses engines tendem a produzir sempre a mesma estrutura de jogo, mudando só os assets
pessoalmente, em vez de desperdiçar tempo aprendendo um engine, prefiro começar com a curva de aprendizado curta do SDL, que ainda pode ser usado em outros projetos cross-platform além de jogos
meu jogo: https://store.steampowered.com/app/2318420/Glypha_Vintage/
Dizem que fazer o próprio engine leva muito tempo, mas quanto tempo seria necessário para realmente aprender Unreal ou Unity a ponto de conseguir transformar uma ideia em jogo imediatamente?
no fim, quando eu terminar de fazer meu engine, já terei esse nível de especialização de qualquer forma, então no longo prazo isso economiza tempo
quanto mais experiência você tem como engenheiro, mais vantajoso fica fazer por conta própria do ponto de vista de tempo
quanto mais único ou de nicho for o jogo, mais sentido faz fazer por conta própria
é ineficiente passar meses perdido na UI complexa do Unreal e então descobrir que o que você queria desde o começo é quase impossível em um engine genérico
por outro lado, se for um RPG surrealista de mundo aberto, fazer tudo por conta própria não é uma boa escolha
as limitações de um engine customizado podem até estimular a criatividade e gerar jogos mais originais, mesmo sem ser algo de altíssimo nível
Eu já fiz meu próprio engine
no começo, levei cerca de um ano enfrentando inúmeros erros e becos sem saída
implementei quase todos os subsistemas que você vê em um jogo: renderização 3D, UI adaptativa, animação esquelética, save files, smart objects, pathfinding, scripting, áudio, física etc.
principalmente, implementei por conta própria um recurso de rewind (como o sistema de Braid)
funcionalidades assim exigem suporte de todos os subsistemas do engine (scripts, física etc.)
como conheço todas as partes do engine que criei, tenho uma liberdade enorme para desenvolver recursos adicionais
mas depois de um ano de desenvolvimento fui entrando em burnout e perdi a motivação
Não conheço Unreal, mas com Unity dá para desenvolver mais de 10 vezes mais rápido do que codando tudo diretamente
é possível adicionar física em 1 minuto, mas num engine próprio só integrar uma biblioteca externa já pode levar um ou dois dias
as ferramentas internas de visualização que o usuário Noel mostra no Unreal também já vêm embutidas no Unity
edições como manipular bounding boxes também já existem por padrão
se o comportamento básico do engine não for suficiente, também dá para expandir facilmente com ImGui ou um engine CSS baseado em Yoga
há inúmeros recursos disponíveis, como editor avançado de partículas, shaders com complexidade abstraída, streaming de dados modular
em teoria eu também gostaria de fazer tudo por conta própria, mas no fim a prioridade é terminar dentro do tempo
O tempo para aprender Unreal ou Unity e conseguir implementar uma ideia de jogo imediatamente é uma pergunta diferente do tempo para criar seu próprio engine
se você me der só uma pequena ideia, consigo fazer um protótipo jogável em poucas horas
no Unity, no começo basta programar; no Unreal, só com Blueprints já dá para ir quase até a reta final de um jogo
veja este vídeo de um protótipo estilo Super Hexagon feito em 10 minutos: https://www.youtube.com/watch?app=desktop&v=p8MzsDBI5EI
o único elemento realmente próprio do Unity talvez seja o prefab; o resto são conceitos gerais de desenvolvimento de jogos
do ponto de vista de alguém que desenvolve em Unreal, eu conseguiria fazer um protótipo parecido em Unity em menos de 1 hora
A própria suposição de "depois que o engine estiver pronto" pode ser irrealista
até uma ação simples como
GameObject.Instantiateexige recursos absurdos para ser implementada diretamente num engineconsidere a complexidade de física 2D/3D, shaders, suporte a plataformas etc.
se o objetivo é o engine, faça o engine; se o objetivo é o jogo, faça o jogo em si
Se você já tem conhecimento suficiente de desenvolvimento de jogos para conseguir fazer um engine
um dia basta para aprender Unreal ou Unity a ponto de montar um protótipo
dominar perfeitamente leva muito mais tempo, mas o tempo para concluir o protótipo do jogo que você quer não é comparável
Fazer jogos sem um engine grande que "faz tudo" é mais fácil, mais divertido e às vezes mais eficiente
mas, ao se aprofundar em recursos específicos do engine (por exemplo, cinemática inversa e animation blending do Unreal), você acaba pensando "ainda bem que não sofri duas ou três semanas fazendo isso por conta própria"
minimalismo e evitar inchaço também importam, mas esses engines são populares porque assumem o trabalho pesado
Antigamente eu também trabalhava assim
quando fui fazer meu primeiro jogo 3D, implementei entrada, gerenciamento de objetos, culling, carregamento de modelos, biblioteca matemática, gráficos, normal map, SSAA e tudo mais, e no fim o progresso real do jogo ficou em 0%
mesmo assim, em projetos 2D de hobby continuo desenvolvendo sem dependências, usando só o canvas do navegador
na prática, o navegador faz o papel do engine
Sobre a opinião de que "ainda bem que não fiz por conta própria"
se você pensa na carreira de longo prazo como desenvolvedor indie, então mesmo que leve algumas semanas, entender o assunto em profundidade + possuir 100% do código-fonte e seu valor de reutilização é maior
Minha monografia de graduação foi sobre portar para Windows 95/Visual C++ um engine de partículas baseado em NeXTSTEP/Objective-C (com OpenGL e amostra de marching cubes)
hoje em dia, um tema desses é só parte de um recurso de uma linha em engines modernos
Usar um engine faz o projeto avançar muito mais rápido e evita gastar tempo desenvolvendo infraestrutura
para a maioria das pessoas, reinventar a roda não é particularmente divertido
Funcionalidades como cinemática inversa ou animation blending
se forem o núcleo do jogo, vale a pena implementá-las; caso contrário, são uma armadilha técnica desnecessária
Faço meus jogos do meu jeito usando Lua & Love2D
a própria ideia de me impor restrições é parte central da diversão
se desenvolver deixa de ser divertido, isso é sinal de que algo está errado, então vale buscar uma forma melhor
meu jogo YOYOZO tem só 39KB, mas entrou na lista dos melhores jogos de 2023 da Ars Technica ao lado de produções grandes
https://news.ycombinator.com/item?id=38372936
depois de anos desde que comprei um Playdate, comecei a brincar com o SDK, e também estou aprendendo Lua pela primeira vez
tenho vontade de tipos fortes e mais segurança de linguagem, mas ele é suficiente para o contexto
até agora só fiz uma pequena demo técnica em que o texto gira em um espaço 3D falso conforme a manivela
https://bsky.app/profile/haydenblai.se/post/3lpgnya4cqk2a
trabalhando nesse projeto percebi que já tinha esquecido quase toda a trigonometria por causa de uma longa carreira anterior com CRUD/webapps
a melhor coisa no desenvolvimento para Playdate é a libertação de ter um canvas fixo: basta definir a posição dos pixels e tudo funciona igual em qualquer aparelho
na minha carreira anterior de desenvolvimento eu só fazia UI responsiva, então essa experiência é bem nova para mim
Sempre que tento criar algo com um engine de jogo (Godot, Unity, Unreal etc.), acabo lutando contra o engine
no fim, parece que estou só colocando assets em cima de um formato de jogo já definido, o que dificulta fazer o jogo que eu realmente quero
numa analogia com desenvolvimento web, parece um produto pronto como WordPress
quando a configuração padrão diverge da intenção, é preciso fazer uma quantidade enorme de hacks e contornos
Os "templates de jogo" ainda colocam mais lenha na fogueira
você pode comprar templates que fazem um jogo parecer pronto só trocando a tela de título e os modelos
quase metade dos lançamentos novos na Steam parece ser só template de Unity/Unreal com a skin levemente trocada
alguns exemplos:
https://assetstore.unity.com/packages/templates/…
https://store.steampowered.com/app/2488370/Cash_Cleaner_Simulator/
https://store.steampowered.com/app/2073910/A_Webbing_Journey/
https://store.steampowered.com/app/3498270/Better_Mart/
https://store.steampowered.com/app/2625420/Drive_Beyond_Horizons/
https://store.steampowered.com/app/3163790/Toy_Shop_Simulator/
https://store.steampowered.com/app/3023600/Horse_Farm_Simulator/
https://store.steampowered.com/app/3124550/Liquor_Store_Simulator/
No Google Play, todos os jogos parecem iguais, e aparecem problemas típicos do Unity, como carregamento longo, problemas de renderização, texto quebrado e bugs de áudio
para jogos "idle RPG" feitos para publicidade mobile isso talvez seja tolerável, mas no campo de VR eu realmente tinha dificuldade de entender por que usavam Unity
para cumprir os requisitos de desempenho da Meta Quest Store, é preciso desmontar e mexer em muitas partes do engine Unity
é difícil atingir o desempenho necessário, e a forma de trabalhar dele também é antiquada
se você quer criar software de alta qualidade, não dá para começar com um engine em que você não pode confiar
O autor (Noel) fez o jogo Celeste, que vendeu mais de 3 milhões de cópias
https://en.wikipedia.org/wiki/Celeste_(video_game)
Eu também concordo em boa parte e estou criando um framework de jogos em C# baseado em código (um sucessor espiritual de XNA/Monogame, usando Sokol em vez de SDL)
https://zinc.graphics/
pontos fortes do C# moderno: cross-platform, compilação NativeAOT, hot reload nativo, reflection etc.
pessoalmente também acrescentei source generators
embora a imagem negativa do passado ainda permaneça, a evolução do CoreCLR e da linguagem nos últimos 5 anos foi impressionante
a única coisa que eu realmente queria eram Union Types, mas já existe uma proposta e espero que entrem no ano que vem
https://github.com/dotnet/csharplang/blob/main/proposals/TypeUnions.md
usei C# só em Win32 ou Unity e, embora eu tenha conhecimento de engine de baixo nível no lado C/C++, achava que C# era inviável para coisas cross-platform como consoles de jogos
agora percebo que eu estava enganado
Para qualquer software, prefiro começar do zero
para quem tem experiência em projetos grandes isso pode parecer lento, mas na fase de startup muitas vezes é até mais rápido
implemente só o mínimo e, quando as abstrações entram, adicionar novos recursos fica ainda mais rápido
a produtividade de um grande software corporativo e a do meu mini-engine escrito por mim são completamente diferentes
com código escrito por mim, cortar e refatorar é muito mais fácil, então tudo anda bem mais rápido
por isso prefiro microsserviços e equipes pequenas
quando você faz por conta própria, inevitavelmente precisa passar por tentativas e erros e por um campo minado de coisas quebrando, e também leva anos para aprender as características reais da linguagem ou da plataforma
mas todo esse processo acaba virando bagagem real de desenvolvimento
Em vez de um engine, fico curioso sobre como seria usar algo no nível de um framework como o MonoGame~
"Esse processo em si acaba ficando como bagagem do próprio desenvolvedor" Concordo totalmente.