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

Collision

Liez un transform à la carte des obstacles et déclarez ce que produit un contact. Les collisions sont calculées dans la simulation de la plateforme. Vous déclarez des corps, des couches et des réponses, puis vous vous abonnez aux contacts.

Quand l’utiliser

• Des entités en mouvement doivent résoudre leurs contacts côté serveur (glisser, s’arrêter, rebondir) sans routine de déviation écrite à la main.
• Le gameplay réagit au toucher : un objet se ramasse dès qu’on le chevauche, un volume déclencheur fait avancer la machine à états d’une entité.
• Locomotion et les projectiles ont besoin d’une résolution continue (swept) contre les obstacles de la carte.
• Un aperçu de placement ou un ciblage doit savoir « est-ce que ça tient ici ? » et interroger le chevauchement de volumes.
• Inutile quand rien ne se rencontre physiquement. Un gameplay requête/réponse sur des enregistrements relève simplement de Data & Subscriptions.

Qui fait quoi

En bref

La forme, la couche et l’effet d’un contact se déclarent tous sur le corps lui-même — aucune déclaration à distance de paires de couches :

[Entity("tank")]
public class Tank
{
    [Sync] public Vector3 Position;

    [Body(Shape.Capsule, Radius = 0.6f, Layer = "vehicles")]
    [CollidesWith("walls", Response.Slide)]
    [CollidesWith("pickups", Response.Pass)]        // reported, motion passes through
    public Body Body;
}

@Entity('tank')
export class Tank {
  @Sync() position!: Vector3;

  @Body({ shape: 'capsule', radius: 0.6, layer: 'vehicles' })
  @CollidesWith('walls', Response.Slide)
  @CollidesWith('pickups', Response.Pass)        // reported, motion passes through
  body: Body;
}

@entity("tank")
class Tank:
    position: Vector3 = sync()

    body = collision.body(shape="capsule", radius=0.6, layer="vehicles",
                           collides_with=[
                               ("walls", Response.SLIDE),
                               ("pickups", Response.PASS),   # reported, motion passes through
                           ])

// the declaration rides inside the engine's own reflection macros, in the specifier position —
// UHT reads it from the header text, and the member is a reflected property at the same time
UCLASS(PSEntity = "tank")
class UTank : public UObject
{
    GENERATED_BODY()

    UPROPERTY(PSSync)
    FVector3f Position;

    // walls slide, pickups report the contact and let motion pass through —
    // multi-entry values are one quoted list (a specifier value is a single token)
    UPROPERTY(PSBody = (Shape = "Capsule", Radius = "0.6", Layer = "vehicles"),
              PSCollidesWith = "walls:Slide, pickups:Pass")
    FPSBody Body;
};
// declarations compile into the same pushed model — playserv push from the UE project or CI

[Entity("tank")]
public class Tank
{
    [Sync] public Vector3 Position;

    [Body(Shape.Capsule, Radius = 0.6f, Layer = "vehicles")]
    [CollidesWith("walls", Response.Slide)]
    [CollidesWith("pickups", Response.Pass)]        // reported, motion passes through
    public Body Body;
}

Un contact est un événement, et les modules s’y abonnent. Il n’existe pas de hook sur un contact : au moment où il existe, le pas de simulation l’a déjà résolu, il n’y a donc plus rien à refuser. Si un studio a besoin d’autres règles, il remplace les vérifications d’admissibilité et de trajectoire par sa propre implémentation — voir Extensibility — et la réponse reste déclarée.

Le modèle

Ce que déclare un corps.

La réponse se déclare sur une paire — un type de franchissabilité d’obstacle × un type de corps — et elle est tirée d’un ensemble fermé :

Les coefficients sont des valeurs déclarées, pas des résultats calculés à partir de masses et de matériaux : ce contrat ne connaît ni les unes ni les autres.

Ce qui vaut pour chaque vérification.

Erreurs

• « Inadmissible » est une réponse, pas une erreur, et elle précise laquelle des trois raisons s’applique : hors des limites, occupé par un obstacle statique, ou occupé par le corps d’une autre entité. Un client réagit différemment à chacune : faire demi-tour, contourner ou attendre.
• Les défauts de déclaration se révèlent au déploiement, jamais au premier contact : un corps dont la forme sort de l’ensemble fermé, un corps sur un aspect sans transform, une paire sans réponse déclarée — tous sont refusés au déploiement.
• L’entité ou l’emplacement est introuvable : la réponse est not found, et réessayer ne sert à rien.
• La fréquence de vérification est dépassée : la réponse relève de la catégorie rate limit, avec l’échéance avant laquelle réessayer ne sert à rien.

Limites

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

• Corps dans une salle : en déclarer un de plus est refusé comme un conflit ; on ne supprime jamais des corps existants pour faire de la place.
• Contacts par pas : l’excédent n’est jamais écarté en silence. Soit le pas est refusé, soit l’ordre de coupure est déclaré.
• Taille d’un corps par rapport au pas de la grille de la carte : refusée au déploiement, car un corps plus petit que le pas du champ de hauteurs passe à travers le terrain.
• Zones dans lesquelles un corps peut se trouver : un excédent est refusé au déploiement.
• Fréquence de vérification par acteur : une limitation de débit, avec une échéance.
• Corps dans une réponse « qui est dans cette zone » : la liste est tronquée selon un ordre déclaré, et l’indicateur de troncature est obligatoire.