Cette page n’est pas encore traduite : la version anglaise est affichée.

Locomotion

Vous déclarez comment une chose se déplace ; personne n’écrit d’intégrateur. Un modèle de mouvement transforme des entrées numérotées en mouvement faisant autorité : il s’appuie sur les collisions, il est enregistré pour la prédiction, et les buffs, les debuffs et le terrain le modifient.

Quand l’utiliser

• Des entités se déplacent sous l’entrée du joueur (tanks, personnages, véhicules), et le serveur doit faire autorité sur leur déplacement (locomotion).
• Vous préférez déclarer des limites de vitesse, d’accélération et de rotation plutôt qu’écrire un intégrateur.
• Le gameplay bouscule les corps : recul (knockback) avec Impulse, Teleport, et des modificateurs temporaires du genre boue.
• Le mouvement doit paraître instantané : le même modèle déclaré avance sur le serveur et dans la boucle de prédiction.
• Inutile quand les positions ne changent que par sauts discrets. Un champ synchronisé sur l’entité suffit alors.

Qui fait quoi

En bref

[Entity("tank")]
public class Tank
{
    [Sync] public Vector3 Position;
    [Motion(Model.Tank, MaxSpeed = 8f, Acceleration = 14f, TurnRateDeg = 120f)]
    public Motion Motion;
}

@Entity('tank')
export class Tank {
  @Sync() position!: Vector3;
  @Motion({ model: 'tank', maxSpeed: 8, acceleration: 14, turnRateDeg: 120 }) motion: Motion;
}

@entity("tank")
class Tank:
    position: Vector3 = sync()
    motion = locomotion.motion(model="tank", max_speed=8.0, acceleration=14.0, turn_rate_deg=120.0)

UCLASS(PSEntity = "tank")
class UTank : public UObject
{
    GENERATED_BODY()

    UPROPERTY(PSSync) FVector3f Position;

    UPROPERTY(PSMotion = (Model = "Tank", MaxSpeed = "8.0", Acceleration = "14.0", TurnRateDeg = 120))
    FPSMotion Motion;
};
// declarations compile into the same pushed model — playserv push from the UE project or CI

[Entity("tank")]
public class Tank
{
    [Sync] public Vector3 Position;
    [Motion(Model.Tank, MaxSpeed = 8f, Acceleration = 14f, TurnRateDeg = 120f)]
    public Motion Motion;
}

L’entrée du client est une intention numérotée. C’est la plateforme qui fait avancer le mouvement :

room.My<Tank>().Motion.Drive(throttle: 1f, steer: -0.4f);   // cl — sent at input rate

room.my<Tank>().motion.drive({ throttle: 1, steer: -0.4 });   // cl — sent at input rate

room.my(Tank).motion.drive(throttle=1.0, steer=-0.4)   # cl — a bot brain drives the same way

Room->Entities->Of<UTank>()->Select().GetMine().Then(
    TPSOnResult<UTank*>::CreateWeakLambda(this, [this](const TPSResult<UTank*>& Result)
    {
        if (!Result.HasValue()) { return; }
        // client — sent at input rate, numbered so the platform can acknowledge
        Result.Value()->Motion->SubmitInput(FPSMoveInput{ .Throttle = 1.f, .Steer = -0.4f }, InputSequence);
    }));
// co_await support ships later: a built-in SDK coroutine wrapper that respects Unreal's GC and threading.

room.My<Tank>().Motion.Drive(throttle: 1f, steer: -0.4f);   // cl — sent at input rate

Les verbes côté serveur :

tank.Motion.Impulse(knockback);
tank.Motion.Modify("mud", speedMultiplier: 0.6f, duration: 3.Seconds());
tank.Motion.Teleport(spawn);

tank.motion.impulse(knockback);
tank.motion.modify('mud', { speedMultiplier: 0.6, duration: seconds(3) });
tank.motion.teleport(spawn);

tank.motion.impulse(knockback)
tank.motion.modify("mud", speed_multiplier=0.6, duration=seconds(3))
tank.motion.teleport(spawn)

// on a dedicated server / master-client host
Tank->Motion->Impulse(EPSImpulseKind::Impulse, KnockbackVelocity);
Tank->Motion->Modify({ .Modifier = TEXT("mud"), .SpeedMultiplier = 0.6f, .For = FPSDuration::Seconds(3.f) });
Tank->Motion->Teleport(SpawnPosition, SpawnFacing);
// co_await support ships later: a built-in SDK coroutine wrapper that respects Unreal's GC and threading.

tank.Motion.Impulse(knockback);
tank.Motion.Modify("mud", speedMultiplier: 0.6f, duration: 3.Seconds());
tank.Motion.Teleport(spawn);

Le modèle

Ce qu’une entité déclare pour se déplacer.

Ce qui vaut pour chaque pas.

Erreurs

• Une entité sans modèle de mouvement, un preset partiellement rempli, une impulsion sans amortissement déclaré : autant d’échecs de validation au déploiement, pas au runtime.
• La génération attendue ne correspond pas : c’est un échec de précondition, et il vaut la peine de réessayer après relecture — une entrée envoyée avant une réapparition ne doit pas s’appliquer après.
• La fréquence des entrées est dépassée : la réponse relève de la catégorie rate limit, avec une échéance.
• L’entité n’est pas contrôlable : c’est un conflit, et réessayer n’a de sens qu’après un changement d’état.
• Trois situations ne sont des refus ni dans un sens ni dans l’autre, et toutes trois sont observables. Une entrée périmée est écartée, une intention qui dépasse une limite est écrêtée, et une pose hors tolérance est ramenée avec pose_clamped. Le faire en silence laisserait le client croire que son action a été appliquée, et il divergerait du serveur pour de bon.

Limites

Les chiffres arriveront avec le chapitre sur les limites de la plateforme ; ce qui se passe à chaque plafond est déjà fixé.

• Vitesse et accélération maximales : écrêtées, jamais refusées.
• Rotation maximale par entrée : écrêtée.
• Fréquence des entrées par acteur : une limitation de débit, avec une échéance.
• Pas de rattrapage : au-delà du plafond, des pas sont écartés avec une conséquence déclarée. Le temps de simulation prend du retard, de façon observable, au lieu de rattraper d’un bond qui donnerait l’impression que tout le monde se téléporte en même temps.
• Intensité d’une impulsion : écrêtée au maximum déclaré.
• Impulsions simultanées par entité : une nouvelle évince la plus ancienne, et l’éviction est observable ; aucune sommation illimitée en silence.
• Durée de vie d’une pose annoncée : une pose plus ancienne que la période déclarée n’est pas prise en compte.