¿Por que deberias crear tu propio motor de juegos?

Ya estamos en 2025 y todavia al hablar con gente en comunidades de desarrollo de juegos siempre veo que surge un pequeño pero frecuente debate: Crear un motor de juegos vs uno existente. Y siempre veo los mismos malentendidos sobre el tema de los motores de juegos y en general crear tus propias herramientas “desde cero” (no realmente).

Acá voy a explicar por que SÍ puede valer la pena hacerte tu propio motor de juegos según mi experiencia luego de pasar algo de tiempo trabajando en un juego sin usar un motor tradicional.

Tú eliges hasta qué punto reinventar la rueda

Uno de los malentendidos más comunes que veo en el debate sobre hacer o no un motor de juegos es que la gente entiende “motor de juegos” como algo similar a Unity, Godot o Unreal, donde cada uno viene con varias herramientas listas para su uso, un editor flexible con múltiples subsistemas para el manejo de distintos aspectos del desarrollo de juegos, así como lenguajes de scripting diseñados para ser más accesibles al público general. Pero nada de esto tiene por qué ser implementado en un “motor” hecho por ti mismo si solo planeas usarlo para tus propios juegos.

Un “motor” no es más que una colección de código reutilizable para crear distintos juegos. Nada más. El editor es opcional, las físicas también, el lenguaje de scripting también. Puedes usar un editor externo como Tiled o LDtk y gestionar tus entidades con el mismo código de tu motor de juegos.

Puedes incluir hot reloading mediante bibliotecas dinámicas y configurar un sistema de compilación que solo recompile lo necesario mientras trabajas, reduciendo así los tiempos de desarrollo. También puedes aprovechar bibliotecas como Raylib, Flecs, Bevy (si te gusta Rust) o SDL.

Si no te gusta “reinventar la rueda”, tú decides hasta qué punto reinventarla sin necesidad de hacerlo todo desde cero.

Trabajas cuando quieres, en lo que quieres

¿Recuerdas el escándalo de Unity de hace unos años? Depender tanto de una tecnología significa estar a merced de las decisiones técnicas y de negocio de su equipo, así como del éxito de su empresa. Esto va más allá de un simple drama de internet o creencias personales.
Mientras más te acoples a una dependencia, más difícil será cambiar a otra cuando esta comience a generar problemas. Esto no es un inconveniente si trabajas en pocos y pequeños proyectos, pero si tienes un negocio, lo más natural es que quieras crear herramientas para mejorar tu tiempo de desarrollo y maximizar ganancias.

Con un motor de juegos, por lo general, esto significa crear plugins que inevitablemente estarán acoplados a la API del motor. ¿Qué pasará la próxima vez que Unity cambie su modelo de negocios a uno que no te convenga? ¿Cuánto tiempo tardarás en migrar tu(s) juego(s) y herramientas a Godot o Unreal?

Por otro lado, si eres el propietario y mantenedor de al menos las herramientas que más utilizas, puedes asegurarte de que siempre serán relevantes para ti e incluso adaptarlas a otros flujos de trabajo si necesitas migrar algo. Tienes el control total sobre la arquitectura de tus proyectos, lo que te permite hacerlos tan modulares como sea necesario para reutilizar componentes e incluso integrarlos con otros motores si es necesario.

Obviamente, todo esto tiene un costo, pero lo que obtienes a cambio es la seguridad de que tus herramientas seguirán siendo tan relevantes como tú lo decidas.

Ambiente de desarrollo a medida

Esta es, personalmente, la razón por la que me cambié de Godot a Raylib. Hace algunos años aprendí a valorar más las herramientas que me permiten personalizar mi experiencia de desarrollo según mis necesidades, así como los flujos de trabajo más simplificados. Parece paradójico ¿no? Ando creando un motor de juegos, pero sí tiene sentido cuando lo piensas un poco.

Si bien personalizar herramientas toma más tiempo—y aún más si estás creando varias —al final puedes evitar aprender un editor con tres o cuatro sub-editores, más dos lenguajes de programación (uno para prototipado y otro para performance), además de las herramientas para la creación de assets. En su lugar, podrías reducir todo a un solo lenguaje de programación, un editor de niveles y las herramientas para el desarrollo de assets.

