Como a Wishfully lançou Planet of Lana II simultaneamente em plataformas

Planet of Lana II é um jogo de aventura e quebra-cabeça cinematográfico desenvolvido pela Wishfully, um estúdio indie sueco fundado em 2018 em Gotemburgo. Oferecer essa experiência em PC, Xbox, PlayStation® e Nintendo Switchᵀᴹ, incluindo hardware de próxima geração, é um desafio técnico significativo.

Sentamos com o co-chefe do estúdio e diretor criativo Adam Stjärnljus, o programador sênior Edvard Rutström e o programador líder Mattias Wargren para detalhar como unificaram sua base de código, escalaram seu pipeline de construção e otimizaram o jogo para alcançar 60 fps na maioria das plataformas enquanto lançavam simultaneamente em PC e consoles.

*Nintendo Switch é uma marca registrada da Nintendo.

Você pode compartilhar uma visão geral de Planet of Lana II e seu escopo como um projeto multiplataforma?

Adam Stjärnljus: Planet of Lana II se baseia no original com aproximadamente o dobro do conteúdo e um escopo expandido. Diferente do primeiro jogo, que foi lançado no Xbox e PC antes de o portarmos para outras plataformas, desenvolvemos a sequência para um lançamento multiplataforma simultâneo em PC, Xbox One e Xbox Series X|S, PlayStation 4 e PlayStation 5, e sistemas Nintendo Switch. Lançamos em 5 de março de 2026.

Continua sendo um jogo de aventura e quebra-cabeça que segue Lana e seu companheiro Mui em uma jornada guiada pela história que mistura quebra-cabeças, plataformas e furtividade. A jogabilidade central foca nas interações cooperativas entre Lana e Mui, enquanto a narrativa expande o mundo e o conflito do primeiro jogo.

Que abordagem a equipe adotou para definir a visão de um lançamento multiplataforma simultâneo, e quais fatores moldaram a seleção de plataformas?

AS: Abordamos a sequência com uma mentalidade de multiplataforma em primeiro lugar e construímos sobre a abstração de plataforma e ferramentas do primeiro jogo. Nosso objetivo era realizar construções contínuas em todas as plataformas-alvo no início da produção para que pudéssemos testar e refinar o desempenho ao longo do desenvolvimento, em vez de deixar esse trabalho para o final.

Selecionamos a linha de plataformas – PC, Xbox, PlayStation e sistemas Nintendo Switch – com base no sucesso do lançamento original e nosso objetivo de oferecer um lançamento simultâneo em todas as plataformas. Para apoiar isso, iteramos sobre ferramentas e fluxos de trabalho existentes para que toda a equipe pudesse contribuir para melhorias de desempenho desde o início, mesmo que manter a paridade entre todas as plataformas-alvo continuasse desafiador.

Como sua arquitetura técnica suportou builds e deployment multiplataforma eficientes sem criar silos de código específicos de plataforma?

Mattias Wargren: Evitamos a fragmentação de plataforma usando um único projeto Unity sem bifurcações de plataforma e construindo em uma camada de abstração de plataforma compartilhada desde o primeiro jogo. Lidamos com as diferenças de plataforma através de definições em tempo de compilação, sistemas condicionais e ferramentas, em vez de manter bases de código separadas.

Também implementamos ferramentas de filtragem de conteúdo para incluir ou excluir ativos por plataforma, juntamente com níveis de qualidade e detalhe em camadas que podíamos ajustar por dispositivo. Além das configurações integradas do Unity, adicionamos um sistema de qualidade personalizado para maior controle.

AS: Essa configuração permitiu que designers e desenvolvedores ajustassem conteúdo e desempenho por dispositivo alvo, mantendo tudo unificado em um único pipeline. Isso manteve as builds eficientes e gerenciáveis ao longo da produção.

Como você estruturou o pipeline de build para suportar deployment em todas as plataformas enquanto evitava gargalos de build?

Edvard Rutström: Priorizamos o pipeline de build desde o início, começando com uma configuração local usando TeamCity e agentes de build dedicados para manter as builds fora das máquinas dos desenvolvedores e evitar contenda. Nas etapas finais do projeto, mudamos para uma infraestrutura hospedada pelo publisher com mais agentes de build, o que possibilitou builds automáticas noturnas em todas as plataformas e reduziu gargalos.

Também tivemos que suportar uma demonstração pública em todas as plataformas, o que aumentou a complexidade das builds e efetivamente dobrou o número de builds. Lidamos com isso dentro do mesmo repositório e projeto usando uma flag de build para definir demo versus jogo completo, removendo conteúdo não-demo no momento da build. Embora isso tenha funcionado bem tecnicamente, gerenciar o volume de builds, especialmente com QA exigindo variantes de debug e release, tornou-se uma grande sobrecarga.

