Como corrigir o Player Location Desync no UEFN e Unreal Engine Multiplayer

O Pesadelo do Multiplayer Transform Desync

Todo desenvolvedor de jogos multiplayer acaba enfrentando o momento em que seu netcode começa a mentir. Você cria uma sequência onde um jogador se senta em uma cadeira, a cadeira se move pelo mapa e tudo parece perfeito no servidor. Mas quando você abre um segundo cliente, a ilusão desaparece. O Cliente A se vê sentado perfeitamente. O Cliente B vê a cadeira se movendo enquanto o Cliente A flutua congelado no ar no ponto de partida.

Este fenômeno específico — o uefn player location desync — é um problema recorrente ao usar inputs de jogador para disparar comandos MoveTo em props que possuem jogadores vinculados (attached). O servidor registra a localização absoluta correta, mas os simulated proxies (as representações do jogador em outros clientes) falham ao herdar o transform atualizado de seu prop pai.

Seja criando no Unreal Editor for Fortnite (UEFN) ou arquitetando um dedicated server no Unreal Engine 5, entender por que a replication de attachments falha é crítico. Neste tutorial, vamos analisar a Network Dormancy, por que attachments quebram a client-side prediction e como forçar o replication graph a respeitar o estado do seu mundo.

Por que Attachments quebram as Network Updates

Para corrigir o desync, você precisa entender como o Unreal Engine lida com actor replication hierarquicamente.

Quando um character actor se anexa a um prop, seu transform torna-se relativo ao actor pai. Para economizar largura de banda, o Unreal Engine utiliza agressivamente o conceito de Network Dormancy.

Quando um jogador se senta e para de enviar input de movimento, o servidor pode marcar o player actor como dormant (latente). O servidor assume: "O jogador não está se movendo de forma independente, então não preciso enviar atualizações para ele. Enviarei apenas para a cadeira."

A Matemática por trás do Desync

• Server Tick Rate: Geralmente 30Hz no UEFN.
• Prop NetUpdateFrequency: Frequentemente 100 atualizações por segundo.
• Character MinNetUpdateFrequency: Pode cair para 2.0 sem input.

Ao chamar MoveTo, a cadeira atualiza a 30Hz. Mas como o jogador está dormant, os outros clientes nunca recebem o RPC (Remote Procedure Call) para atualizar a posição relativa. O resultado é um desync visual massivo.

Passo 1: O Workaround no UEFN Verse

Sair da cadeira resolve o problema porque mudar o movement mode de Custom para Walking força o servidor a limpar (flush) a Network Dormancy.

Podemos recriar esse "flush" no Verse com um micro-teleporte para acordar o replication graph.

# [Código Verse igual ao original]

Ao usar TeleportTo nas mesmas coordenadas, enganamos o motor C++ para disparar a flag TeleportPhysics, resetando a client-side prediction.

Passo 2: Fix Nativo no Unreal Engine C++

Se você tem acesso ao código-fonte, pode usar a API de networking para gerenciar a dormancy diretamente.

// Exemplo C++
// [Código C++ igual ao original]

Passo 3: Persistência no Backend

Garanta que as coordenadas server-authoritative sejam salvas no banco de dados após um forced net update. Criar um backend para saves de alta frequência leva semanas. O horizOn oferece um Backend-as-a-Service pronto para desenvolvedores de jogos.

5 Melhores Práticas

1. Nunca confie no estado de attachment do cliente: Use RPCs server-authoritative.
2. Gerencie NetDormancy manualmente: Use FlushNetDormancy em movimentos ativos.
3. Hierarquias simples: Evite anexos com muitos níveis.
4. RPCs confiáveis para mudanças críticas: Use NetMulticast para montar/desmontar.
5. Valide transforms ao sair: Verifique a posição no servidor ao desmontar.

Conclusão

Desyncs multijogador resultam de otimizações agressivas. Ao entender a Network Dormancy, você pode forçar atualizações via Verse ou C++. Assuma o controle do seu replication graph.

Quer escalar seu backend? Teste o horizOn gratuitamente.