Desarrollar videojuegos sin un motor de juego (2025)

 (noelberry.ca)
33 puntos por GN⁺ 2025-05-21 | 5 comentarios | Compartir por WhatsApp
  • Incluso sin un motor de juego comercial, es totalmente posible desarrollar juegos de forma fácil y divertida
  • La mayoría de las funciones de los motores grandes no son necesarias, y crear herramientas propias aumenta la flexibilidad y la eficiencia de desarrollo
  • Aprovechando C# moderno y bibliotecas de código abierto, es posible contar con un entorno de desarrollo suficiente sin importar el tamaño del equipo
  • Combinando bibliotecas como FMOD, SDL3, Dear ImGui con herramientas propias, se puede armar un pipeline ajustado a las necesidades
  • En términos de desarrollo multiplataforma, mantenimiento y portabilidad, un framework ligero construido por cuenta propia ofrece muchas ventajas

Prólogo: reflexiones de un desarrollador de juegos con 20 años de experiencia

  • En 2025, sigo desarrollando videojuegos sin motores de juego comerciales
  • A menudo a la gente de mi alrededor le sorprende que no use un motor comercial
  • Las funciones básicas de motores grandes como Unity o Unreal resultan menos satisfactorias que implementarlas directamente, y al final terminas rehaciendo muchas partes
  • Al usar motores comerciales, se está expuesto a problemas causados por cambios frecuentes en las políticas de negocio o por actualizaciones
  • Crear directamente herramientas pequeñas ajustadas a cada proyecto es más eficiente y, a largo plazo, también más fácil de mantener

Elección del lenguaje de programación necesario para desarrollar juegos

  • Durante mucho tiempo he usado C# como lenguaje principal
  • El C# moderno ha mejorado mucho en rendimiento, sintaxis y experiencia de desarrollo en comparación con el pasado
  • Cuenta con funciones de hot reload como dotnet watch, lo que resulta muy conveniente para modificar y probar código en tiempo real
  • Incluso personas no desarrolladoras pueden acercarse con facilidad, lo que mejora la distribución de roles y la eficiencia de la colaboración dentro del equipo
  • La función integrada de reflection ofrece ventajas al crear editores o herramientas

Bibliotecas multiplataforma e implementación de renderizado y entrada

  • Uso SDL3 para implementar todas las funciones básicas: ventanas, renderizado, controladores y soporte multiplataforma
  • La abstracción de GPU de SDL3 facilita el soporte para distintos entornos como DirectX, Vulkan, Metal
  • Encima de SDL, utilizo una capa en C# escrita por mí (por ejemplo, Foster) como utilidad compartida
  • Uso FMOD como la última herramienta de audio comercial que me queda; fuera de eso, construyo un pipeline basado en código abierto
  • Antes también tuve experiencia implementando directamente OpenGL/DirectX, pero la estabilidad de SDL es una ventaja considerable

Cómo manejar los assets

  • Cuando se usa un motor propio, simplemente se cargan los archivos que el juego necesita
  • En el caso de assets pequeños, como en un juego de pixel art, todos los archivos se cargan de una vez durante la inicialización
  • En proyectos grandes, solo se cargan los assets cuando se solicitan, y se libera memoria al cambiar de escena
  • Si se necesita conversión, basta con escribir scripts que la procesen automáticamente durante la compilación

Editor de niveles y herramientas de UI

  • Es fácil vincular datos con editores de niveles de código abierto como LDtk, Tiled, Trenchbroom
  • Por lo general, implemento directamente editores personalizados para cada proyecto
  • No escribo la UI base desde cero, sino que aprovecho activamente la GUI de modo inmediato de Dear ImGui
  • La combinación de reflection de C# con ImGui permite visualizar en tiempo real el estado de los objetos del juego
  • Cuando hace falta, mezclo herramientas externas adecuadas para el propósito con herramientas propias

Multiplataforma y portabilidad a consolas

  • Antes, por los problemas al portar a consolas, había una gran necesidad de elegir C++, pero eso se resolvió con la llegada de C# Native-AOT
  • Frameworks de código abierto como FNA están ampliando activamente el soporte para consolas
  • Si se aprovecha la capa de abstracción general que ofrece SDL3, es posible operar con la misma base de código en la mayoría de los sistemas

