Devlog #5 · Replicação

Com espaço e interesse funcionando, veio a camada que transforma mudanças do estado do mundo em dados para os clientes: a replicação.

O servidor precisa saber o que mudou, decidir o que cada jogador precisa receber, compactar no menor formato possível e enviar com prioridade correta — tudo dentro do orçamento de um tick.

Por componente, não por entidade

A replicação funciona por componente, não por entidade inteira. Posição muda todo tick. HP muda em combate. Aparência raramente muda. Cada tipo de dado tem prioridade e cadência próprias.

Dirty bits marcam o que mudou desde o último envio. A fila de replicação prioriza por distância e relevância: primeiro quem está perto, depois quem está em combate, depois o resto. Keyframes garantem que um cliente novo receba o estado completo antes de começar a receber deltas.

Quantização e deltas

Posições são quantizadas para caber em menos bytes. Após o baseline inicial — "aqui está essa entidade, estado completo" — só deltas são enviados: "posição mudou, HP caiu". Isso reduz volume de forma drástica em mundos com muitos objetos em movimento.

Canais separados para cada tipo de dado: crítico, movimento, estado médio, dados lentos, ambientação distante. Se uma fila enche, o sistema sabe o que pode atrasar e o que não pode.

Bench / validação
— Marcar componente sujo: p50 0.55 ns por chamada
— Construção do plano de replicação: p50 435 µs
— Encode de posição: 4 ns por entidade
— 5 canais com prioridade e comportamento distintos
— replication_framing_errors_total = 0 no soak de 1h

Próximo: transporte de rede — o canal que leva esses dados até o cliente.