Por qué hago juegos en C (sí, en C)

• Desarrollo todos los juegos de mis proyectos personales en "C puro", una elección poco común hoy en día
• Los criterios clave para elegir lenguaje son confiabilidad, portabilidad y sostenibilidad a largo plazo, sin depender de un SO o plataforma en particular
• Valoro la simplicidad y la velocidad de compilación, además de la verificación estricta de tipos y un sólido sistema de advertencias
• Evalué lenguajes alternativos como C++, C#, Java, Go y Haxe, pero concluí que no eran adecuados por su complejidad, el GC o la imposición de OOP
• C es peligroso, pero simple y rápido, y sigue siendo la mejor opción gracias a su amplio soporte multiplataforma y a un ecosistema de bibliotecas robusto

---

Criterios para elegir un lenguaje

• La condición indispensable es la confiabilidad y estabilidad, para no perder tiempo en bugs que yo no causé
  • En el pasado desarrollé juegos basados en Flash, pero con la caída de Flash quise concentrarme en crear juegos nuevos en lugar de portar a otra plataforma
  • Doy prioridad a la portabilidad y al soporte de bibliotecas de propósito general para no quedar atado a un SO específico y mantener abierta la posibilidad de desarrollar para consolas
• Entre las condiciones deseables, destaco una sintaxis simple y una estructura fácil de recordar
  • Quiero evitar estar consultando constantemente APIs complejas o características del lenguaje
• Busco reducir bugs mediante verificación estricta de tipos, advertencias potentes y análisis estático, y encontrar problemas con facilidad usando buenos depuradores y herramientas de análisis dinámico
• La velocidad de compilación es muy importante
  • Las esperas largas rompen la concentración y reducen la productividad
• Soy escéptico con la programación orientada a objetos (OOP) y prefiero un enfoque que separe datos y código para tratarlos según convenga

Evaluación de los principales lenguajes alternativos

• C++
  • Sigue siendo el estándar en desarrollo de videojuegos, pero me deja insatisfecho por su complejidad y lenta velocidad de compilación
  • Ofrece alto rendimiento y muchas funciones, pero tiene demasiadas características que no quiero y un costo de complejidad alto
• C# y Java
  • Son verbosos y complejos, y su fuerte estructura centrada en OOP reduce la flexibilidad
  • Como lenguajes de alto nivel, esconden la complejidad, pero no evitan los problemas de fondo
• Go
  • Lo valoro positivamente como una reinterpretación moderna de C, pero su recolección de basura stop-the-world lo hace poco adecuado para desarrollo de juegos
  • También hay preocupación por la falta de bibliotecas para juegos y por su sostenibilidad a largo plazo
• JavaScript
  • El cambio acelerado del entorno web y el fin de Flash hacen que se sienta inestable
  • Concluyo que su sintaxis laxa no es adecuada para escribir software de gran escala
• Haxe
  • Lo considero prometedor para desarrollo web, pero al ser un lenguaje relativamente nuevo existen dudas sobre su continuidad
• Desarrollar un lenguaje propio
  • Es una idea atractiva, pero no parece realista por la renuncia a bibliotecas existentes y la carga de mantener compatibilidad

Por qué elegir C

• Es un lenguaje peligroso pero confiable que, gracias a su estructura simple, puede ser estable si se usa con cuidado
  • Lo compara con un "cuchillo afilado": difícil de manejar, pero una herramienta poderosa cuando se domina
• La velocidad de compilación es muy alta y puede ejecutarse en casi cualquier plataforma
  • El proceso de portabilidad también es relativamente sencillo, y su viabilidad a largo plazo es alta
• El soporte de bibliotecas y tooling es sólido y se mantiene de forma constante
• En lo personal, ya tengo mucha experiencia escribiendo código en "C puro", así que me resulta familiar
• No recomienda usar C a otras personas; para él, es una elección optimizada para sus preferencias personales y su forma de trabajar

[GN⁺]

Opiniones en Hacker News

• Yo suelo escribir código más bien con estilo C, pero uso funciones de C++ solo cuando hacen falta
  Por eso, a simple vista, a veces hasta parece código Rust
  La gente que dice que escribe juegos en C termina odiando las funciones de C++, pero igual implementa sus propias interfaces virtuales o arma switches enormes para hacer algo parecido
  Si no quieres usar una función del lenguaje, simplemente no la usas; no le veo sentido a quejarse de que exista
  C++ no compila lento si no abusas de las plantillas

  • Eso puede funcionar cuando desarrollas solo, pero en proyectos de equipo que se mantienen durante mucho tiempo la situación es distinta
    Con el tiempo cambian los integrantes y también los líderes del equipo, y el conjunto de funciones usadas se va ampliando cada vez más
    Una vez que ese conjunto crece, es muy difícil volver a reducirlo
    Además, puede que tengas que usar bibliotecas que emplean funciones que no quieres
    Por ejemplo, a mí no me gustan las llamadas implícitas (destructores, sobrecarga de operadores, etc.), pero si la biblioteca las usa, al final te toca seguir esa línea
  • Al menos un switch se puede leer
    Una de las peores cosas de C++ es que genera demasiado código oculto automáticamente
  • El despacho dinámico en C++ funciona poniendo una vtable en todos los tipos
    Aunque la mayor parte del código trabaje con tipos concretos (Goose, Duck, etc.), todos los objetos cargan con un puntero a vtable
    En cambio, Rust usa vtables solo donde hacen falta, así que ahorra memoria
    Los programadores de C implementan solo lo necesario por su cuenta, así que quedan menos atados a estructuras impuestas por el lenguaje
  • C++ es lento incluso sin abusar de las plantillas
    Con solo incluir <vector> ya entran decenas de miles de líneas de código
    Entonces, si no usas la biblioteca estándar, empieza la discusión de “por qué estás reinventando la rueda”
    Cuando esa discusión se repite una y otra vez, volver a C es muchísimo más cómodo
    Yo también me pasé a C por ahí de 2017, y todavía hoy me cansa cada vez que tengo que usar una biblioteca de C++
    Dear ImGui es una excepción aceptable, pero aun así prefiero sus bindings de C
  • De hecho, una vez escribí un archivo C++ sin usar ni una sola función de C++
    Cambié la extensión a .c y el tiempo de compilación se redujo a la mitad

