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

Visibility

Con 40 jugadores, un snapshot de toda la sala funciona. Con 200, no. Una zona de visibilidad decide quién recibe qué, como un predicado declarado y no como un interruptor que activas objeto por objeto. La difusión y los paquetes por actor son dos modos de entrega declarados de un mismo modelo, así que pasar de uno a otro es cuestión de configuración, no de reescribir código. Es una optimización del canal y no un permiso; para eso, consulta Access & Roles.

Un mismo modelo declarado (el predicado, las capas, los niveles de detalle) se lee de dos maneras:

Lo que no debe filtrarse no está en el paquete, en lugar de estar oculto en el cliente: nunca se envía, y por eso es una propiedad de seguridad y no de ancho de banda.

Cuándo usarlo

• Tus salas ya no caben en una difusión de toda la sala: 200 jugadores necesitan flujos de su entorno cercano por cliente, no cada delta.
• El estado no debe filtrarse: la niebla de guerra y los campos (field) que solo ve el dueño nunca deben enviarse, en vez de ocultarse en el cliente.
• Varias sesiones comparten un mapa y no deben verse entre sí: una capa es un predicado más.
• El tamaño del paquete tiene que ser predecible en una multitud: limita los objetos y declara el orden, para que “los N más cercanos” sea una promesa y no un accidente de la densidad.
• Un jugador en un límite tiene que ver del otro lado: declara qué áreas vecinas son visibles, porque de forma predeterminada solo lo es la suya.
• No lo necesitas si la sala es pequeña. El modo de entrega con paquete compartido ya lo resuelve.

Quién hace qué

En resumen

[Entity("tank")]
[Visible(Radius = 60)]                           // spatial
[Visible(Rule.SameLayer)]                        // layers of one map
public class Tank
{
    [Sync] public Vector3 Position;
    [Sync(To = Scope.Owner)] public int Ammo;    // per-field scope
}

@Entity('tank')
@Visible({ radius: 60 })                       // spatial
@Visible(Rule.SameLayer)                       // layers of one map
export class Tank {
  @Sync() position!: Vector3;
  @Sync({ to: Scope.Owner }) ammo = 0;         // per-field scope
}

@entity("tank")
@visible(radius=60)                              # spatial
@visible(Rule.SAME_LAYER)                        # layers of one map
class Tank:
    position: Vector3 = sync()
    ammo: int = sync(to=Scope.OWNER)             # per-field scope

// multi-entry values are one quoted list (a specifier value is a single token)
UCLASS(PSEntity = "tank",
       PSVisible = "radius:60, rule:SameMapInstance")   // spatial + instances of one map
class UTank : public UObject
{
    GENERATED_BODY()

    UPROPERTY(PSSync)                  FVector3f Position;
    UPROPERTY(PSSync = (To = "Owner")) int32     Ammo;   // per-field scope
};
// declarations compile into the same pushed model — playserv push from the UE project or CI

[Entity("tank")]
[Visible(Radius = 60)]                           // spatial
[Visible(Rule.SameLayer)]                        // layers of one map
public class Tank
{
    [Sync] public Vector3 Position;
    [Sync(To = Scope.Owner)] public int Ammo;    // per-field scope
}

El modelo

Qué declara una regla de visibilidad.

Qué se cumple en toda zona.

Errores

• Un destino de suscripción no declarado es un rechazo de validación.
• La falta de permiso para suscribirse responde forbidden o not found según si la existencia del destino es secreta: el propio rechazo no debe revelar lo que rechaza.
• Una posición de reanudación que no se puede interpretar es una solicitud incorrecta, no un reinicio silencioso desde el momento actual.
• Una suscripción que cerró la plataforma y una cantidad de suscripciones agotada son, ambas, conflictos.
• Ampliar una vista es fn. Otorgar una vista ampliada y fijar niveles de detalle se rechazan con forbidden para una sesión de jugador, y su vista no cambia: un cliente espectador no puede ampliar sus propios permisos otorgados (grant).
• Una instancia que la vista del llamador excluye responde not found, la misma respuesta que una que no existe: un forbidden confirmaría que hay algo detrás del muro.
• Leer el costo de los paquetes por actor es fn adm : una función en la nube o el panel, nunca un cliente.

Límites

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

• El costo de un paquete por actor: al agotarse, degradación declarada al paquete compartido con un aviso, nunca una pérdida arbitraria de destinatarios.
• Objetos por regla: limitados, con un orden declarado y un indicador de truncamiento observable.
• Suscripciones por actor: una nueva se rechaza y las existentes siguen.
• Tamaño de la delta: la delta se divide, no se trunca, y la división es observable.
• La tasa de envío: un límite superior, no una garantía.