Not translated yet — showing English.

Locomotion

You declare how a thing moves; nobody writes an integrator. A movement model turns sequenced input into authoritative motion, integrated with collision, recorded for prediction, and modified by buffs, debuffs and terrain.

When to use it

• Entities move under player input (tanks, characters, vehicles), and motion must be server-authoritative.
• You would rather declare speed, acceleration and turn-rate limits than write an integrator.
• Gameplay pushes bodies around: Impulse knockbacks, Teleport, and mud-style modifiers with durations.
• Movement must feel instant: the same declared model steps on the server and in prediction's loop.
• Skip it when positions change only in discrete steps. A synced field on the entity already covers it.

Who does what

At a glance

[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;
}

Client input is a sequenced intent. The platform steps the motion:

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

Server-side verbs:

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);

The model

What an entity declares in order to move.

What is true of every step.

Errors

• A missing movement model on the entity, a partially filled preset, and an impulse with no declared decay are all validation failures at deploy, not at runtime.
• The expected generation did not match is a precondition failure, worth repeating after re-reading: input sent before a respawn must not be applied after it.
• The input rate exceeded answers in the rate-limit category with a deadline.
• The entity is not controllable is a conflict, and repeating it makes sense only after the state changes.
• Three things are refusals in neither direction, and all three are observable. Stale input is discarded, an intent beyond a limit is clamped, and a pose beyond the tolerance is clamped as pose_clamped. Doing any of them silently would leave the client believing it applied and diverging from the server for good.

Limits

The numbers arrive with the platform limits chapter; what happens at each ceiling is fixed now.

• Maximum speed and acceleration: clamped, never refused.
• Maximum turn per input: clamped.
• Input rate per actor: a rate limit with a deadline.
• Catch-up steps: beyond the cap, steps are discarded with a declared consequence. Simulation time falls behind, observably, instead of catching up in a jump that looks like everyone teleporting at once.
• Impulse magnitude: clamped to the declared maximum.
• Simultaneous impulses per entity: a new one evicts the oldest, and the eviction is observable; there is no silent unbounded summation.
• The lifetime of a claimed pose: one older than the declared period is not considered.