Cómo Wishfully lanzó «Planet of Lana II» simultáneamente en todas las plataformas

Planet of Lana II es un juego de aventuras y puzles de estilo cinematográfico desarrollado por Wishfully, un estudio Indie sueco fundado en 2018 en Gotemburgo. Ofrecer esa experiencia en PC, Xbox, PlayStation® y Nintendo Switchᵀᴹ, incluyendo el hardware de nueva generación, supone un importante reto técnico.

Nos reunimos con Adam Stjärnljus, codirector del estudio y director creativo; Edvard Rutström, programador sénior; y Mattias Wargren, programador jefe, para analizar cómo unificaron su código base, ampliaron su proceso de compilación y optimizaron el juego para alcanzar los 60 FPS en la mayoría de plataformas, al tiempo que lo lanzaban simultáneamente para PC y consolas.

*Nintendo Switch es una marca comercial de Nintendo.

¿Podrías ofrecernos una visión general de «Planet of Lana II» y de su Scope como proyecto multiplataforma?

Adam Stjärnljus: «Planet of Lana II IIS» parte de la versión original y ofrece aproximadamente el doble de contenido y un Scope más amplio. A diferencia del primer juego, que se lanzó para Xbox y PC antes de que lo adaptáramos a otras plataformas, hemos desarrollado la secuela para un lanzamiento multiplataforma simultáneo en PC, Xbox One y Xbox Series X|S, PlayStation 4 y PlayStation 5, y Nintendo Switch. Lo lanzamos el 5 de marzo de 2026.

Sigue siendo un juego de aventuras y puzles que sigue a Lana y a su compañera Mui en un viaje centrado en la historia que combina puzles, plataformas y sigilo. La mecánica principal del juego se centra en las interacciones cooperativas entre Lana y Mui, mientras que la narrativa amplía el mundo y el conflicto del primer juego.

¿Qué enfoque adoptó el equipo para definir la visión de un lanzamiento simultáneo en varias plataformas, y qué factores determinaron la selección de plataformas?

AS: Abordamos la secuela con una mentalidad centrada en la multiplataforma y nos basamos en la abstracción de plataformas y las herramientas del primer juego. Nuestro objetivo era ejecutar compilaciones continuas en todas las plataformas de destino desde las primeras fases de la producción, para poder probar y optimizar el rendimiento a lo largo del desarrollo, en lugar de dejar ese trabajo para el final.

Seleccionamos las plataformas —PC, Xbox One, PlayStation y Nintendo Switch— basándonos en el éxito del lanzamiento original y en nuestro objetivo de ofrecer un lanzamiento simultáneo en todas ellas. Para ello, fuimos perfeccionando las herramientas y los flujos de trabajo existentes, de modo que todo el equipo pudiera contribuir desde el principio a mejorar el rendimiento, aunque mantener la compatibilidad en todas las plataformas de destino seguía siendo un reto.

¿Cómo permitió vuestra arquitectura técnica llevar a cabo compilaciones y despliegues multiplataforma eficientes sin crear silos de código específicos para cada plataforma?

Mattias Wargren: Evitamos la fragmentación de plataformas utilizando un único proyecto de Unity sin bifurcaciones por plataforma y basándonos en una capa de abstracción de plataforma compartida del primer juego. Resolvimos las diferencias entre plataformas mediante definiciones en tiempo de compilación, sistemas condicionales y herramientas, en lugar de mantener códigos fuente independientes.

También implementamos herramientas de filtrado de contenidos para incluir o excluir recursos según la plataforma, junto con niveles de calidad y detalle diferenciados que podíamos ajustar según el dispositivo. Además de los ajustes integrados de Unity, hemos añadido un sistema de calidad personalizado para ofrecer un mayor control.

AS: Esta configuración permitió a los diseñadores y desarrolladores adaptar el contenido y el rendimiento a cada dispositivo de destino, manteniendo al mismo tiempo todo unificado en un único proceso. Esto permitió que las compilaciones se mantuvieran eficientes y manejables durante toda la fase de producción.

¿Cómo has estructurado el proceso de compilación para permitir la implementación en todas las plataformas y evitar al mismo tiempo los cuellos de botella en la compilación?

Edvard Rutström: Desde el principio dimos prioridad al proceso de compilación, comenzando con una configuración local que utilizaba TeamCity y agentes de compilación dedicados para mantener las compilaciones fuera de los equipos de los desarrolladores y evitar conflictos. En las últimas fases del proyecto, pasamos a una infraestructura alojada por el proveedor con más agentes de compilación, lo que permitió realizar compilaciones nocturnas automatizadas en todas las plataformas y redujo los cuellos de botella.

Además, tuvimos que dar soporte a una demo pública en todas las plataformas, lo que aumentó la complejidad de la compilación y, en la práctica, duplicó el número de compilaciones. Lo gestionamos dentro del mismo repositorio y proyecto utilizando un indicador de compilación para distinguir entre la demo y el juego completo, eliminando el contenido que no formaba parte de la demo en el momento de la compilación. Aunque esto funcionaba bien desde el punto de vista técnico, gestionar el volumen de compilaciones, sobre todo teniendo en cuenta que el departamento de QA necesitaba tanto variantes de depuración como de lanzamiento, se convirtió en una carga considerable.

MW: Hemos diseñado el proceso para que sea portátil. No tuvimos que modificar nuestro código ni nuestros scripts de compilación al migrar la infraestructura, por lo que la transición fue fluida y no afectó al desarrollo.

