Comment Wishfully a expédié Planet of Lana II simultanément sur les plateformes

Planet of Lana II est un jeu d'aventure cinématographique de puzzle développé par Wishfully, un studio indépendant suédois fondé en 2018 à Göteborg. Offrir cette expérience sur PC, Xbox, PlayStation® et Nintendo Switchᵀᴹ, y compris sur du matériel de nouvelle génération, représente un défi technique significatif.

Nous nous sommes assis avec le co-directeur du studio et directeur créatif Adam Stjärnljus, le programmeur senior Edvard Rutström et le programmeur principal Mattias Wargren pour expliquer comment ils ont unifié leur code, développé leur pipeline de construction et optimisé le jeu pour atteindre 60 fps sur la plupart des plateformes tout en le lançant simultanément sur PC et consoles.

*Nintendo Switch est une marque déposée de Nintendo.

Pouvez-vous partager un aperçu de Planet of Lana II et de son ampleur en tant que projet multiplateforme ?

Adam Stjärnljus : Planet of Lana II s'appuie sur l'original avec environ le double de contenu et une portée élargie. Contrairement au premier jeu, qui a été lancé sur Xbox et PC avant que nous ne le portons sur d'autres plateformes, nous avons développé la suite pour un lancement multiplateforme simultané sur PC, Xbox One et Xbox Series X|S, PlayStation 4 et PlayStation 5, et les systèmes Nintendo Switch. Nous l'avons lancé le 5 mars 2026.

C'est toujours un jeu d'aventure de puzzle qui suit Lana et son compagnon Mui dans un voyage narratif qui mélange puzzles, plateformes et furtivité. Le gameplay principal se concentre sur les interactions coopératives entre Lana et Mui, tandis que la narration élargit le monde et le conflit du premier jeu.

Quelle approche l'équipe a-t-elle adoptée pour définir la vision d'un lancement multiplateforme simultané, et quels facteurs ont façonné la sélection des plateformes ?

AS : Nous avons abordé la suite avec un état d'esprit multiplateforme en premier et nous avons construit sur l'abstraction de plateforme et les outils du premier jeu. Notre objectif était de réaliser des constructions continues sur toutes les plateformes cibles dès le début de la production afin que nous puissions tester et affiner les performances tout au long du développement au lieu de laisser ce travail jusqu'à la fin.

Nous avons sélectionné la liste des plateformes – PC, Xbox, PlayStation et systèmes Nintendo Switch – en fonction du succès de la sortie originale et de notre objectif de fournir un lancement simultané sur toutes les plateformes. Pour soutenir cela, nous avons itéré sur les outils et les flux de travail existants afin que toute l'équipe puisse contribuer aux améliorations de performance dès le début, même si le maintien de la parité sur toutes les plateformes cibles restait un défi.

Comment votre architecture technique a-t-elle soutenu des builds multiplateformes efficaces et le déploiement sans créer de silos de code spécifiques à chaque plateforme ?

Mattias Wargren : Nous avons évité la fragmentation des plateformes en utilisant un seul projet Unity sans forks de plateforme et en construisant sur une couche d'abstraction de plateforme partagée depuis le premier jeu. Nous avons géré les différences entre les plateformes grâce à des définitions à la compilation, des systèmes conditionnels et des outils au lieu de maintenir des bases de code séparées.

Nous avons également mis en œuvre des outils de filtrage de contenu pour inclure ou exclure des actifs par plateforme, ainsi que des niveaux de qualité et de détail hiérarchisés que nous pouvions ajuster par appareil. En plus des paramètres intégrés de Unity, nous avons ajouté un système de qualité personnalisé pour un meilleur contrôle.

AS : Cette configuration a permis aux concepteurs et aux développeurs d'ajuster le contenu et les performances par appareil cible tout en gardant tout unifié dans un seul pipeline. Cela a maintenu les builds efficaces et gérables tout au long de la production.

Comment avez-vous structuré le pipeline de build pour soutenir le déploiement sur toutes les plateformes tout en évitant les goulets d'étranglement de build ?

Edvard Rutström : Nous avons donné la priorité au pipeline de build dès le début, en commençant par une configuration sur site utilisant TeamCity et des agents de build dédiés pour garder les builds hors des machines des développeurs et éviter les conflits. À la fin du projet, nous sommes passés à une infrastructure hébergée par l'éditeur avec plus d'agents de build, ce qui a permis des builds nocturnes automatisés sur toutes les plateformes et a réduit les goulets d'étranglement.

Nous avons également dû soutenir une démo publique sur toutes les plateformes, ce qui a augmenté la complexité des builds et a effectivement doublé le nombre de builds. Nous avons géré cela dans le même dépôt et projet en utilisant un drapeau de build pour définir la démo par rapport au jeu complet, en supprimant le contenu non démo au moment de la construction. Bien que cela ait bien fonctionné techniquement, la gestion du volume de builds, en particulier avec l'assurance qualité nécessitant à la fois des variantes de débogage et de version finale, est devenue une charge importante.

MW : Nous avons conçu le pipeline pour qu'il soit portable. Nous n'avons pas eu besoin de modifier notre base de code ou nos scripts de build lorsque nous avons migré l'infrastructure, donc la transition a été transparente et n'a pas perturbé le développement.

