How Wishfully shipped Planet of Lana II simultaneously across platforms

Planet of Lana II is a cinematic puzzle-adventure developed by Wishfully, a Swedish indie studio founded in 2018 in Gothenburg. Delivering that experience across PC, Xbox, PlayStation®, and Nintendo Switchᵀᴹ, including next-gen hardware, is a significant technical challenge.

We sat down with co-head of studio and creative director Adam Stjärnljus, senior programmer Edvard Rutström, and lead programmer Mattias Wargren to break down how they unified their codebase, scaled their build pipeline, and optimized the game to reach 60 fps on most platforms while shipping simultaneously across PC and consoles.

*Nintendo Switch is a trademark of Nintendo.

Can you share an overview of Planet of Lana II and its scope as a multiplatform project?

Adam Stjärnljus: Planet of Lana II builds on the original with roughly double the content and an expanded scope. Unlike the first game, which launched on Xbox and PC before we ported it to other platforms, we developed the sequel for a simultaneous multiplatform release across PC, Xbox One and Xbox Series X|S, PlayStation 4 and PlayStation 5, and Nintendo Switch systems. We launched it on March 5, 2026.

It remains a puzzle-adventure game that follows Lana and her companion Mui on a story-driven journey that blends puzzles, platforming, and stealth. The core gameplay focuses on cooperative interactions between Lana and Mui, while the narrative expands the world and conflict from the first game.

What approach did the team take to define the vision for a simultaneous multiplatform launch, and what factors shaped the platform lineup?

AS: We approached the sequel with a multiplatform-first mindset and built on the platform abstraction and tools from the first game. Our goal was to run continuous builds on all target platforms early in production so we could test and refine performance throughout development instead of leaving that work until the end.

We selected the platform lineup – PC, Xbox, PlayStation, and Nintendo Switch systems – based on the success of the original release and our goal of delivering a simultaneous launch across all platforms. To support this, we iterated on existing tools and workflows so the entire team could contribute to performance improvements early, even though maintaining parity across all target platforms remained challenging.

How did your technical architecture support efficient multiplatform builds and deployment without creating platform-specific code silos?

Mattias Wargren: We avoided platform fragmentation by using a single Unity project with no platform forks and building on a shared platform abstraction layer from the first game. We handled platform differences through compile-time defines, conditional systems, and tools instead of maintaining separate codebases.

We also implemented content-filtering tools to include or exclude assets per platform, along with tiered quality and detail levels that we could tune per device. On top of Unity’s built-in settings, we added a custom quality system for greater control.

AS: This setup allowed designers and developers to adjust content and performance per target device while keeping everything unified in a single pipeline. This kept builds efficient and manageable throughout production.

How did you structure the build pipeline to support deployment across all platforms while avoiding build bottlenecks?

Edvard Rutström: We prioritized the build pipeline early, starting with an on-premises setup using TeamCity and dedicated build agents to keep builds off developer machines and avoid contention. At the late stages of the project, we moved to a publisher-hosted infrastructure with more build agents, which enabled automated nightly builds across all platforms and reduced bottlenecks.

We also had to support a public demo across all platforms, which increased build complexity and effectively doubled the number of builds. We handled this within the same repository and project using a build flag to define demo versus full game, stripping out non-demo content at build time. While this worked well technically, managing the volume of builds, especially with QA requiring both debug and release variants, became a major overhead.

MW: We designed the pipeline to be portable. We did not need to change our codebase or build scripts when we migrated infrastructure, so the transition was seamless and did not disrupt development.

What integration strategy ensured stability while multiple platform-specific optimizations were developed in parallel?

MW: We achieved stability by combining shared quality tiers with strong validation tools. We implemented platform-aware quality modes that we could simulate directly in the Unity Editor, which allowed designers and artists to preview how content would behave on different hardware without branching the project.

We also built automated tools to step through checkpoints, capture screenshots, and overlay performance metrics. This gave the team continuous insight into how changes affected different target platforms and made it possible to iterate in parallel while keeping the codebase stable.

How did you structure your asset pipeline to streamline multiplatform builds and reduce asset duplication?

ER: We moved away from a content-bundling-heavy approach. It proved difficult to avoid asset duplication, especially since we reused biome content across the game, which made clean separation impractical.

Instead, we relied on a more controlled asset pipeline. We handled audio through isolated banks in FMOD and visuals through Sprite Atlases. To optimize for different hardware tiers, we focused on asset stripping and atlas size limits, which reduced memory usage without introducing additional duplication.

This approach kept builds simpler while ensuring predictable loading behavior and stable memory usage across devices.

How did your gameplay systems using the C# Job System and Burst compiler support multiplatform build deployment?

ER: We used the Unity C# Job System and Burst compiler in a few targeted systems, primarily an elemental simulation that handled fire, heat, and water and a snow deformation system.

Since these systems were well scoped and data-oriented, they translated cleanly across different hardware without requiring special handling. We did not encounter crashes or race conditions, so standard Job System best practices were sufficient.

How did you use profiling data to inform build configurations and platform-specific optimizations?

MW: We relied on profiling across development builds on all platforms and used automated snapshots to identify problem areas per level. Instead of tuning each platform independently from the start, we focused on improvements that benefited all target platforms, then refined specific hotspots when needed.

ER: We began with a low-spec baseline pass and targeted CPU bottlenecks, and sometimes GPU bottlenecks, with optimizations that preserved visual quality. That work carried upward and helped us reach 60 fps on most target platforms. We also used memory profiling extensively to manage asset loading and memory footprint.

AS: It was a continuous loop. We profiled, identified issues such as draw calls and framerate drops, optimized, and repeated. Over time, this evolved into a workflow where designers understood performance constraints earlier, which reduced late stage rework.

How did you configure and build navigation systems to ensure they deployed efficiently and performed consistently across multiple platforms?

MW: We used a combination of static and dynamic NavMesh volumes, which balanced precomputed data with runtime flexibility. We adjusted navigation settings per platform through quality configurations, which allowed us to control precision and performance cost per device while maintaining consistent behavior.

In hindsight, what would you do differently, and what advice would you give to teams attempting a simultaneous multiplatform launch?

ER: One thing we would change is automating patch creation in the build pipeline. Doing it manually was time-consuming and did not scale.

Our biggest takeaway is to go multiplatform from day one. Build and test on all target platforms early, and do not defer optimization to the end. We also developed a platform abstraction layer that wraps common features such as save data, achievements, and user handling behind a single API. This kept implementations isolated and made it easier to support new platforms without affecting the rest of the codebase.

To read more about projects made with Unity, visit the Resources page.