No se trata solo de la simplificación del proceso de desarrollo, sino también de la personalización. ¿Has pensado que tal vez podrías editar tus entidades usando archivos JSON? ¿O quizás transformar un archivo Markdown en una escena jugable con diálogos coherentes? Claro que todo esto se puede hacer en un motor de juegos, pero eso significaría gastar dinero (en caso de que quieras comprar plugins o extensiones) y sacrificar independencia, además de perder algo de performance.

Innovación técnica

No todos los juegos son tan fáciles de hacer sin tener el control técnico necesario. A veces, simplemente por el costo en términos de performance que conlleva el uso de un motor de juegos, tienes más limitadas las interacciones físicas que puedes hacer en la escena a la vez, la forma en la que quieres renderizar o el control que necesitas sobre tu game loop, dependiendo del tipo de juego que vayas a desarrollar.

A veces, simplemente es más conveniente crear tus propias herramientas enfocadas en tus necesidades que usar una que no está hecha para lo que intentas hacer.

Tengo claro que es perfectamente viable crear negocios y vivir del desarrollo de juegos sin ser muy disruptivo o innovador, y enfocarse más en la parte artística y de diseño que en la técnica. Pero si te interesa tener más control para llevar a cabo tus ideas, irte por la ruta low level suele ser más conveniente.

Simplemente es más divertido

¿Qué sentido tiene dedicarte a algo que supuestamente te gusta si al final no vas disfrutar el proceso por una u otra tecnología? En mi opinión, el costo de tiempo y esfuerzo vale la pena si eso hace que disfrutes mas de tus actividades.

Algunos simplemente preferimos enfrentarnos y resolver los desafíos técnicos que conlleva usar un lenguaje de programación de bajo nivel y crear sistemas gráficos complejos como los videojuegos. Y si eso es lo que más te gusta… realmente no hay mucho que pensar, ¿o sí? Solo ve por lo que te hace sentir más cómodo y disfruta de tus actividades tanto como sea posible.

Al final, aunque no te sirva de nada todo lo que habrás construido, habrás aprendido muchísimo, y esta experiencia también se va a traducir en criterio técnico, algo clave para decidir mejor qué herramientas te convienen en cada proyecto. Así que, en mi opinión, si lo disfrutas, solo ve por ello sin pensarlo mucho.

No todo es tan bonito…

También hay que ser honestos: esto no es para todos. No solo es el hecho de que hay que tener experiencia en programación para poder encarar los desafíos que surgen en esta ruta, sino que también cuesta tiempo y dinero.

Al final, los videojuegos también son un negocio, y no todos se pueden dar el lujo de gastar semanas o meses preparando herramientas para luego empezar a trabajar en su producto. Si bien puedes reducir el tiempo usando bibliotecas, la integración entre todas estas también tiene un costo en tiempo y complejidad.

Otro problema es el soporte a plataformas muy específicas. Afortunadamente, el mercado para PCs es bastante flexible, pero no se puede decir lo mismo del mercado mobile o de consolas. A veces, simplemente es mejor usar una herramienta que ya resuelve estos dolores de cabeza por ti… a menos que seas Jonathan Blow y tengas el dinero suficiente para pagar licencias y/o equipos de desarrollo que te apoyen con estos detalles.

Conclusión

Si hay algo que nunca se nos puede olvidar, es que tú tienes la decisión final. Si disfrutas más haciéndote tu propio motor de juegos o usando uno ya existente, ¿quién soy yo para decirte qué hacer? Siempre trabaja de la manera que más se acomode a ti.

Eso sí, cada decisión técnica en software tiene sus consecuencias, y en mi opinión, nunca está de más aprender cuáles son las ventajas, desventajas y alternativas de las decisiones que tomamos.

Al final, lo importante es que disfrutes lo que haces. Haz cosas, equivócate, aprende, y sobre todo, ¡pásala bien!.