- Desenvolvo todos os jogos dos meus projetos pessoais em “C puro”, uma escolha incomum hoje em dia
- Os principais critérios na escolha da linguagem são confiabilidade, portabilidade e sustentabilidade de longo prazo, sem dependência de um SO ou plataforma específicos
- Dou grande importância à simplicidade e à velocidade de compilação, além de verificação estrita de tipos e um sistema robusto de avisos
- Avaliei linguagens alternativas como C++·C#·Java·Go·Haxe, mas concluí que não eram adequadas por causa de complexidade, GC, imposição de OOP etc.
- C é perigosa, mas simples e rápida e, graças ao amplo suporte a plataformas e a um ecossistema sólido de bibliotecas, continua sendo a melhor escolha
Critérios para escolher a linguagem
- O requisito essencial é confiabilidade e estabilidade, para não perder tempo com bugs que eu não causei
- No passado, desenvolvi jogos baseados em Flash, mas com o declínio do Flash passei a querer focar na criação de novos jogos em vez de portar para uma nova plataforma
- Valorizo portabilidade e suporte de bibliotecas de uso geral para não ficar preso a um SO específico e para manter aberta a possibilidade de desenvolvimento para consoles
- Entre os requisitos desejáveis estão sintaxe simples e uma estrutura fácil de memorizar
- Quero evitar ter de consultar o tempo todo APIs complexas ou recursos da linguagem
- Quero reduzir bugs com verificação estrita de tipos, avisos fortes e análise estática, e encontrar problemas facilmente com bons depuradores e ferramentas de análise dinâmica
- Considero a velocidade de compilação muito importante
- Tempos longos de espera quebram a concentração e reduzem a produtividade
- Sou cético em relação à orientação a objetos (OOP) e prefiro separar dados e código para tratá-los conforme a situação
Avaliação das principais linguagens alternativas
- C++
- Ainda é o padrão no desenvolvimento de jogos, mas me desagrada por causa da complexidade e da compilação lenta
- Oferece alto desempenho e muitos recursos, mas há funcionalidades demais que não quero, e o custo em complexidade é alto
- C# e Java
- São verbosas e complexas e, por causa de uma estrutura fortemente centrada em OOP, oferecem pouca liberdade
- Como linguagens de alto nível, escondem a complexidade, mas não impedem os problemas fundamentais
- Go
- Vejo como uma releitura moderna de C, mas o coletor de lixo stop-the-world é inadequado para desenvolvimento de jogos
- Também há preocupações com a falta de bibliotecas para jogos e com a sustentabilidade no longo prazo
- JavaScript
- O ritmo acelerado de mudanças no ambiente web e o fim do Flash fazem esse ecossistema parecer instável
- Julgo que sua sintaxe permissiva o torna inadequado para escrever software de grande escala
- Haxe
- Considero promissora para desenvolvimento web, mas há preocupação com sua continuidade por ser uma linguagem relativamente nova
- Desenvolver uma linguagem própria
- É uma ideia atraente, mas considerei irrealista por causa do abandono das bibliotecas existentes e do peso de manter compatibilidade
Por que escolher C
- É uma linguagem perigosa, mas confiável e, graças à sua estrutura simples, pode ser estável se usada com cuidado
- Ele a compara a uma “faca afiada”, destacando que é difícil de manusear, mas uma ferramenta poderosa quando dominada
- A velocidade de compilação é muito alta e ela pode rodar em praticamente qualquer plataforma
- O processo de portar também é relativamente simples, e sua sustentabilidade no longo prazo é alta
- O suporte de bibliotecas e ferramentas é forte e continua sendo mantido de forma consistente
- Pessoalmente, já tenho muita experiência com código em “C puro”, então é algo familiar
- Ele não recomenda o uso de C para outras pessoas; esta é uma escolha otimizada para seu gosto pessoal e sua forma de trabalhar
1 comentários
Opiniões do Hacker News
Eu normalmente escrevo código em estilo C, mas uso recursos de C++ só quando preciso
Então, à primeira vista, às vezes até parece código Rust
Quem diz que escreve jogos em C costuma odiar recursos de C++, mas no fim acaba implementando interfaces virtuais manualmente ou criando um switch gigante para fazer algo parecido
Se você não quer usar um recurso da linguagem, basta não usar; reclamar da simples existência dele não faz muito sentido
C++ não fica lento para compilar se você não abusar de templates
Com o passar do tempo, membros entram e saem, líderes mudam, e o conjunto de recursos usados vai crescendo
Depois que esse conjunto cresce, é muito difícil reduzi-lo
Além disso, você pode acabar tendo que usar bibliotecas que usam recursos que você não quer
Por exemplo, eu não gosto de chamadas implícitas (destrutores, sobrecarga de operadores etc.), mas se a biblioteca usa isso, no fim você é obrigado a acompanhar
Uma das piores partes do C++ é a quantidade enorme de código oculto gerado automaticamente
Mesmo que a maior parte do código lide com tipos concretos (Goose, Duck etc.), todos os objetos acabam carregando um ponteiro de vtable
Já o Rust usa vtable só onde precisa, economizando memória
O programador em C implementa apenas o que precisa manualmente, então fica menos preso às estruturas impostas pela linguagem
Só incluir
<vector>já puxa dezenas de milhares de linhas de códigoAí, se você evita a biblioteca padrão, começa a discussão de “por que reinventar a roda?”
Quando esse tipo de discussão se repete, voltar para C acaba sendo muito mais confortável
Eu também migrei para C por volta de 2017, e até hoje fico cansado sempre que preciso usar bibliotecas C++
Dear ImGui é uma exceção aceitável, mas ainda assim prefiro bindings em C
Quando troquei a extensão para .c, o tempo de compilação caiu pela metade
Eu gosto da natureza bruta e simples de C, embora odeie o pré-processador
Por isso, Zig parece um presente divino — é mais simples que C e tem um design de linguagem mais preciso
Por exemplo, Zig distingue ponteiro simples de ponteiro para array
Dá para importar bibliotecas C e torná-las mais fáceis de usar, o que é muito útil no desenvolvimento de jogos
A maioria das bibliotecas C++ também fornece headers em C
O zig-gamedev tem muitas dessas bibliotecas C adaptadas para Zig
No lugar do pré-processador, o recurso de comptime do Zig é muito melhor, e no fim é só “código Zig executado em tempo de compilação”
Eu também concordo com o autor
O maior motivo para eu gostar de uma linguagem é a simplicidade
Por isso prefiro linguagens como C, Go, Odin e Zig
Mas também é importante ter linguagens que lidem bem com a complexidade necessária
Para código de rede que exige segurança de memória, concorrência e padrões funcionais, Rust parece natural
Já para código simples e rápido, como em jogos indie, C ou Odin se encaixam bem
Odin parece uma combinação da simplicidade de Go com o desempenho de C, então eu recomendo
Também é fácil fazer jogos com Raylib
Fico curioso se você acha que Odin se encaixa melhor nesse lugar do que Zig
No texto original foi dito que o suporte de bibliotecas de jogos em Go era fraco, mas isso parece um texto de cerca de 2015
Hoje a situação pode ser diferente
Dá para ver capturas de tela dos jogos feitos naquela época
Por exemplo, Knossu tem um estilo 3D bem distinto
Em 2026, fazer jogos em C talvez seja meio insano, mas eu também faço isso
Por exemplo, desenvolvi Chrysalis em C (usando GLFW3 e FMOD)
Ela é baseada em idTech3, e o sistema de combate é tão preciso que até pequenas mudanças quebram todo o balanceamento
Até adicionar um simples
i++muda o timingPor isso ainda usamos exatamente o mesmo compilador de 22 anos atrás
Existem forks modernizados, mas eles perderam a sensação do original
idTech3 realmente mostra a essência de C como engine
Milhares de jogos foram escritos em C, e APIs gráficas como OpenGL, Vulkan e DX também são todas baseadas em C
Então isso não é nada estranho
A maioria das engines de jogo também é escrita em C/C++
Nos consoles isso varia de geração para geração
Diferentemente da programação em Linux, o desenvolvimento de jogos foi centrado em C++ por mais de 30 anos
Eu sou, no fundo, uma pessoa que ama C
Usei a linguagem muito bem por décadas, mas gerenciar código C em equipe aumenta bastante o sofrimento
Além disso, o ritmo de desenvolvimento é mais lento do que em linguagens modernas
Ainda assim, o apelo da simplicidade continua forte
Na minha experiência, C foi menos doloroso do que C++
Esse fato enfraquece o argumento de que C tem limitações para colaboração
Dizer que “ninguém faz jogos em C” é exagero
Hoje não é a abordagem dominante, mas ainda há muita gente fazendo jogos em C
Você só é uma exceção, e a frase ainda continua estatisticamente correta
Eu gosto de C
Tenho controle total sobre o gerenciamento de memória e consigo um comportamento previsível
Em ambientes que exigem pré-alocação, como nas regras MISRA, isso é especialmente útil
Também é bom para lidar diretamente com exceções ou erros em nível de hardware
Escrever testes unitários também é fácil
C tem uma barreira de entrada baixa, mas conhecimento de gerenciamento de memória é indispensável
Como desenvolvedor Java, quando precisei criar rapidamente um conector tendo apenas arquivos .h e .so, escolhi C em vez de C++
Se C é uma faca afiada, C++ é como um pilar giratório de facas — se você vacilar, se machuca
Mas o tratamento de strings em C é doloroso demais, então eu gostaria de pegar emprestado o sistema de strings do C++