Entrevista
13 de octubre de 2026
Fuse Games usa UE5 para crear un juego de carreras de Star Wars™ rápido y realista
Desde empuñar espadas láser hasta dominar la Fuerza, Star Wars™ ha inspirado innumerables fantasías infantiles, y sentarte al volante de uno de los vehículos emblemáticos de la franquicia tiene que estar entre las primeras de la lista.
Star Wars: Galactic Racer™ es un juego creado en torno a esta premisa. Te pones en el papel de un piloto en el circuito de carreras rebelde de la galaxia para conducir motos speeder, skim speeders y landspeeders mientras intentas subir puestos en la clasificación y conseguir la pole position.
Sin embargo, esto es más que un simple juego de carreras con los vehículos geniales de Star Wars™. El desarrollador Fuse Games tomó una decisión muy acertada al añadir una función roguelite que te permite trazar tu propio camino por los planetas, eligiendo rutas ramificadas y enfrentándote a sesiones contrarreloj, pruebas de eliminación y carreras por vueltas, todo ello mientras personalizas a tu personaje y mejoras tu vehículo con habilidades que alteran la jugabilidad.
Una vez consolidado el bucle de juego adecuado, el equipo se centró en conseguir que el aspecto fuera tan bueno como la jugabilidad. Ahí es donde entró en juego Unreal Engine 5.
Hablamos con Andrei Shires, cofundador y director de tecnología, y con Karl Wickens, director técnico de arte del estudio en Fuse Games, para que nos cuenten cómo Lumen, Nanite y World Partition liberaron al equipo de la tarea de desarrollo de la tecnología básica para poder centrarse en ofrecer unos gráficos de alta calidad dignos de una galaxia muy, muy lejana.
Star Wars: Galactic Racer™ es un juego creado en torno a esta premisa. Te pones en el papel de un piloto en el circuito de carreras rebelde de la galaxia para conducir motos speeder, skim speeders y landspeeders mientras intentas subir puestos en la clasificación y conseguir la pole position.
Sin embargo, esto es más que un simple juego de carreras con los vehículos geniales de Star Wars™. El desarrollador Fuse Games tomó una decisión muy acertada al añadir una función roguelite que te permite trazar tu propio camino por los planetas, eligiendo rutas ramificadas y enfrentándote a sesiones contrarreloj, pruebas de eliminación y carreras por vueltas, todo ello mientras personalizas a tu personaje y mejoras tu vehículo con habilidades que alteran la jugabilidad.
Una vez consolidado el bucle de juego adecuado, el equipo se centró en conseguir que el aspecto fuera tan bueno como la jugabilidad. Ahí es donde entró en juego Unreal Engine 5.
Hablamos con Andrei Shires, cofundador y director de tecnología, y con Karl Wickens, director técnico de arte del estudio en Fuse Games, para que nos cuenten cómo Lumen, Nanite y World Partition liberaron al equipo de la tarea de desarrollo de la tecnología básica para poder centrarse en ofrecer unos gráficos de alta calidad dignos de una galaxia muy, muy lejana.
P: ¡Gracias por estar con nosotros! ¡El juego tiene una pinta increíble! Contadnos cuáles fueron vuestros objetivos principales para Star Wars: Galactic Racer™ y de qué va el juego.
Andrei Shires, cofundador y jefe de tecnología de Fuse Games: En principio, nuestra labor como equipo técnico es sencilla: garantizar la mejor experiencia posible para el jugador. Todo lo que hacemos gira en torno a eso.
Karl Wickens, director técnico de arte del estudio en Fuse Games: Desde un punto de vista técnico, nuestros principales objetivos eran ofrecer contenido muy realista y una presentación cinematográfica, sin sacrificar la tasa de fotogramas constante ni la fluidez de los controles.
P: ¿Por qué se eligió Unreal Engine 5 para este proyecto y qué funciones de UE5 os llamaron más la atención durante el desarrollo (y por qué)?
Shires: Al principio evaluamos varios motores. Lo más importante era encontrar uno que nos permitiera desarrollar rápidamente con un nivel muy alto y constante para poder centrarnos en crear el juego, no en desarrollar la tecnología básica desde cero. Unreal Engine 5 era claramente la mejor opción en ese sentido, sobre todo por cómo se complementan Nanite, Lumen y World Partition. Esa combinación resultaba tremendamente atractiva para un juego como el nuestro.
Wickens: Sabíamos que tendríamos que ampliar el equipo rápidamente. Por eso, recurrir a un motor ya listo para usar, con unas prácticas recomendadas bien establecidas, facilitó mucho la incorporación de nuevos miembros. También aceleró nuestra propia curva de aprendizaje y nos permitió utilizar herramientas y contenido comprados como punto de partida para nuestros propios recursos específicos del juego.
STAR WARS © & TM 2026 Lucasfilm Ltd. Todos los derechos reservados.
P. Los juegos de carreras ponen de manifiesto cada milisegundo de latencia. ¿Cuáles fueron los mayores retos técnicos a la hora de conseguir que los vehículos respondieran bien a velocidades tan altas?
Shires: Varias cosas. Shires: Para que un juego de carreras resulte coherente y justo, la simulación física tiene que funcionar a la máxima tasa de fotogramas, independientemente de la del juego, y ser lo suficientemente rápida como para gestionar vehículos que circulan —y chocan— a una velocidad extrema. Nos esforzamos mucho para que esa simulación física fuera lo más sólida posible, porque todo lo demás depende de ella: la uniformidad, la equidad, la baja latencia y que el vehículo responda de verdad como esperas que lo haga al tomar una curva.
Wickens: Una cosa que tuvo una importancia enorme —no exactamente la renderización, pero muy relacionado con ella— fue gestionar varias «capas» diferentes de cada nivel al mismo tiempo. Tenemos la malla de renderización, que es principalmente Nanite. También hay una capa de colisión independiente para la simulación de las carreras. Y luego está la escena de Lumen: la geometría 3D que alimenta la GI, además de la escena de campo lejano. A medida que corres por un nivel, hay varias capas de datos activas a la vez: algunas visibles, otras no; unas afectan a la física de la carrera y, otras, a la iluminación. Dedicamos mucho tiempo a ajustar la resolución de cada una de ellas. Probamos qué se percibía realmente si se omitía de la escena de trazado de rayos de Lumen, para alcanzar las tasas de fotogramas que necesitábamos.
STAR WARS © & TM 2026 Lucasfilm Ltd. Todos los derechos reservados.
P: ¿De qué forma ha permitido Nanite al equipo utilizar recursos muy detallados, como vehículos con millones de triángulos, sin dejar de garantizar un rendimiento fluido? Además, ¿qué resultados concretos ha observado el equipo en cuanto a calidad visual y tiempo de producción?
Wickens: Nanite supuso un auténtico cambio de paradigma respecto al antiguo mundo basado en LOD, en el que tenías que seleccionar cuidadosamente a mano el número de triángulos para cada nivel de detalle de un recurso. Con Nanite, proporcionas una única versión fija de alta resolución y dejas que resuelva dinámicamente los triángulos que la escena necesite. El antiguo enfoque de LOD es caro de producir y, como los LOD funcionan en bandas fijas, supone un derroche: hay un punto óptimo en cada banda donde el detalle se ve bien, y un margen a cada lado donde no consigues la calidad que podrías conseguir. Nanite también acabó con el «efecto de salto» que se producía al cambiar de recursos entre bandas de LOD, ya que resuelve el detalle de forma fluida.
Las mejoras en la fidelidad también se notaron en algunos lugares inesperados. A nuestro jefe de contenido todavía le encanta que podamos utilizar directamente los recursos de los vehículos de carreras para imágenes en primer plano de marketing, sin ningún trabajo extra de modelado. Esos mismos recursos funcionaron de maravilla como elementos cinematográficos, y en el modo foto puedes acercarte mucho manteniendo los detalles, sin ninguno de esos artefactos que «saltan» que solían causar los LOD.
El tiempo de producción es un punto interesante. La antigua canalización de LOD se parece un poco a dar el acabado a mano a un mueble. Cada corte cuenta: cada bordeado cíclico tiene que luchar por ganarse su lugar en un presupuesto de triángulos muy reducido. Nanite elimina gran parte de esa sobrecarga técnica. Sigue estando ahí, pero se ha reducido enormemente, lo que permite que en el trabajo participen más artistas y les permite avanzar más rápido.
Shires: Estoy de acuerdo con eso. La mayor diferencia que he visto es el hecho de poder conseguir que un nivel o un vehículo tenga buen aspecto y, al mismo tiempo, funcione a una buena tasa de fotogramas. En la antigua canalización, cuando introducías unas mallas espectaculares, la tasa de fotogramas se iba al traste inmediatamente hasta que se terminaban los LOD, así que veías «cómo era el aspecto del juego» y «la forma de jugar» como dos momentos distintos, con semanas de diferencia.
Con Nanite, teníamos recursos que, a pesar de no estar optimizados en absoluto, se veían bien y funcionaban a una buena tasa de fotogramas desde una fase muy temprana del desarrollo. Para mí, eso es lo que marca la diferencia. No es que el juego se vea mejor, porque creo que podríamos haber conseguido una calidad visual similar también con los LOD, sino lo mucho más rápido que pudimos iterar con esa experiencia y con Fuse. Cuanto más avanzábamos en el ciclo de iteración, mejor se volvía nuestro juego.
Incluso añadimos un modelo de destructor estelar que se había creado para las películas. Unreal Engine nos permitió colocarlo directamente en el nivel, y funcionó sin problemas en la PS5. Eso fue algo muy especial.
STAR WARS © & TM 2026 Lucasfilm Ltd. Todos los derechos reservados.
P: ¿Cómo han ayudado Lumen y la renderización basada en física a crear una iluminación convincente en distintos entornos y momentos del día? ¿Podrías contarnos cómo ha influido esto en los procesos de trabajo de los artistas y en los tiempos de iteración?
Wickens: Lumen nos permitió conseguir muy rápidamente una base de iluminación atractiva, aunque no del todo pulida, y permitió al equipo de iluminación probar diferentes estilos para un nivel en una pasada preliminar antes de darlo por definitivo.
Uno de los resultados más interesantes en cuanto al PBR fue un proceso de trabajo que creamos para tomar muestras de colores del mundo real a partir de nuestro metraje de referencia y convertirlos en colores de referencia físicamente precisos para nuestros recursos. Eso eliminó gran parte de las conjeturas a la hora de elegir los colores de las texturas —conjeturas que varían muchísimo dependiendo del monitor de cada uno, la luminosidad de la habitación o la luz ambiental, ya que no todos los artistas trabajan en un entorno con control de color—.
Lo combinamos con herramientas de validación personalizadas de Unreal Engine que muestran a los artistas dónde se sitúa un color determinado en una escala porcentual (desde muy oscuro y oscuro, pasando por los tonos medios, hasta brillante y muy brillante), además de avisos para cualquier cosa que se salga por completo de ese rango. Muchas veces, los artistas empiezan eligiendo colores que parecen correctos por separado —en Photoshop—, pero que no quedan bien una vez iluminados en el motor. Contar con ese marco PBR uniforme significaba que, tanto si alguien creaba texturas para personajes, vehículos o entornos —muchas veces de forma aislada unos de otros—, todo encajara correctamente una vez iluminado en la escena de Lumen, sin que hubiera diferencias visuales entre ellos.
STAR WARS © & TM 2026 Lucasfilm Ltd. Todos los derechos reservados.
P: ¿Cómo habéis optimizado Unreal Engine para ofrecer tasas de fotogramas constantes y mantener la sensación de velocidad?
Wickens: Creamos una herramienta de validación bastante compleja que convierte nuestras especificaciones técnicas en reglas que se aplican. Fíjate en la densidad de triángulos de Nanite: Nanite acepta sin problemas todos los triángulos que le eches, pero queremos que la densidad sea constante desde el principio, así que calculamos una densidad objetivo por objeto según su tamaño y curvatura.
Cada vez que se realiza un registro, se comprueba que cada recurso cumpla las reglas establecidas para su tipo; luego, se marca todo lo que no pase la prueba y se recopila en paneles de control que abarcan todo el repositorio de contenido. Ese es solo un ejemplo de las más de 250 reglas que tenemos para los distintos tipos de recursos. El sistema nos da la seguridad de que todo lo que llega al juego tiene el nivel de calidad que debe tener.
STAR WARS © & TM 2026 Lucasfilm Ltd. Todos los derechos reservados.
Shires: Además, tenemos procedimientos automatizados que juegan al juego de diferentes maneras y registran un montón de datos. No solo las cifras generales de la tasa de fotogramas o el escalado dinámico de la resolución, sino cada detalle del rendimiento del juego en cada rincón de cada nivel. Eso nos da un ciclo de feedback: si una regla está configurada de una forma demasiado laxa —algo que pasa desapercibido en un solo recurso, pero que causa problemas cuando se multiplica por mil—, podemos volver atrás y ajustarla, y luego repetir el proceso. No teníamos todas las respuestas correctas desde el principio, pero creamos las herramientas que nos permitieron encontrarlas.
También aplicamos esa misma medición a otros sistemas, aparte de al contenido. La sincronización de la física, la latencia de red y la frecuencia de actualización del servidor frente a la del cliente alimentan un segundo conjunto de paneles de control, además de los de contenido. Conseguir esa visibilidad desde el principio, basándonos en Unreal Insights para obtener datos de tendencias a lo largo del tiempo, fue una de las primeras cosas a las que dimos prioridad. Esto significa que, si dos funciones chocan y, al combinarse, provocan un fallo —aunque por separado funcionen bien—, nuestras pruebas automatizadas pueden detectarlo de inmediato.
Wickens: Esas herramientas también han influido en la estructura de los niveles, no solo en los recursos individuales. Esto se debe a lo bien que interactúan Nanite y los LOD jerárquicos: poder ver las resoluciones de World Partition frente a las distancias de transición de los HLOD nos permite ajustar nuestra configuración de streaming. Al final, implementamos radios de streaming variables vinculados a la velocidad del vehículo, de modo que el juego cargue más lejos cuanto más rápido vayas.
También aplicamos esa misma medición a otros sistemas, aparte de al contenido. La sincronización de la física, la latencia de red y la frecuencia de actualización del servidor frente a la del cliente alimentan un segundo conjunto de paneles de control, además de los de contenido. Conseguir esa visibilidad desde el principio, basándonos en Unreal Insights para obtener datos de tendencias a lo largo del tiempo, fue una de las primeras cosas a las que dimos prioridad. Esto significa que, si dos funciones chocan y, al combinarse, provocan un fallo —aunque por separado funcionen bien—, nuestras pruebas automatizadas pueden detectarlo de inmediato.
Wickens: Esas herramientas también han influido en la estructura de los niveles, no solo en los recursos individuales. Esto se debe a lo bien que interactúan Nanite y los LOD jerárquicos: poder ver las resoluciones de World Partition frente a las distancias de transición de los HLOD nos permite ajustar nuestra configuración de streaming. Al final, implementamos radios de streaming variables vinculados a la velocidad del vehículo, de modo que el juego cargue más lejos cuanto más rápido vayas.
STAR WARS © & TM 2026 Lucasfilm Ltd. Todos los derechos reservados.
P: ¿Cómo se asegura el equipo de que haya coherencia visual entre los distintos tipos de hardware?
Shires: Todo se reduce a los mismos principios. Si el juego mantiene la tasa de fotogramas a la resolución adecuada, se verá bien en cualquier plataforma. Unreal Engine gestiona bien la coherencia entre plataformas. Pero las concesiones son inevitables, así que el objetivo es entender qué concesiones elegimos y cuáles surgen por accidente, y asegurarnos de que hacemos concesiones donde hay que hacerlas. Nos hemos esforzado mucho, sobre todo en los PC de gama baja y en la Xbox Series S, así que si pones la Series S y la Series X una al lado de la otra, la diferencia se nota, pero tiene su razón de ser: un hardware mejor tiene sus ventajas.
Durante la mayor parte de la producción, revisábamos las plataformas de destino cada semana. Un director de arte técnico, un director técnico, un ingeniero gráfico y, muchas veces, un artista de iluminación sénior se reunían alrededor de las mismas pantallas para comparar la PlayStation con la Xbox, o las consolas con el PC, analizando a fondo los ajustes específicos de cada plataforma para subsanar cualquier diferencia no intencionada.
Cuando salgan los inevitables vídeos comparativos de YouTube, queremos que los jugadores vean que nos hemos esforzado mucho específicamente en su hardware: que en el hardware menos potente el juego tiene buen aspecto, funciona de maravilla y mantiene la tasa de fotogramas, incluso donde ha habido que hacer concesiones.
Wickens: Exacto, literalmente comparamos dos configuraciones de hardware una al lado de la otra en la misma pantalla de televisión cada semana. También invertimos mucho tiempo, desde muy pronto, en hacer pruebas de juego conjuntas en contexto en lugar de crear contenido de forma aislada y encajarlo a última hora. Eso es una parte importante de nuestra cultura, y algo de lo que hablamos mucho cuando contratamos gente para el equipo.
Hacemos pruebas multijugador y esbozamos los niveles desde el principio, con gente en PlayStation, Xbox, PC de gama alta y PC de menor potencia, todos en la misma sesión, para que los problemas en un hardware específico salgan a la luz rápidamente. Al dar una vuelta por esas sesiones, ves el juego en una docena de pantallas y configuraciones diferentes. Además, las compilaciones automáticas diarias muestran el rendimiento en todas las consolas en un único gráfico, así que podemos confirmar que nuestras decisiones de escalabilidad para el hardware de gama baja se mantienen en cuanto a la tasa de fotogramas y la memoria.
STAR WARS © & TM 2026 Lucasfilm Ltd. Todos los derechos reservados.
P: ¿Cómo se ha integrado el enfoque de desarrollo de Fuse en el proceso de trabajo de UE5 y en sus tecnologías de renderización estrella?
Wickens: Desde el principio nos dimos cuenta de que usar World Partition, HLOD, Lumen y Nanite juntos supone una ventaja real en la producción. Es un ecosistema que funciona muy bien en su conjunto, con una eficiencia que no conseguirías si crearas cualquiera de esos sistemas por separado a medida. Así que nos decantamos por él. Teniendo en cuenta en qué punto del ciclo de vida de UE5 nos encontrábamos, probamos tanto el trazado de rayos por software como por hardware a lo largo de varias iteraciones antes de decidirnos por Lumen con trazado de rayos por hardware.
Shires: Estoy totalmente de acuerdo con todo lo que acaba de decir Karl. Nuestra experiencia previa con motores en los que no éramos dueños de cada línea de código nos enseñó que hay dos formas de trabajar con una herramienta que no controlas del todo: a favor de ella o en su contra. Y si vas en su contra, estás luchando continuamente contra el motor. Saber cómo Epic pretendía que se usara Unreal Engine nos permitió contar con su apoyo. Además, gracias a eso, los desarrolladores que ya habían lanzado juegos antes pudieron incorporarse y entender de inmediato nuestro proceso de trabajo.
Extendimos esa filosofía a toda nuestra cadena de herramientas. Cómo distribuimos el editor internamente, cómo ejecutamos las compilaciones automáticas… todo sigue el método de Epic. Hay una serie estupenda de charlas en las que Epic explica paso a paso su propio procedimiento para crear Fortnite, y gran parte de lo que hacemos se inspira directamente en eso. Si funciona a la escala de Fortnite, es más que suficiente para nosotros. Así que, en lugar de exigir que el motor funcione de una forma concreta, partimos de lo que intentamos resolver y nos preguntamos cómo lo resuelve ya Unreal Engine. Esa mentalidad se aplica en todo el proceso, desde la sincronización del código y el contenido entre todo el equipo, pasando por las canalizaciones que ha mencionado Karl, hasta cómo empaquetamos y lanzamos el juego.
P. Los circuitos recorren lugares emblemáticos de Star Wars™. ¿Cómo ayudaron las herramientas de creación de mundos de Unreal Engine al equipo a crear entornos que parezcan auténticos y, al mismo tiempo, se vean perfectamente incluso a toda velocidad?
Wickens: Las herramientas de pintura de paisajes fueron de gran ayuda para iterar rápidamente a través de los bloqueos y diseños iniciales. Y la generación procedimental de contenido en particular nos permitió definir conjuntos de reglas procedimentales para poblar los niveles: elementos de alta densidad junto al circuito, que se van reduciendo a una densidad procedural menor a medida que nos alejamos. Eso nos permitió crear a mano edificios emblemáticos clave y luego poblar rápidamente los detalles que los rodean.
STAR WARS © & TM 2026 Lucasfilm Ltd. Todos los derechos reservados.
P: ¿Qué importancia ha tenido para vosotros el acceso al código fuente de UE a lo largo del desarrollo?
Shires: Ha sido muy importante. Es lo que nos permite entender no solo lo que debería hacer el motor, sino también cómo lo hace realmente por dentro, para poder crear nuestro contenido de forma que se adapte a él. Sin esa visibilidad, te limitas a adivinar y nunca consigues que ambos encajen del todo. Tener ese acceso a él nos permite sacar más partido al motor, arreglar algún que otro error nosotros mismos y enviar el parche a Epic; y cuando hablamos con los ingenieros del servicio técnico, mantenemos una conversación técnica en profundidad desde la primera frase, en lugar de tener que empezar desde cero.
P: ¡Gracias por vuestro tiempo! ¿Dónde puede ir la gente para obtener más información sobre Star Wars: Galactic Racer™?
Shires: Pueden visitar nuestro sitio web oficial en starwarsgalacticracer.com para saber más del juego. Allí también encontrarán todos los enlaces a nuestras redes sociales y nuestro servidor oficial de Discord del juego.