Quelle stratégie d'intégration a assuré la stabilité pendant que plusieurs optimisations spécifiques à la plateforme étaient développées en parallèle ?

MW : Nous avons atteint la stabilité en combinant des niveaux de qualité partagés avec de puissants outils de validation. Nous avons mis en œuvre des modes de qualité sensibles à la plateforme que nous pouvions simuler directement dans l'éditeur Unity, ce qui a permis aux concepteurs et aux artistes de prévisualiser comment le contenu se comporterait sur différents matériels sans créer de branches dans le projet.

Nous avons également construit des outils automatisés pour passer par des points de contrôle, capturer des captures d'écran et superposer des métriques de performance. Cela a donné à l'équipe un aperçu continu de la manière dont les changements affectaient différentes plateformes cibles et a rendu possible l'itération en parallèle tout en maintenant la base de code stable.

Comment avez-vous structuré votre pipeline d'actifs pour rationaliser les constructions multiplateformes et réduire la duplication des actifs ?

ER: Nous nous sommes éloignés d'une approche lourde de regroupement de contenu. Il s'est avéré difficile d'éviter la duplication des actifs, surtout puisque nous avons réutilisé le contenu des biomes à travers le jeu, ce qui a rendu une séparation propre impraticable.

Au lieu de cela, nous avons compté sur un pipeline d'actifs plus contrôlé. Nous avons géré l'audio à travers des banques isolées dans FMOD et les visuels à travers des atlas de sprites. Pour optimiser pour différents niveaux de matériel, nous nous sommes concentrés sur le stripping des actifs et les limites de taille des atlas, ce qui a réduit l'utilisation de la mémoire sans introduire de duplication supplémentaire.

Cette approche a gardé les constructions plus simples tout en assurant un comportement de chargement prévisible et une utilisation stable de la mémoire sur les appareils.

Comment vos systèmes de gameplay utilisant le système de tâches C# et le compilateur Burst ont-ils soutenu le déploiement de constructions multiplateformes ?

ER: Nous avons utilisé le système de tâches C# de Unity et le compilateur Burst dans quelques systèmes ciblés, principalement une simulation élémentaire qui gérait le feu, la chaleur et l'eau, ainsi qu'un système de déformation de la neige.

Étant donné que ces systèmes étaient bien définis et orientés données, ils se traduisaient proprement sur différents matériels sans nécessiter de traitement spécial. Nous n'avons pas rencontré de plantages ni de conditions de concurrence, donc les meilleures pratiques standard du système de tâches étaient suffisantes.

Comment avez-vous utilisé les données de profilage pour informer les configurations de build et les optimisations spécifiques à chaque plateforme ?

MW : Nous nous sommes appuyés sur le profilage lors des builds de développement sur toutes les plateformes et avons utilisé des instantanés automatisés pour identifier les zones problématiques par niveau. Au lieu de régler chaque plateforme indépendamment dès le départ, nous nous sommes concentrés sur des améliorations qui bénéficiaient à toutes les plateformes cibles, puis avons affiné les points chauds spécifiques lorsque cela était nécessaire.

ER: Nous avons commencé avec un passage de base à faible spécification et ciblé les goulets d'étranglement CPU, et parfois les goulets d'étranglement GPU, avec des optimisations qui préservaient la qualité visuelle. Ce travail a porté ses fruits et nous a aidés à atteindre 60 fps sur la plupart des plateformes cibles. Nous avons également utilisé le profilage de la mémoire de manière extensive pour gérer le chargement des ressources et l'empreinte mémoire.

AS : C'était une boucle continue. Nous avons profilé, identifié des problèmes tels que les appels de dessin et les chutes de fréquence d'images, optimisé et répété. Au fil du temps, cela a évolué en un flux de travail où les concepteurs comprenaient plus tôt les contraintes de performance, ce qui a réduit le retravail tardif.

Comment avez-vous configuré et construit des systèmes de navigation pour garantir qu'ils se déploient efficacement et fonctionnent de manière cohérente sur plusieurs plateformes ?

MW : Nous avons utilisé une combinaison de volumes NavMesh statiques et dynamiques, qui équilibrent les données précalculées avec la flexibilité d'exécution. Nous avons ajusté les paramètres de navigation par plateforme grâce à des configurations de qualité, ce qui nous a permis de contrôler la précision et le coût de performance par appareil tout en maintenant un comportement cohérent.

Avec le recul, que feriez-vous différemment, et quel conseil donneriez-vous aux équipes tentant un lancement multiplateforme simultané ?

ER: Une chose que nous changerions est l'automatisation de la création de patchs dans le pipeline de build. Le faire manuellement était chronophage et ne se prêtait pas à l'échelle.

Notre plus grande leçon est de passer au multiplateforme dès le premier jour. Construisez et testez sur toutes les plateformes cibles dès le début, et ne reportez pas l'optimisation à la fin. Nous avons également développé une couche d'abstraction de plateforme qui encapsule des fonctionnalités communes telles que la sauvegarde de données, les réalisations et la gestion des utilisateurs derrière une API unique. Cela a maintenu les implémentations isolées et a facilité le support de nouvelles plateformes sans affecter le reste de la base de code.

Pour en savoir plus sur les projets réalisés avec Unity, visitez la page des ressources.