Entorno de desarrollo: ecosistema abierto centrado en Linux

  • Cambié mi plataforma principal de desarrollo a Linux, y encaja muy bien con el toolchain de código abierto
  • Aún quedan vínculos con cierto software comercial (por ejemplo, vscode, github), pero mientras más se expande el ecosistema de código abierto, más crece también el soporte
  • En lo personal, estoy configurando el mismo entorno de trabajo en diversas plataformas basadas en Linux, como Steam Deck

Q&A adicional y casos

  • Consulta sobre usar Godot: si se busca desarrollar con un motor de código abierto, recomiendo Godot; fuera de eso, prefiero herramientas personalizadas
  • Trabajo en 3D: los motores grandes tienen ventajas, pero para proyectos pequeños y especializados, un framework a medida es suficiente
  • Requisitos técnicos de alto rendimiento: según el nivel de exigencia, usar motores grandes como Unreal también es perfectamente válido
  • Cambio de motor a nivel de equipo: es adecuado para desarrollo individual o de equipos pequeños, y también están aumentando los casos de estudios medianos y grandes que migran a motores personalizados para evitar riesgos a largo plazo
  • Flujo de trabajo de assets: los archivos de Aseprite pueden convertirse automáticamente en animaciones aprovechando etiquetas y tiempos integrados

Conclusión

  • Hacer juegos sin un motor de juego comercial es una elección que depende del gusto personal y la forma de trabajar
  • Basta con priorizar las necesidades y la diversión, y elegir el método que mejor se adapte a uno mismo

Lecturas relacionadas

5 comentarios

 
assembler 2025-05-29

Es una buena actividad.
Yo fui un desarrollador de juegos de primera generación.
Antes de que saliera Unreal, por supuesto las desarrolladoras
tenían como algo natural desarrollar su propio motor,
y eso era precisamente su competitividad.
En el desarrollo de motores, la mayor parte del trabajo era crear herramientas
basadas en el core, el kernel, el renderizado y otras entradas y salidas.
En ese entonces yo estaba a cargo de las herramientas de partículas, sonido, capas y objetos,
y aunque el equipo era de 7 personas, si juntabas todo creo que fácilmente
superábamos las 20 herramientas.

Desde cierto día, cuando apareció Unreal y empezaron a salir en masa juegos hechos en serie,
ya no siguieron invirtiendo en desarrollar motores.
Creo que en ese momento muchos se independizaron y fundaron sus propias empresas.
Ya es una historia de hace 27 años.

Yo también, con el paso del tiempo, envejecí y ahora trabajo en algo que no es videojuegos.

Recuerdo con nostalgia aquella época en la que hacía trabajo de core
según la tarjeta gráfica y los modos de DirectX y OpenGL.

Ánimo...
 
chanapple 2025-05-21

Últimamente he estado buscando durante mucho tiempo un motor para hacer un juego de estrategia, así que pensé que quizá sería mejor hacer uno yo mismo, pero ver un caso exitoso de alguien que realmente lo hizo me llena de valor.
 
