Comment corriger le Player Location Desync dans UEFN et Unreal Engine Multiplayer

Le cauchemar du Multiplayer Transform Desync

Tout développeur de jeux multijoueurs finit par être confronté au moment où son netcode commence à lui mentir. Vous scriptez une séquence où un joueur s'assoit sur une chaise, la chaise se déplace sur la map, et tout semble parfait sur le serveur. Mais lorsque vous lancez un second client, l'illusion s'effondre. Le Client A se voit parfaitement sur la chaise. Le Client B voit la chaise bouger alors que le Client A flotte, figé dans les airs, au point de départ.

Ce phénomène spécifique — le uefn player location desync — est un problème bien documenté lors de l'utilisation d'inputs de joueur pour déclencher des commandes MoveTo sur des props transportant des joueurs attachés. Le serveur enregistre la position absolue correcte, mais les simulated proxies (les représentations du joueur sur les autres clients) ne parviennent pas à hériter du transform mis à jour de leur prop parent.

Que vous créiez une expérience personnalisée dans Unreal Editor for Fortnite (UEFN) ou que vous conceviez un dedicated server autonome dans Unreal Engine 5, il est crucial de comprendre pourquoi la replication des attachments échoue. Dans ce tutoriel, nous allons décortiquer la mécanique de la Network Dormancy, pourquoi les attachments cassent la client-side prediction, et comment forcer le replication graph à respecter l'état de votre monde.

Pourquoi les Attachments cassent les Network Updates

Pour corriger le desync, vous devez d'abord comprendre comment Unreal Engine gère la actor replication de manière hiérarchique.

Lorsqu'un character actor s'attache à un prop (comme s'asseoir sur un dispositif de chaise), son transform devient relatif à l'actor parent. Dans un environnement réseau, le serveur doit décider comment diffuser ces données à 100 clients différents de manière efficace. Pour économiser de la bande passante, Unreal Engine utilise de manière agressive un concept appelé Network Dormancy.

Lorsqu'un joueur est assis et cesse de fournir un input de mouvement direct, le replication graph du serveur peut marquer le player actor comme dormant. Le serveur suppose : "Le joueur ne bouge pas de manière indépendante, je n'ai donc pas besoin d'envoyer de mises à jour pour lui. Je n'enverrai des mises à jour que pour la chaise en mouvement."

Les chiffres derrière le Desync

Voici les chiffres concrets qui causent cet échec :

• Server Tick Rate : Généralement 30Hz dans UEFN.
• Prop NetUpdateFrequency : Souvent 100 mises à jour par seconde par défaut.
• Character MinNetUpdateFrequency : Peut descendre jusqu'à 2.0 (2 mises à jour par seconde) lorsqu'aucun input n'est détecté.

Lorsque vous appelez MoveTo sur la chaise, le transform de la chaise se met à jour à 30Hz. Cependant, comme le joueur attaché est dormant ou se met à jour à une fréquence réduite, les autres clients ne reçoivent jamais le RPC (Remote Procedure Call) leur demandant de mettre à jour la position relative du joueur. Résultat ? Un desync visuel massif.

Si vous rencontrez des problèmes avec d'autres variables, consultez The Unreal Engine Multiplayer Sync Bug Ruining Your World States And How To Fix It.

Étape 1 : Le contournement Verse dans UEFN

Dans les rapports de bugs officiels d'UEFN, les développeurs ont noté un indice vital : quitter la chaise corrige le problème.

Pourquoi ? Parce que changer le movement mode du joueur de Custom (assis) à Walking force le serveur à vider (flush) la Network Dormancy et à diffuser une mise à jour de transform absolue à tous les clients.

Nous pouvons recréer ce "flush" par programmation dans Verse. En manipulant l'état du joueur ou en forçant un micro-téléport, nous réveillons le replication graph.

# [Code Verse identique à l'original]

En appelant TeleportTo aux mêmes coordonnées, nous forçons le moteur C++ à activer le flag TeleportPhysics, ce qui réinitialise complètement la client-side prediction pour cet actor.

Étape 2 : Le correctif natif Unreal Engine C++

Si vous avez accès au code source, vous pouvez interagir directement avec l'API networking pour gérer la dormancy.

// Exemple de force net update en UE5 C++
// [Code C++ identique à l'original]

Cette approche C++ est plus performante car elle manipule directement le NetDriver au lieu de s'appuyer sur des effets de bord de la physique.

Étape 3 : Persistance de l'état dans votre Backend

Corriger le desync en direct n'est que la moitié du travail. Si votre jeu possède un monde persistant, vous devez vous assurer que les coordonnées absolues correctes sont sauvegardées. Utilisez toujours le transform server-authoritative après une mise à jour réseau forcée.

Développer un backend sur mesure prend du temps. horizOn propose un Backend-as-a-Service conçu pour les développeurs de jeux, avec persistance d'état en temps réel incluse.

5 Bonnes Pratiques

1. Ne faites jamais confiance à l'état d'attachment du client : Utilisez des RPCs server-authoritative.
2. Gérez la NetDormancy manuellement : Appelez FlushNetDormancy lors des mouvements.
3. Hiérarchies simples : Évitez les attachments trop profonds (Joueur -> Chaise -> Train -> Plateforme).
4. RPCs fiables pour les changements critiques : Utilisez NetMulticast pour monter/descendre.
5. Validez les transforms à la descente : Vérifiez la position côté serveur lors de la sortie.

Conclusion

Les desyncs multijoueurs sont souvent dus à des optimisations agressives. En comprenant la Network Dormancy, vous pouvez forcer les mises à jour via Verse ou C++. Reprenez le contrôle de votre replication graph.

Prêt à scaler votre backend ? Essayez horizOn gratuitement.