Networking a physics co-op game: LEGO® Voyagers

Fundada em 2020, a Light Brick Studio é uma equipe independente focada em artesanato e compreensão do jogador. Seu último lançamento, LEGO Voyagers, é uma aventura cooperativa sobre dois amigos que buscam o sonho de se tornarem astronautas. Foi lançado em 15 de setembro de 2025 em várias plataformas. A experiência depende do som e da interação, em vez de diálogos, permitindo que os jogadores sintam a história através do jogo.

A funcionalidade cooperativa online foi adicionada no final do desenvolvimento, o que criou desafios únicos para a equipe. Conversamos com Kasper Honnens de Lichtenberg, programador chefe de LEGO Voyagers, e Daniel Zastrow, programador, sobre a adaptação do modo cooperativo online em um projeto com forte ênfase em física.

Qual era o objetivo principal durante o desenvolvimento LEGO Voyagers?

Kasper Honnens de Lichtenberg (KHdL): Queríamos criar um jogo divertido que evocasse emoção e apoiasse uma forte experiência cooperativa.

Daniel Zastrow (DZ):Nosso objetivo era capturar a essência do jogo LEGO – se divertir com um amigo, sentir-se o mais próximo possível de ser um tijolo LEGO real e embarcar em uma aventura onde você vivencia a história juntos.

Quais sistemas foram os mais tecnicamente desafiadores de implementar?

KHdL: Adicionar o jogo online no meio do desenvolvimento significou que precisávamos manter os fluxos de trabalho de arte e design existentes intactos. Criamos ferramentas para converter automaticamente objetos e cenas para que as equipes pudessem continuar criando sem interrupções.

DZ: A rede do sistema de anexação foi a mais difícil. Qualquer tijolo pode se conectar de inúmeras maneiras e dois jogadores podem interagir simultaneamente. Como não desenvolvemos o jogo para jogar online, reescrevi grande parte da lógica para que o host pudesse validar ações enquanto os clientes aguardavam. Eu também suavizei as transições de anexação de tijolos para esconder a latência.

Como o Netcode for GameObjects ajudou a manter vários tijolos LEGO soltos sincronizados na rede?

DZ: Não perseguimos um determinismo perfeito. Cada cliente simulava a física localmente e, em seguida, ajustava os objetos em relação às atualizações de rede para manter a coerência visual. Para cenários rápidos como catapultas, a física pura não era confiável, então usamos trajetórias determinísticas e reativamos o PhysX após o pouso. Este híbrido manteve a sensação física sem falhas.

Como o Netcode for GameObjects e o Relay simplificaram seu fluxo de trabalho de rede?

KHdL: O Netcode for GameObjects e o Relay nos permitem colocar o modo cooperativo online em funcionamento rapidamente, sem a necessidade de construir uma infraestrutura de rede do zero. Como o modo online foi adicionado tardiamente no desenvolvimento, precisávamos de uma pilha estável que nos permitisse focar na jogabilidade. Ser capaz de abrir e personalizar o pacote foi crucial, especialmente para acelerar a conversão automática de cenas quando os fluxos de trabalho do NGO assumiam mudanças manuais. Essa flexibilidade nos ajudou a corrigir bugs e resolver problemas no final do desenvolvimento e, em última análise, a lançar o jogo.

DZ: Os designers podiam continuar trabalhando offline, e as ferramentas de conversão automática de cenas nos permitiram evitar forçar todos a uma única cena compartilhada. Também fizemos algumas alterações no fluxo de trabalho sem afetar a estabilidade da camada de rede.

Como os objetivos de desempenho multiplataforma moldaram sua implementação de física e rede?

KHdL: Como LEGO Voyagers depende tanto da física, o desempenho afetava diretamente a estabilidade da rede. No Nintendo Switchᵀᴹ, nosso alvo era de 30 fps para a física, o que significava otimizar cuidadosamente tudo ao seu redor: reduzir modelos, usar ativos e sombras com menos detalhes e simplificar recursos mais pesados como a água. A iluminação e o colapso do modelo eram automáticos, mas acionados manualmente.

DZ: Do ponto de vista dos sistemas, tivemos que garantir que as cargas de trabalho de física permanecessem previsíveis para que as interações em rede não se degradassem sob carga. Otimizamos os scripts e reescrevemos os sistemas mais pesados quando necessário, e a paralelização das operações de física com o Sistema de Tarefas do Unity ajudou significativamente com lançamentos, gatilhos e sinalização. Isso nos deu mais espaço para manter a simulação de física e as atualizações de rede responsivas.

KHdL: Analisamos cada cena, rastreamos quedas de quadros e otimizamos até que o desempenho atendesse consistentemente esses objetivos. Alcançar esses números era essencial – não apenas para os visuais, mas para garantir que a física e a rede permanecessem sincronizadas e parecessem confiáveis para os jogadores.

Olhando para trás, quais abordagens de rede você mudaria?

DZ: Teríamos começado a rede mais cedo. Quando adicionamos o jogo online, o jogo já estava essencialmente terminado. Os designers criaram cenas e mecânicas que funcionavam perfeitamente em cooperativo local, mas muitas vezes implementaram as mesmas mecânicas de maneiras diferentes por baixo dos panos. Quando tentamos conectá-los em rede, essas inconsistências se tornaram um grande problema – mesmo que tudo parecesse idêntico no jogo.

KHdL: Por exemplo, tínhamos três scripts de alavanca diferentes. Esse tipo de duplicação acontece naturalmente quando os designers prototipavam a jogabilidade cedo, mas, sem uma estrutura compartilhada, isso cria atrito mais tarde, especialmente para a rede.

DZ: Sem a refatoração antecipada, tivemos que adaptar várias versões da mesma mecânica. A rede expõe problemas arquitetônicos – a consistência é crucial, ou cada recurso se torna um caso especial.

KHdL: Ter uma estrutura de rede leve desde o início teria ajudado. Construir novos recursos em cima de uma base compartilhada torna as conversões e ferramentas automáticas muito mais eficazes.

DZ: Outro desafio foi o próprio design orientado por física. Isso nos deu a jogabilidade que queríamos, mas dificultou a rede. Há sempre uma tensão entre prototipar livremente e definir as coisas para garantir a estabilidade técnica. Olhando para trás, uma transição mais clara da experimentação para a estrutura teria ajudado.

KHdL: É um equilíbrio. Iniciar essa conversa mais cedo como equipe teria evitado muita dor de cabeça.

Que dicas você compartilharia para lidar com a rede em um jogo cooperativo multiplataforma?

DZ: Separe a execução da validação. Deixe os clientes executar ações, mas mantenha a validação no host ou no servidor. Quando essas responsabilidades estão emaranhadas, a rede fica muito mais difícil e leva a um código frágil e excessivamente complexo. Não force o determinismo de 100% se você não precisar. Busque a consistência que pareça e se comporte corretamente.

KHdL: Também é importante projetar de acordo com o contexto do seu jogo. LEGO Voyagers é uma experiência cooperativa casual, o que nos permite sermos flexíveis. A sincronização perfeita nem sempre é necessária.

Para saber mais sobre projetos feitos com Unity, visite o Página de recursos.

*Nintendo Switch é uma marca comercial da Nintendo.