GN⁺ 2025-05-21
Opiniones de Hacker News

  • Tras pasar 5 años desarrollando en solitario un motor 2D y haciendo trabajo remunerado relacionado, quiero explicar un punto importante que mucha gente no conoce
    el motor es la parte fácil
    lo realmente importante es el tooling alrededor del motor, el contenido y el pipeline de assets
    importar texturas, audio y archivos de modelos (gltf, fbx, animaciones, etc.) desde distintas fuentes y formatos de datos
    funciones básicas de edición en la app del editor, como recortar, copiar, pegar, deshacer, rehacer, guardar y borrar
    visualización y funciones que permitan a los desarrolladores crear y manipular datos reales desde el editor (entidades, animaciones, escenas, grafos de audio, soporte de scripting, etc.)
    empaquetado y preprocesamiento de datos, como baking de geometría estática, compilación de shaders, resampling y empaquetado de texturas/audio, y creación de asset packs de contenido del juego
    cuando todo eso está terminado, la parte de runtime en sí (es decir, el loop principal del juego y sus subsistemas) es una parte pequeña del sistema completo
    por eso en los estudios de videojuegos hay poca gente encargada del motor y la mayoría de los programadores hacen herramientas
    motor detonator: https://github.com/ensisoft/detonator

    • Es importante enfocarse en hacer un motor que se ajuste a tu juego, más que en la generalidad
      la UI, la compresión, etc. se pueden resolver con librerías y frameworks
      el uso que hace OP de una librería pequeña como imGUI es un buen ejemplo
      como no estás haciendo un motor para todos los juegos, en la práctica hay mucho trabajo que ni siquiera hace falta hacer

    • El motor es como un pequeño runtime pegado a un pipeline de assets
      hoy en día, incluso los compiladores de shaders se están volviendo más importantes que las APIs 3D
      la parte interesante se concentra en el compilador de shaders, y la API 3D se limita a ejecutar shaders y pasar datos

    • Cuando la gente habla de motor, muchas veces tiende a incluir también el pipeline de assets y el editor
      los motores actuales no son solo un loop principal + funciones de API 3D
      aun si usas un motor como Unity, son muy pocos los desarrolladores que solo escriben código de renderizado
      claro, eso no significa que al usar Unity/Unreal nunca vayas a tocar herramientas de assets por tu cuenta

    • Estoy muy de acuerdo con esto después de rehacer el motor para una secuela reciente
      como escribí en el postmortem, la mayoría piensa en el motor como el código incluido en el ejecutable del juego, pero en la práctica creo que pesa más el código que no se distribuye con el juego, como el editor de niveles, el pipeline de contenido, el debugging/profiling y el workflow de desarrollo
      desarrollar herramientas es más aburrido y más desgastante que desarrollar el motor
      por eso tantos desarrollos de juegos con motor personalizado se quedan a mitad del camino
      postmortem: https://ruoyusun.com/2025/04/18/game-sequel-lessons.html

    • Hacer un editor desde cero es bastante trabajo
      si se puede, conviene aprovechar editores ya existentes
      por ejemplo, la combinación TrenchBroom (editor de Quake) + func_godot, o Tiled para 2D
      para gestionar datos del juego también estaba CastleDB, aunque ahora está integrado con Hide (un editor 3D más serio)
      después de crear las herramientas, diseñar el juego y producir contenido vuelve a ser otra etapa principal

  • Hace unos años hice una clase simple de "sprite" con SDL2 y un poco de C++, y le fui agregando funciones sencillas como colisiones
    si insistiera en llamarle motor a lo que hice, era más bien como la asistencia de una bicicleta eléctrica
    el problema es que el "motor" muchas veces termina guiando todo el proyecto/juego
    a menudo acabas adaptando el juego al motor, por eso siempre evito usar motores grandes como Unity
    al final esos motores tienden a producir la misma estructura de juego, solo cambian los assets
    personalmente, en vez de perder tiempo aprendiendo un motor, prefiero empezar con SDL, que tiene una curva de aprendizaje corta y además sirve para otros proyectos multiplataforma fuera de juegos
    mi juego: https://store.steampowered.com/app/2318420/Glypha_Vintage/

  • Aunque se diga que hacer tu propio motor toma mucho tiempo, pregunto cuánto tiempo hace falta para aprender Unreal o Unity de verdad, hasta el punto de poder convertir una idea en juego de inmediato
    al final, cuando termino mi propio motor, ya tengo precisamente ese nivel de especialización, así que a largo plazo ahorro tiempo
    cuanta más experiencia acumulas como ingeniero, más te conviene hacerlo tú mismo en términos de tiempo
    cuanto más único o de nicho sea el juego, más sentido tiene hacerlo por tu cuenta
    pasar meses perdido en la UI compleja de Unreal y descubrir que lo que querías era casi imposible en un motor generalista es ineficiente
    en cambio, si vas a hacer un RPG de mundo abierto hiperrealista, construirlo tú mismo no es una buena opción
    las limitaciones de un motor personalizado incluso pueden fomentar la creatividad, y aunque no salga algo de primer nivel, sí puede salir un juego más original

    • Yo sí hice mi propio motor
      al principio me tomó alrededor de un año, atravesando muchísimos intentos fallidos y callejones sin salida
      implementé casi todos los subsistemas que uno puede ver en un juego: renderizado 3D, UI adaptativa, animación esquelética, archivos de guardado, smart objects, pathfinding, scripting, audio, física, etc.
      en particular, implementé por mi cuenta una función de rebobinado (como el sistema de Braid)
      ese tipo de función requiere soporte de todos los subsistemas del motor (scripts, física, etc.)
      como conozco cada parte del motor que hice, tengo una libertad enorme para desarrollar funciones adicionales
      pero después de un año de desarrollo me fui quemando poco a poco y perdí la motivación

    • No conozco Unreal, pero con Unity se puede desarrollar más de 10 veces más rápido que programando todo directamente
      agregar física puede tomar 1 minuto, mientras que en un motor propio solo integrar una librería externa puede tomar uno o dos días
      las funciones de visualización interna que muestra Noel en Unreal también vienen integradas en Unity
      ediciones como manipular bounding boxes ya vienen incluidas por defecto
      si el comportamiento base del motor no te alcanza, se puede extender fácilmente con ImGui o un motor CSS basado en Yoga
      ofrece muchísimas funciones, como un editor avanzado de partículas, shaders con complejidad abstraída y streaming modular de datos
      en teoría uno querría hacerlo todo por su cuenta, pero al final manda el tiempo y la prioridad es terminar

    • El tiempo que toma aprender Unreal o Unity hasta poder implementar una idea de juego de inmediato, y el tiempo que toma hacer tu propio motor, son preguntas distintas
      si me das una idea sencilla, puedo hacer un prototipo jugable en unas horas
      en Unity al principio basta con programar, y en Unreal puedes llegar casi hasta el lanzamiento de un juego usando solo Blueprints
      como referencia, aquí hay un video donde hacen un prototipo estilo Super Hexagon en 10 minutos: https://www.youtube.com/watch?app=desktop&v=p8MzsDBI5EI
      lo único realmente específico de Unity sería algo como los prefabs; el resto son conceptos generales del desarrollo de juegos
      si vienes de Unreal, también podrías hacer un prototipo parecido en Unity en menos de una hora

    • La suposición de “después de terminar el motor” quizá ya es irrealista
      incluso una acción simple como GameObject.Instantiate exige una cantidad enorme de recursos si tienes que implementarla tú mismo en el motor
      si consideras la complejidad de física 2D/3D, shaders y soporte de plataformas
      si tu objetivo es el motor, haz el motor; si tu objetivo es el juego, haz el juego

    • Si ya tienes suficiente conocimiento de desarrollo de juegos como para crear un motor de juego
      un día basta para aprender Unreal o Unity al nivel de hacer un prototipo
      llegar a la perfección toma mucho más, pero el tiempo para terminar el prototipo del juego que quieres no tiene comparación

  • Hacer juegos sin un gran motor "que lo hace todo" es más fácil, más divertido y a veces más eficiente
    pero cuando te metes a fondo en funciones específicas del motor (por ejemplo, la cinemática inversa de Unreal o el animation blending), terminas pensando “menos mal que no tuve que sufrir 2 o 3 semanas haciéndolo yo mismo”
    el minimalismo o evitar la hinchazón también importan, pero estos motores son populares porque cargan con el trabajo pesado

    • Antes yo también trabajaba así
      cuando hice mi primer juego 3D, implementé entrada, gestión de objetos, culling, carga de modelos, librería matemática, gráficos, normal maps, SSAA y todo lo demás, y al final el porcentaje de juego terminado fue 0%
      aun así, en mis proyectos 2D de hobby sigo desarrollando sin dependencias, solo con el canvas del navegador
      en la práctica, el navegador hace el papel de motor

    • Sobre la idea de “menos mal que no lo hice yo mismo”
      si piensas en una carrera de desarrollador indie a largo plazo, aunque te lleve unas semanas, entender el tema en profundidad + tener el 100% del código fuente + el valor de poder reutilizarlo pesa más

    • Mi tesis de grado trató de portar un motor de partículas basado en NeXTSTEP/Objective-C a Windows 95/Visual C++ (basado en OpenGL, con un ejemplo de marching cubes)
      hoy ese tipo de tema en los motores actuales no pasa de ser una pequeña función de una línea

    • Usar un motor acelera muchísimo el avance del proyecto y evita gastar tiempo en desarrollar infraestructura
      volver a inventar la rueda no suele ser algo especialmente divertido para la mayoría

    • Funciones como la cinemática inversa o el animation blending
      si son el núcleo del juego, vale la pena implementarlas; si no, son una trampa técnica innecesaria

  • Hago juegos a mi manera usando Lua y Love2D
    parte de la diversión está justamente en autoimponerse restricciones
    si desarrollar deja de ser divertido, es señal de que algo anda mal y toca buscar un mejor método
    mi juego YOYOZO pesa 39 KB, pero apareció junto a producciones grandes en la lista de mejores juegos de 2023 de Ars Technica
    https://news.ycombinator.com/item?id=38372936

    • Me acuerdo de ese juego
      después de años de haber comprado una Playdate, recién empecé a jugar con el SDK, y también estoy aprendiendo Lua por primera vez
      aunque a veces extraño los tipos fuertes y más seguridad del lenguaje, para este caso es suficientemente bueno
      lo único que hice fue una pequeña demo técnica donde texto gira en un espacio 3D falso según el crank
      https://bsky.app/profile/haydenblai.se/post/3lpgnya4cqk2a
      haciendo este proyecto me di cuenta de que, tras tantos años de experiencia en CRUD/webapps, casi había olvidado toda la trigonometría
      la mayor ventaja del desarrollo para Playdate es la liberación que da tener un canvas fijo: defines la posición de los píxeles y funciona igual en todos los dispositivos
      después de tantos años haciendo solo UI responsiva, esa experiencia se siente muy nueva

  • Cada vez que intento hacer algo con un motor de juego (Godot, Unity, Unreal, etc.), termino peleándome con el motor
    al final se siente como poner assets encima de un formato de juego ya definido, y se vuelve difícil hacer el juego que realmente quiero
    si lo comparas con desarrollo web, se parece a usar un producto terminado como WordPress
    cuando la configuración base no coincide con tu intención, hace falta una cantidad enorme de hacks y rodeos

  • El autor (Noel) hizo el juego Celeste y vendió más de 3 millones de copias
    https://en.wikipedia.org/wiki/Celeste_(video_game)

  • Yo también coincido bastante y estoy creando un framework de juego en C# centrado en código (un sucesor espiritual de XNA/Monogame, usando Sokol en vez de SDL)
    https://zinc.graphics/
    fortalezas del C# moderno: multiplataforma, compilación NativeAOT, hot reloading nativo, reflection, etc.
    personalmente también le agregué source generators
    aunque todavía arrastra una imagen negativa del pasado, lo que han avanzado CoreCLR y el lenguaje en los últimos 5 años ha sido impresionante
    lo único que realmente me gustaría tener son Union Types, y como ya hay una propuesta, espero que se agreguen el próximo año
    https://github.com/dotnet/csharplang/blob/main/proposals/TypeUnions.md

    • Me pregunto si hay material de referencia para empezar con C# en proyectos como este
      solo he usado C# en Win32 o Unity, y aunque tengo conocimientos de motores de bajo nivel en C/C++, pensaba que C# no era viable para multiplataforma como consolas
      ahora me doy cuenta de que estaba equivocado

  • Para cualquier software, prefiero empezar desde cero
    a quien tiene experiencia en proyectos grandes eso puede parecerle lento, pero en etapa startup en realidad es más rápido
    implementas solo lo mínimo, y una vez que aparecen abstracciones, agregar nuevas funciones se vuelve más rápido
    la productividad del software empresarial grande y la de un mini motor que escribí yo mismo son completamente distintas
    el código que escribí yo mismo se puede cortar y refactorizar enseguida, así que voy mucho más rápido
    por eso prefiero microservicios y equipos pequeños
    cuando haces algo tú mismo, inevitablemente atraviesas ensayo y error y un campo minado de cosas que se rompen, y además hacen falta años para entender de verdad las características reales del lenguaje o la plataforma
    pero todo ese proceso termina convirtiéndose en experiencia real del desarrollador
 
kissdesty 2025-06-10

Más que un motor, me pregunto qué tal sería usar algo al nivel de un framework como MonoGame~
 
lazyhack 2025-05-23

"Ese proceso en sí mismo al final se queda como experiencia acumulada del desarrollador". Estoy totalmente de acuerdo.