• Me gusta el carácter rudo y simple de C, aunque no me gusta el preprocesador
  Por eso Zig me parece un regalo de los dioses: es más simple que C y tiene un diseño de lenguaje más preciso
  Por ejemplo, Zig distingue entre punteros simples y punteros a arreglos
  Puedes importar bibliotecas de C y hacerlas más cómodas de usar, lo cual es muy útil en desarrollo de juegos
  La mayoría de las bibliotecas de C++ también ofrecen headers de C
  En zig-gamedev hay muchas de estas bibliotecas de C adaptadas a Zig
  En lugar del preprocesador, la función comptime de Zig es mucho mejor, y al final no es más que “código Zig que se ejecuta en tiempo de compilación”

  • Pero en la práctica, son poquísimas las bibliotecas de C++ que realmente exportan headers de C

• Yo también coincido con el autor
  La razón principal por la que uno termina queriendo un lenguaje es su simplicidad
  Por eso prefiero lenguajes como C, Go, Odin y Zig
  Pero también importan los lenguajes que manejan con elegancia la complejidad necesaria
  Para código de red donde hacen falta seguridad de memoria, concurrencia y patrones funcionales, Rust se siente natural
  En cambio, para código simple y rápido como el de un juego indie, C u Odin encajan muy bien
  Odin se siente como una combinación entre la simplicidad de Go y el rendimiento de C, así que lo recomiendo
  Además, es fácil hacer juegos con Raylib

  • Curiosamente, yo suelo describir Zig como un punto medio entre Go y C
    Me pregunto si crees que Odin encaja mejor ahí que Zig
  • Como referencia, el nombre del lenguaje es Go; golang es solo el nombre del dominio

• En el texto original se decía que Go tenía poco soporte de bibliotecas para juegos, pero eso parece un artículo de alrededor de 2015
  Puede que ahora la situación ya sea distinta

  • En la Wayback Machine hay una captura de enero de 2016
    También se pueden ver capturas de pantalla de los juegos que hizo en ese entonces
    Por ejemplo, Knossu tiene un estilo 3D bastante particular

• Hacer juegos en C en 2026 quizá sea una pequeña locura, pero yo también lo hago
  Por ejemplo, desarrollé Chrysalis en C (usando GLFW3 y FMOD)

  • Llevo 2 años trabajando con la base de código de Jedi Academy (C y C++)
    Está basada en idTech3, y su sistema de combate es tan preciso que cualquier cambio pequeño rompe todo el balance
    Incluso agregar un i++ puede alterar el timing
    Por eso seguimos usando exactamente el mismo compilador de hace 22 años
    Hay forks modernizados, pero perdieron la sensación original
    idTech3 de verdad muestra la esencia de C como motor

• Miles de juegos se escribieron en C, y APIs gráficas como OpenGL, Vulkan y DX también están basadas en C
  Así que no tiene nada de raro
  La mayoría de los motores de juego también están hechos en C/C++

  • Las APIs de Khronos son C, DirectX está basado en COM/WinRT de C++, y Metal es una mezcla de Objective-C y C++
    En consolas depende de la generación
  • SDL3 también está escrito en C, y la versión más reciente de Box2D también fue reescrita en C
  • DirectX es C++, y la mayoría de los motores de juego también son C++
    A diferencia de la programación en Linux, el desarrollo de juegos ha estado centrado en C++ durante más de 30 años

• Yo, en el fondo, amo C
  Lo he usado bien durante décadas, pero manejar código C en equipo se vuelve más doloroso
  Además, comparado con lenguajes modernos, la velocidad de desarrollo es menor
  Aun así, el encanto de la simplicidad sigue ahí

  • Me da curiosidad por qué una base de código en C duele más en trabajo de equipo
    En mi experiencia, C fue menos doloroso que C++
  • “Decir menos y significar más”: o sea, la clave está en la concisión
  • Solo en 2025 participaron 2,134 desarrolladores en el kernel de Linux
    Ese hecho debilita la idea de que C tenga límites para la colaboración

• Decir que “nadie hace juegos en C” es una exageración
  Quizá ya no sea lo dominante, pero todavía mucha gente hace juegos en C

  • Expresiones como “nadie” o “todos” normalmente no son absolutas
    Tú solo eres la excepción, y la frase sigue siendo correcta en términos estadísticos

• Me gusta C
  Te da control total sobre la gestión de memoria y permite obtener un comportamiento predecible
  Es especialmente útil en entornos que exigen preasignación, como las reglas MISRA
  También sirve muy bien para manejar directamente excepciones o errores a nivel de hardware
  Es fácil escribir pruebas unitarias

• C tiene una barrera de entrada baja, pero el conocimiento de gestión de memoria es indispensable
  Como desarrollador Java, cuando me tocó armar rápido un conector teniendo solo archivos .h y .so, elegí C en vez de C++
  Si C es un cuchillo afilado, C++ es como un pilar de cuchillas giratorias: si te descuidas, te corta
  Eso sí, el manejo de cadenas en C es demasiado doloroso, así que dan ganas de tomar prestado el sistema de strings de C++

  • Lo bueno de C++ es que no tienes que usar las funciones que no quieres