Juego cooperativo de física en red: LEGO® Viajeros

Fundado en 2020, Light Brick Studio es un equipo independiente centrado en la artesanía y los Insights de los jugadores. Su último lanzamiento, LEGO Voyagers, es una aventura cooperativa sobre dos amigos que persiguen su sueño de convertirse en astronautas. Se lanzó el 15 de septiembre de 2025 en múltiples plataformas. La experiencia se basa en el sonido y la interacción más que en el diálogo, lo que permite a los jugadores sentir la historia a través del juego.

La funcionalidad cooperativa en línea se añadió en una fase avanzada del desarrollo, lo que supuso un reto único para el equipo. Hablamos con Kasper Honnens de Lichtenberg, programador jefe de LEGO Voyagers, y Daniel Zastrow, programador, sobre la adaptación de la cooperación en línea a un proyecto con gran peso de la física.

¿Cuál fue el objetivo principal al desarrollar LEGO Voyagers?

Kasper Honnens de Lichtenberg (KHdL): Nos propusimos crear un juego divertido que evocara emociones y fomentara una sólida experiencia cooperativa.

Daniel Zastrow (DZ): Nuestro objetivo era capturar la esencia del juego LEGO: divertirse con un amigo, sentirse lo más cerca posible de ser un ladrillo LEGO real y embarcarse en una aventura en la que se vive la historia juntos.

¿Qué sistemas fueron los más difíciles de implementar desde el punto de vista técnico?

KHdL: Añadir el modo online a mitad del desarrollo significaba que teníamos que mantener intactos los flujos de trabajo artísticos y de diseño existentes. Creamos herramientas para convertir automáticamente objetos y escenas, de modo que los Teams pudieran seguir creando sin interrupciones.

DZ: Lo más difícil fue conectar el sistema de fijación. Cualquier ladrillo se puede conectar de innumerables maneras, y dos jugadores pueden interactuar simultáneamente. Como no diseñamos el juego para jugar online, reescribí gran parte de la lógica para que el host pudiera validar las acciones mientras los clientes esperaban. También suavicé las transiciones de los accesorios de ladrillo para ocultar la latencia.

¿Cómo ayudó NVIDIA PhysX a mantener sincronizados varios ladrillos LEGO sueltos a través de la red?

DZ: No buscábamos el determinismo perfecto. Cada cliente simulaba la física localmente y, a continuación, empujaba los objetos hacia las actualizaciones de la red para mantener la coherencia visual. Para escenarios FAST como catapultas, la física pura no era fiable, por lo que utilizamos trayectorias deterministas y reactivamos PhysX tras el aterrizaje. Este híbrido conservó la sensación física sin fallos.

¿Cómo optimizó Netcode for GameObjects and Relay su flujo de trabajo de redes?

KHdL: El código de red para GameObjects y Relay nos permite poner en marcha rápidamente el modo cooperativo en línea sin tener que crear una infraestructura de red desde cero. Dado que el juego online se añadió en una fase avanzada del desarrollo, necesitábamos una pila estable que nos permitiera centrarnos en la jugabilidad. La posibilidad de abrir y personalizar el paquete fue crucial, especialmente para acelerar la conversión automática de escenas cuando los flujos de trabajo de las ONG requerían cambios manuales. Esa flexibilidad nos ayudó a corregir errores y resolver problemas en las últimas fases del desarrollo y, en última instancia, a lanzar el juego.

DZ: Los diseñadores podían seguir trabajando sin conexión, y las herramientas automatizadas de conversión de escenas nos permitían evitar obligar a todos a utilizar una única escena compartida. También realizamos algunos ajustes en el flujo de trabajo sin afectar a la estabilidad de la capa de red.

¿Cómo influyeron los objetivos de rendimiento multiplataforma en la implementación de la física y las redes?

KHdL: Dado que LEGO Voyagers depende en gran medida de la física, el rendimiento afectaba directamente a la estabilidad de la red. En Nintendo Switchᵀᴹ, nos propusimos alcanzar los 30 FPS para la física, lo que significó optimizar cuidadosamente todo lo relacionado con ella: colapsar modelos, utilizar recursos y sombras con menos detalle y simplificar características más pesadas como el agua. El horneado de la iluminación y el colapso del modelo eran automáticos, pero se activaban manualmente.

DZ: Desde una perspectiva sistémica, teníamos que asegurarnos de que las cargas de trabajo físicas siguieran siendo predecibles para que las interacciones en red no se vieran afectadas por la carga. Optimizamos los scripts y reescribimos los sistemas más pesados cuando fue necesario, y la paralelización de las operaciones físicas con el sistema de tareas de Unity ayudó significativamente con los casts, los triggers y la señalización. Eso nos dio más margen para mantener la simulación física y las actualizaciones de red con una buena capacidad de respuesta.

KHdL: Analizamos cada escena, hicimos un seguimiento de las caídas de fotogramas y optimizamos hasta que el rendimiento cumplió de forma constante esos objetivos. Alcanzar esos números era esencial, no solo por motivos visuales, sino también para garantizar que la física y la red se mantuvieran sincronizadas y resultaran fiables para los jugadores.

Mirando hacia atrás, ¿qué enfoques de networking cambiarías?

DZ: Habríamos empezado a crear una red de contactos antes. Cuando añadimos el modo online, el juego estaba prácticamente terminado. Los diseñadores habían creado escenas y mecánicas que funcionaban perfectamente en el modo cooperativo local, pero a menudo implementaban las mismas mecánicas de diferentes maneras bajo el capó. Cuando intentamos conectarlos en red, esas inconsistencias se convirtieron en un problema importante, aunque todo pareciera idéntico en el juego.

KHdL: Por ejemplo, teníamos tres scripts de palanca diferentes. Ese tipo de duplicación ocurre de forma natural cuando los diseñadores crean prototipos de jugabilidad en una fase temprana, pero sin una estructura compartida, se generan fricciones más adelante, especialmente en lo que respecta a las redes.

DZ: Sin una refactorización previa, tuvimos que adaptar múltiples versiones de la misma mecánica. Networks put architectural problems into focus: consistency is crucial, or each feature becomes a special case.

KHdL: Habría sido útil contar con una estructura de red ligera desde el principio. Crear nuevas funciones sobre una base compartida hace que las conversiones automáticas y las herramientas sean mucho más eficaces.

DZ: Otro reto fue el propio diseño basado en la física. Nos proporcionó la jugabilidad que queríamos, pero dificultó la conexión en red. Siempre existe tensión entre crear prototipos libremente y fijar las cosas para lograr estabilidad técnica. En retrospectiva, una transición más clara de la experimentación a la estructura habría sido útil.

KHdL: Es una cuestión de equilibrio. Si hubiéramos iniciado esa conversación antes como equipo, nos habríamos ahorrado mucho dolor.

¿Qué TiPs compartirías para gestionar las redes en un juego cooperativo multiplataforma?

DZ: Separar la ejecución de la validación. Permita que los clientes ejecuten acciones, pero mantenga la validación en el host o servidor. Cuando esas responsabilidades se entremezclan, la creación de redes se vuelve mucho más difícil y da lugar a un código frágil y excesivamente complejo. No fuerces el determinismo al 100 % si no lo necesitas. Busca la coherencia que se vea y se sienta bien.

KHdL: También es importante diseñar teniendo en cuenta el contexto de tu juego. LEGO Voyagers es una experiencia cooperativa informal, lo que nos permite ser flexibles. No siempre se requiere una sincronización perfecta.

Para obtener más información sobre los proyectos realizados con Unity, visite la página Recursos.

*Nintendo Switch es una marca comercial de Nintendo.