Por qué estoy creando mi propio motor de videojuegos

Por qué no he elegido Unity o Unreal

Podría haber empezado con Unity o Unreal Engine. Son herramientas potentes y para muchos proyectos tienen todo el sentido. Mi razón principal para crear un motor propio es tener un control absoluto sobre mi tecnología: poder entender y modificar hasta el más mínimo detalle del motor, de las herramientas y de cómo se conectan.

Esa libertad permite adaptar la tecnología a lo que necesita cada juego. Si una ciudad requiere otro tipo de parcela, una prenda necesita ajustarse a un cuerpo o una animación exige un control nuevo, quiero poder cambiar la pieza que lo resuelve y decidir cómo trabaja con las demás.

Ese control es la gran ventaja, y también supone una enorme cantidad de trabajo. Cada sistema hay que construirlo, probarlo y mantenerlo, incluso cuando un motor comercial ya lo ofrece resuelto. Es una apuesta a largo plazo: asumir ese esfuerzo para tener una base propia que pueda especializar, conectar y aprovechar en distintos juegos.

Qué hay debajo: C++, Vulkan y Jolt

El núcleo está escrito en C++ nativo. Me permite decidir cómo se organizan los datos, cómo se carga una escena y dónde se está gastando el tiempo de cada fotograma. Hay mucho trabajo poco vistoso aquí, pero acaba importando cuando todo tiene que funcionar a la vez.

Empecé construyendo la parte gráfica sobre OpenGL. Me equivoqué con esa elección para el tipo de motor que quería desarrollar. Al incorporar geometría virtualizada y carga de datos por partes, necesitaba más control sobre cómo se organiza el trabajo de la GPU, qué ocupa la memoria y cuándo está listo cada recurso. Esa es la razón del cambio a Vulkan.

Ahora estoy llevando esa base a Vulkan 1.4. El backend ya existe y la integración sigue en marcha. Hay que trasladar sistemas, comprobar que siguen dibujando bien y medir qué mejora. Es una decisión que habría tomado antes si empezara de nuevo, y también una de las lecciones de construir el motor sobre la marcha.

Para la física uso Jolt, pero la integración también lleva trabajo propio. Por ejemplo, he adaptado el controlador de las motos para calcular su inclinación según la velocidad y el giro, y ajustar cómo recuperan el equilibrio. Jolt sigue resolviendo los contactos y las colisiones; ese control adicional permite trabajar el comportamiento que busco al conducir.

También estoy conectando la física con las animaciones. En una caída, por ejemplo, el cuerpo físico parte de la pose que tenía el personaje animado y Jolt continúa el movimiento, con masas y límites de articulación ajustados para el personaje. Ese paso entre animación y física tiene muchos detalles que merece la pena enseñar. Quizá dedique otro artículo a contarlo con más calma y ejemplos.

Geometría virtualizada: qué cambió en rendimiento

La geometría virtualizada es uno de los trabajos que más interés tiene para escenas grandes. La idea, muy simplificada, es dividir los modelos en grupos pequeños y elegir el detalle que necesita la cámara. Los datos más finos pueden llegar por páginas, mientras una representación más sencilla sigue disponible.

Es una implementación propia y más acotada de ideas que Nanite popularizó. Ya incluye selección de detalle, trabajo de visibilidad en la GPU y streaming de geometría y texturas. Quería comprobar qué aportaba dentro de una escena del proyecto, además de ver que el sistema dibujaba.

En una comparación guardada de la base frente al candidato con geometría virtualizada y su streaming, el resumen de tiempo por frame bajó de 29,0 a 17,1 milisegundos. El trabajo de GPU pasó de 22,7 a 12,1 ms. Son aproximadamente un 41 % y un 47 % menos, respectivamente, en ese recorrido. Es una mejora que anima a seguir.

Herramientas conectadas, con la IA como puente

Alrededor del motor estoy construyendo herramientas especializadas: unas sirven para diseñar terreno y ciudades; otras, para crear edificios, vegetación, ropa o animaciones. Human Master se ocupa de los cuerpos y las caras de los personajes. Cada una resuelve una parte del trabajo, pero lo interesante es que puedan compartir sus resultados y construir juntas un mismo mundo.

Por ejemplo, imagina que quiero crear un barrio con calles estrechas y casas en una ladera. La herramienta que dibuja el plano coloca las calles, reparte las parcelas y registra la altura del terreno. La de arquitectura recibe esa información y construye los edificios, ajustando su tamaño y sus apoyos a cada parcela. El motor reúne las piezas para poder recorrer el barrio. Ese es el flujo que busco.

Para conectarlas uso contratos de datos estructurados: acuerdos sobre qué información entrega cada herramienta, qué recibe la siguiente y qué reglas deben respetar ambas. En ese barrio, los datos pueden indicar la anchura de una calle, el límite de una parcela, el número de plantas permitido o la pendiente del terreno. Son parámetros concretos, con unidades y límites, que se pueden leer, cambiar y comprobar.

Ahí entra la IA como puente entre una idea y las herramientas. Un desarrollador puede ajustar esos parámetros directamente; la IA puede interpretar una petición y proponer cambios sobre los mismos datos. Las herramientas comprueban que se respeten sus reglas y el resultado se puede revisar en el motor.

Llamo Studio al conjunto de herramientas de creación que acompaña al motor. Ahí conservo los archivos editables y las instrucciones para generar cada pieza. El motor recibe una versión concreta para usarla en el juego. Así puedo seguir mejorando una casa o un personaje sin perder la versión que estaba funcionando, y aprovechar ese trabajo en otros proyectos.

Algunas conexiones ya funcionan y otras siguen en construcción. Lo que quiero es poder mejorar cada herramienta y hacer que ese avance llegue a las demás, con datos que tanto una persona como la IA puedan entender y ajustar.

Lo siguiente es convertirlo en buenos juegos

Una vez construidas las bases del motor, quiero dar vida a uno o varios juegos que se nutran de estas herramientas. Poder aprovechar lo aprendido al crear ciudades, personajes y animaciones para construir experiencias con una identidad propia.

Mi objetivo es crear mundos vivos donde el sandbox, la acción, las decisiones y el rol definan la experiencia. Poder explorar, improvisar, asumir riesgos y encontrar distintas formas de resolver una situación. Que las decisiones del jugador y la respuesta del mundo abran nuevas posibilidades y den lugar a historias únicas en cada partida.

En este diario iré contando ese camino, desde las pruebas del motor hasta las primeras experiencias jugables.