¿Qué estrategia de integración garantizó la estabilidad mientras se desarrollaban en paralelo múltiples optimizaciones específicas para cada plataforma?

MW: Hemos logrado la estabilidad combinando niveles de calidad compartidos con potentes herramientas de validación. Implementamos modos de calidad adaptados a cada plataforma que podíamos simular directamente en el editor de Unity, lo que permitió a los diseñadores y artistas previsualizar cómo se comportaría el contenido en diferentes dispositivos sin necesidad de crear ramas del proyecto.

También hemos creado herramientas automatizadas para recorrer los puntos de control, capturar capturas de pantalla y superponer métricas de rendimiento. Esto permitió al equipo conocer en todo momento cómo afectaban los cambios a las distintas plataformas de destino y facilitó la realización de iteraciones en paralelo, al tiempo que se mantenía estable el código base.

¿Cómo has estructurado tu flujo de trabajo de recursos para optimizar las compilaciones multiplataforma y reducir la duplicación de recursos?

ER: Hemos dejado de lado un enfoque basado en gran medida en la agrupación de contenidos. Resultó difícil evitar la duplicación de recursos, sobre todo porque reutilizamos el contenido de los biomas en todo el juego, lo que hacía que una separación clara fuera poco práctica.

En su lugar, nos basamos en un proceso de gestión de activos con más control. El audio lo gestionamos mediante bancos aislados en FMOD y los elementos visuales mediante atlas de sprites. Para optimizar el sistema para diferentes niveles de hardware, nos centramos en la simplificación de los recursos y en los límites de tamaño de los atlas, lo que permitió reducir el uso de memoria sin introducir duplicaciones adicionales.

Este enfoque permitió simplificar las compilaciones, al tiempo que garantizaba un comportamiento de carga predecible y un uso estable de la memoria en todos los dispositivos.

¿De qué manera permitieron tus sistemas de juego, que utilizan el Job System de C# y el compilador Burst, la implementación de compilaciones multiplataforma?

ER: Utilizamos el sistema de tareas de Unity C# y el compilador Burst en varios sistemas específicos, principalmente en una simulación de elementos que gestionaba el fuego, el calor y el agua, y en un sistema de deformación de la nieve.

Dado que estos sistemas estaban bien definidos y orientados a los datos, se adaptaban perfectamente a diferentes tipos de hardware sin necesidad de un tratamiento especial. No se produjeron fallos ni condiciones de carrera, por lo que bastó con seguir las prácticas recomendadas habituales del sistema de tareas.

¿Cómo utilizaste los datos de perfilado para definir las configuraciones de compilación y las optimizaciones específicas de cada plataforma?

MW: Nos basamos en el análisis de rendimiento de las versiones de desarrollo en todas las plataformas y utilizamos instantáneas automáticas para identificar los puntos problemáticos de cada nivel. En lugar de optimizar cada plataforma por separado desde el principio, nos centramos en mejoras que beneficiaran a todas las plataformas de destino y, posteriormente, perfeccionamos los puntos críticos específicos cuando fue necesario.

ER: Empezamos con una prueba inicial con especificaciones básicas y nos centramos en los cuellos de botella de la CPU —y, en ocasiones, de la GPU— con optimizaciones que preservaban la calidad visual. Ese trabajo dio sus frutos y nos ayudó a alcanzar los 60 FPS en la mayoría de las plataformas objetivo. También hemos utilizado ampliamente el Profiler para gestionar la carga de recursos y el consumo de memoria.

AS: Era un bucle sin fin. Analizamos el rendimiento, identificamos problemas como las llamadas de dibujo y las caídas de la tasa de fotogramas, optimizamos el código y repetimos el proceso. Con el tiempo, esto dio lugar a un proceso de trabajo en el que los diseñadores identificaban antes las limitaciones de rendimiento, lo que redujo la necesidad de realizar modificaciones en las últimas fases.

¿Cómo configuraste y desarrollaste los sistemas de navegación para garantizar que se implementaran de manera eficiente y funcionaran de forma consistente en múltiples plataformas?

MW: Utilizamos una combinación de volúmenes NavMesh estáticos y dinámicos, lo que permitió equilibrar los datos precalculados con la flexibilidad runtime. Ajustamos los parámetros de navegación para cada plataforma mediante configuraciones de calidad, lo que nos permitió controlar la precisión y el rendimiento en cada dispositivo, al tiempo que mantuvimos un comportamiento uniforme.

En retrospectiva, ¿qué harías de otra manera y qué consejo darías a los equipos que se plantean un lanzamiento simultáneo en varias plataformas?

ER: Una cosa que cambiaríamos es automatizar la creación de parches en el proceso de compilación. Hacerlo manualmente llevaba mucho tiempo y no era escalable.

La conclusión más importante que sacamos es que hay que apostar por la multiplataforma desde el primer día. Compila y prueba el programa en todas las plataformas de destino desde el principio, y no dejes la optimización para el final. También hemos desarrollado una capa de abstracción de la plataforma que agrupa funciones comunes, como el guardado de datos, los logros y la gestión de usuarios, en una única API. Esto permitió mantener las implementaciones aisladas y facilitó la compatibilidad con nuevas plataformas sin afectar al resto del código.

Para obtener más información sobre los proyectos creados con Unity, visita la página de Recursos.