MW: Projetamos o pipeline para ser portátil. Não precisávamos mudar nossa base de código ou scripts de build quando migramos a infraestrutura, então a transição foi tranquila e não interrompeu o desenvolvimento.

Qual estratégia de integração garantiu estabilidade enquanto múltiplas otimizações específicas de plataforma eram desenvolvidas em paralelo?

MW: Alcançamos estabilidade combinando níveis de qualidade compartilhados com ferramentas de validação robustas. Implementamos modos de qualidade cientes da plataforma que podíamos simular diretamente no Unity Editor, permitindo que designers e artistas visualizassem como o conteúdo se comportaria em diferentes hardwares sem ramificar o projeto.

Também construímos ferramentas automatizadas para passar por pontos de verificação, capturar capturas de tela e sobrepor métricas de desempenho. Isso deu à equipe uma visão contínua de como as mudanças afetavam diferentes plataformas-alvo e tornou possível iterar em paralelo enquanto mantínhamos a base de código estável.

Como você estruturou seu pipeline de ativos para agilizar builds multiplataforma e reduzir a duplicação de ativos?

ER: Abandonamos uma abordagem pesada de agrupamento de conteúdo. Provou-se difícil evitar a duplicação de ativos, especialmente porque reutilizamos conteúdo de bioma em todo o jogo, o que tornava a separação limpa impraticável.

Em vez disso, confiamos em um pipeline de ativos mais controlado. Tratamos áudio através de bancos isolados no FMOD e visuais através de Sprite Atlases. Para otimizar para diferentes níveis de hardware, focamos na remoção de ativos e limites de tamanho de atlas, o que reduziu o uso de memória sem introduzir duplicação adicional.

Essa abordagem manteve os builds mais simples, garantindo um comportamento de carregamento previsível e uso de memória estável em todos os dispositivos.

Como seus sistemas de gameplay usando o C# Job System e o compilador Burst suportaram a implantação de builds multiplataforma?

ER: Usamos o Unity C# Job System e o compilador Burst em alguns sistemas direcionados, principalmente uma simulação elemental que lidava com fogo, calor e água e um sistema de deformação de neve.

Como esses sistemas eram bem definidos e orientados a dados, eles se traduziram de forma limpa em diferentes hardwares sem exigir tratamento especial. Não encontramos falhas ou condições de corrida, então as melhores práticas padrão do Job System foram suficientes.

Como você usou dados de perfil para informar configurações de build e otimizações específicas de plataforma?

MW: Confiamos em perfis durante builds de desenvolvimento em todas as plataformas e usamos snapshots automatizados para identificar áreas problemáticas por nível. Em vez de ajustar cada plataforma independentemente desde o início, focamos em melhorias que beneficiaram todas as plataformas-alvo, e depois refinamos hotspots específicos quando necessário.

ER: Começamos com uma passagem de baseline de baixo especificação e visamos gargalos de CPU, e às vezes gargalos de GPU, com otimizações que preservaram a qualidade visual. Esse trabalho se elevou e nos ajudou a alcançar 60 fps na maioria das plataformas-alvo. Também usamos perfis de memória extensivamente para gerenciar o carregamento de ativos e a pegada de memória.

AS: Foi um ciclo contínuo. Nós perfilamos, identificamos problemas como chamadas de desenho e quedas de taxa de quadros, otimizamos e repetimos. Com o tempo, isso evoluiu para um fluxo de trabalho onde os designers entenderam as restrições de desempenho mais cedo, o que reduziu retrabalho em estágios finais.

Como você configurou e construiu sistemas de navegação para garantir que fossem implantados de forma eficiente e apresentassem desempenho consistente em várias plataformas?

MW: Usamos uma combinação de volumes de NavMesh estáticos e dinâmicos, que equilibraram dados pré-computados com flexibilidade em tempo de execução. Ajustamos as configurações de navegação por plataforma através de configurações de qualidade, o que nos permitiu controlar a precisão e o custo de desempenho por dispositivo, mantendo um comportamento consistente.

No retrospecto, o que você faria diferente e que conselho você daria a equipes que tentam um lançamento multiplataforma simultâneo?

ER: Uma coisa que mudaríamos é automatizar a criação de patches no pipeline de build. Fazê-lo manualmente era demorado e não escalava.

Nossa maior lição é ir multiplataforma desde o primeiro dia. Construa e teste em todas as plataformas-alvo cedo, e não adie a otimização para o final. Também desenvolvemos uma camada de abstração de plataforma que envolve recursos comuns, como salvar dados, conquistas e gerenciamento de usuários, por trás de uma única API. Isso manteve as implementações isoladas e facilitou o suporte a novas plataformas sem afetar o restante da base de código.

Para ler mais sobre projetos feitos com Unity, visite a Página de Recursos.