Esta página ainda não foi traduzida: mostrando a versão em inglês.

Prediction & Lag Compensation

Predição para a frente e compensação para trás, sobre dados que carregam o momento real do evento. O cliente responde na hora, o servidor continua certo, e os acertos são julgados na linha do tempo do atirador.

Quando usar

• O input precisa parecer instantâneo mesmo com latência, e o servidor continua autoritativo: prevê para a frente e reconcilia quando diverge.
• Os acertos precisam ser julgados na linha do tempo do atirador: ResolveAt retrocede as hitboxes até o tick de visualização informado.
• Arcos de mira e marcadores de impacto precisam bater com o resultado: cliente e servidor calculam a mesma Trajectory.
• Campos críticos para o jogo nunca podem sofrer rollback: declare o que é previsto e o que espera o servidor.
• O rubber banding precisa de ajuste: janelas por entidade, tolerâncias e telemetria de erros de predição.
• Dispensável quando a latência não atrapalha. Jogos por turnos ou lentos funcionam bem só com os deltas do Data & Subscriptions.

Quem faz o quê

Resumo

A palavra cobre três mecanismos distintos, com autoridades e modos de falha diferentes, e cada um tem o seu próprio artigo:

Quatro presets, e “no prediction” é um deles.

Jogos por turnos, de estratégia e a maioria dos títulos para celular não querem predição nenhuma; ao declarar “no prediction”, você diz ao cliente que mostre o estado como ele é, sem adivinhar.

O módulo não tem modelo de movimento, tabela de reações, geometria nem janela de histórico próprios. Eles pertencem, respectivamente, a Locomotion, Collision, Map e Entity. A predição os aplica antes ou os lê de trás para a frente; nunca declara uma segunda cópia.

[Entity("tank")]
[Prediction(ForwardTicks = 8, MaxRewindTicks = 64)]
public class Tank
{
    [Sync, Predicted] public Vector3 Position;                        // rolls back and replays
    [Sync, Predicted] public Vector3 Velocity;

    [Stat(Max = 100), AuthoritativeOnly] public Stat Hp;   // never predicted
}

@Entity('tank')
@Prediction({ forwardTicks: 8, maxRewindTicks: 64 })
export class Tank {
  @Sync() @Predicted() position!: Vector3;                    // rolls back and replays
  @Sync() @Predicted() velocity!: Vector3;

  @Stat({ max: 100 }) @AuthoritativeOnly() hp: Stat;   // never predicted
}

@entity("tank")
@prediction(forward_ticks=8, max_rewind_ticks=64)
class Tank:
    position: Vector3 = sync(predicted=True)                  # rolls back and replays
    velocity: Vector3 = sync(predicted=True)

    hp = stat(max=100, authoritative_only=True)   # never predicted

UCLASS(PSEntity = "tank", PSPrediction = (ForwardTicks = 8, MaxRewindTicks = 64))
class UTank : public UObject
{
    GENERATED_BODY()

    UPROPERTY(PSSync = (Predicted = "true")) FVector3f Position;   // rolls back and replays
    UPROPERTY(PSSync = (Predicted = "true")) FVector3f Velocity;

    UPROPERTY(PSStat = (Max = 100, AuthoritativeOnly = "true")) FPSStat Hp;   // never predicted
};
// declarations compile into the same pushed model — playserv push from the UE project or CI

[Entity("tank")]
[Prediction(ForwardTicks = 8, MaxRewindTicks = 64)]
public class Tank
{
    [Sync, Predicted] public Vector3 Position;                        // rolls back and replays
    [Sync, Predicted] public Vector3 Velocity;

    [Stat(Max = 100), AuthoritativeOnly] public Stat Hp;   // never predicted
}

A resolução com compensação de lag responde “onde estava todo mundo quando este tiro foi disparado”:

[After(Projectiles.HitReported)]
public static void Validate(HitReport hit) =>
    hit.ResolveAt(hit.ShooterViewTick);    // rewinds hitboxes, sub-tick interpolated

export const validate = after(Projectiles.hitReported, (hit: HitReport) =>
  hit.resolveAt(hit.shooterViewTick));    // rewinds hitboxes, sub-tick interpolated

@after(projectiles.hit_reported)
def validate(hit: HitReport):
    hit.resolve_at(hit.shooter_view_tick)    # rewinds hitboxes, sub-tick interpolated

Previsão de trajetória, compartilhada por servidor e cliente (arcos de mira, marcadores de impacto). A previsão é uma operação deste módulo, extrapolada contra o conjunto de obstáculos do mapa, então os dois lados desenham o mesmo arco a partir dos mesmos dados de entrada:

var arc = room.Prediction.Trajectory(from, velocity, steps: 30);   // collision-aware

const arc = room.prediction.trajectory(from, velocity, { steps: 30 });   // collision-aware

arc = room.prediction.trajectory(origin, velocity, steps=30)   # collision-aware

// collision-aware: the arc the platform itself would walk
Room->Prediction->Trajectories->Get(LaunchPosition, LaunchVelocity, /*Steps*/ 30,
    TPSOnResult<FPSTrajectory>::CreateWeakLambda(this, [this](const TPSResult<FPSTrajectory>& Result)
    {
        if (!Result.HasValue()) { return; }
        DrawArc(Result.Value());
    }));
// co_await support ships later: a built-in SDK coroutine wrapper that respects Unreal's GC and threading.

var arc = room.Prediction.Trajectory(from, velocity, steps: 30);   // collision-aware

O modelo

A previsibilidade é declarada em um aspecto — e um aspecto que só a autoridade altera, por regras que o cliente não tem, não pode ser marcado como previsível: isso é uma falha de validação no deploy, não uma surpresa em runtime.

O que se declara.

O que é retrocedido e o que, de propósito, não é.

client tick:  apply input locally (predict) → buffer it → send, tick-stamped
server tick:  step the same movement model → authoritative state → delta out
client recv:  authoritative state for tick T → if divergence beyond tolerance:
              rewind to T → replay buffered inputs T+1..now → smooth

Só os campos declarados como previstos sofrem rollback; um desvio mínimo é suavizado, e uma divergência real volta no tempo e reaplica os inputs.

Erros

• Momento de visualização fora da janela é um conflito: envie um atual.
• Pedido de histórico fora da janela também é um conflito.
• Dois defeitos de declaração são pegos no deploy: uma janela de compensação maior que o buffer de histórico e um aspecto marcado como previsível sem que o cliente tenha regras para prevê-lo. Nenhum dos dois chega a uma partida ao vivo.
• Duas coisas não são erros, e as duas são observáveis. Um buffer de input cheio suspende a predição até a confirmação, em vez de descartar inputs em silêncio. E uma divergência acima do limiar faz o estado da autoridade ser aceito como chega: essa é a correção declarada, não uma falha.

Limites

Os números chegam com o capítulo de limites da plataforma; o que acontece em cada teto já está definido.

• Janela de compensação: além dela, recusa, nunca extrapolação.
• Janela de extrapolação para os outros: a entidade é marcada como desatualizada e a extrapolação para.
• Buffer de inputs não confirmados: a predição é suspensa até a confirmação; inputs nunca são descartados em silêncio.
• Profundidade do histórico para um retrocesso: no mínimo a janela de compensação, verificado no deploy.
• Taxa de ações com momento de visualização: rate limit com prazo.
• Entidades previstas ao mesmo tempo por cliente: acima do teto, a predição não é feita, e isso é uma degradação declarada, não uma recusa.