Esta página aún no está traducida: se muestra la versión en inglés.

Locomotion

Declaras cómo se mueve algo; nadie escribe un integrador. Un modelo de movimiento convierte la entrada numerada en movimiento autoritativo, integrado con las colisiones, registrado para la predicción y modificado por buffs, debuffs y el terreno.

Cuándo usarlo

• Las entidades se mueven según la entrada del jugador (tanques, personajes, vehículos), y el servidor tiene que tener la autoridad sobre el movimiento.
• Prefieres declarar límites de velocidad, aceleración y giro antes que escribir un integrador.
• El gameplay empuja los cuerpos: empujes (knockback) con Impulse, Teleport y modificadores tipo barro con duración.
• El movimiento tiene que sentirse instantáneo: el mismo modelo declarado avanza en el servidor y en el bucle de la predicción.
• No lo uses si las posiciones solo cambian en pasos discretos. Para eso ya alcanza un campo sincronizado en la entidad.

Quién hace qué

En resumen

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

La entrada del cliente es una intención numerada. La plataforma avanza el movimiento:

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

Verbos del lado del servidor:

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

El modelo

Qué declara una entidad para moverse.

Qué se cumple en cada paso.

Errores

• Un modelo de movimiento que falta en la entidad, un preset a medio llenar y un impulso sin decaimiento declarado son fallas de validación en el deploy, no en runtime.
• La generación esperada no coincide: es una falla de precondición, y conviene repetir después de volver a leer. La entrada enviada antes de una reaparición no debe aplicarse después de ella.
• Si se supera la frecuencia de entrada, la respuesta cae en la categoría de rate limit, con un plazo.
• La entidad no es controlable: es un conflicto, y repetir solo tiene sentido después de que cambie el estado.
• Hay tres casos que no son un rechazo en ninguna dirección, y los tres son observables. La entrada obsoleta se descarta, una intención que supera un límite se recorta y una pose fuera de la tolerancia se ajusta con pose_clamped. Si cualquiera de ellos pasara en silencio, el cliente creería que se aplicó y quedaría desincronizado del servidor para siempre.

Límites

Los números llegarán con el capítulo de límites de la plataforma; lo que pasa en cada tope ya está definido.

• Velocidad y aceleración máximas: se recortan, nunca se rechazan.
• Giro máximo por entrada: se recorta.
• Frecuencia de entrada por actor: un rate limit con plazo.
• Pasos de recuperación: más allá del tope, los pasos se descartan con una consecuencia declarada. El tiempo de simulación se atrasa, de forma observable, en lugar de ponerse al día de un salto que parece un teletransporte de todos a la vez.
• Magnitud del impulso: se recorta al máximo declarado.
• Impulsos simultáneos por entidad: uno nuevo desplaza al más antiguo, y ese desplazamiento es observable; no hay una suma silenciosa sin límite.
• Vida útil de una pose informada: no se tiene en cuenta una pose más antigua que el período declarado.