Je travaille sur un jeu mobile Unity, un peu comme une version multijoueur de Temple Run . Je constate une latence de réseau fluctuante (généralement de 200 à 500 ms) en raison de la plate-forme mobile.

Les deux personnages joueurs sont représentés comme courant sur le même chemin et doivent effectuer des actions simples (saut, glissement, mise sous tension, etc.) pour franchir les obstacles.

Lorsqu'un message arrive en retard, le jeu suppose que le joueur distant a passé un obstacle. Cela fonctionne généralement bien, mais si un joueur est tué par un obstacle, je veux que le joueur distant semble mourir sur le même obstacle / position que le joueur local. En raison de la latence, le joueur distant semble avoir franchi l'obstacle avant même l'arrivée du message annonçant sa mort.

Comment puis-je garder les joueurs synchronisés?

J'ai essayé de déplacer le lecteur distant vers la position de mort des joueurs locaux immédiatement lorsque le message de mort arrive, il semble visuellement gênant et pourrait poser d'autres problèmes de synchronisation.

Analyse du problème

La communication en temps réel sur une connexion à latence élevée est évidemment impossible.

Vous pouvez bien sûr tenter une illusion (comme vous le faites en faisant croire que le lecteur distant a passé un obstacle alors qu'il n'est pas encore connu). Lorsque cette illusion échoue (comme la vôtre lorsque le joueur distant n'a pas franchi l'obstacle, mais est mort à la place), rien ne peut plus être fait.

Dans un cas (comme ici) où l'échec de l'illusion semble vraiment mauvais , il pourrait être plus facile d'accepter les faits et de faire de votre mieux pour représenter la situation telle qu'elle est réellement.

Solution potentielle

Que diriez-vous de ralentir littéralement l'autre joueur si sa décision prend du temps à se propager?

Chaque joueur voit une image de l'autre, mais cette image ralentit à l'approche d'obstacles pour lesquels le message de décision est toujours dans l'air. Ce n'est qu'une fois le message reçu qu'ils semblent passer ou échouer l'obstacle. Après l'obstacle, l'image accélère à nouveau pour rattraper son retard, ralentissant à nouveau pour le suivant, si nécessaire.

Sur une connexion à faible latence, la décision arrive bientôt et le ralentissement et l'accélération seront négligeables. Sur une connexion à latence élevée, cela donnera l' impression que l'autre joueur est à la traîne, mais garantit que l' état de jeu le plus important de "qui a franchi cet obstacle" est cohérent pour les deux joueurs.

Pour compléter la réponse d'Anko, vous pouvez changer un peu la conception de votre jeu en ajoutant la conséquence de l'obstacle échoué après l'échec, par exemple, un saut échoué entraîne l'atterrissage dans une flaque de boue qui disqualifie le joueur. De cette façon, l'autre joueur remarque l'échec en voyant l'autre tomber dans la boue, tandis que le joueur qui échoue le voit tout de suite.

Voici un joli billet de blog sur ce problème (ce n'est pas si récent mais c'est assez intéressant): Gestion du temps et synchronisation de Darrin West .

Est-il si important pour le joueur local de connaître la position exacte de la mort du joueur distant? Disons que le joueur distant ne pouvait pas sauter par-dessus l'un de vos obstacles, et est donc mort.

Le joueur mort verrait sa mort immédiatement et continuerait depuis le lieu de l'accident. Rien de magique ici.

Le joueur local (celui qui est toujours vivant et qui donne des coups de pied) verrait le joueur distant passer l'obstacle avec succès. Une notification de décès entrait. Le joueur distant trébuchait sur ses pieds, tombait et disparaissait lentement. La prochaine fois que vous connaîtrez la position du joueur distant, le joueur se fondra dans cette position exacte et fonctionnera à nouveau normalement. Dans une telle configuration, les joueurs seraient conscients de la latence, mais la latence serait représentée comme un élément de jeu (trébuchant) plutôt que d'apparaître et de disparaître de façon saccadée.

Si la vitesse des deux joueurs est constante, la trajectoire de course est prédéfinie et le temps nécessaire pour se remettre d'une chute est connu, vous pouvez éliminer complètement la partie qui s'estompe / disparaît. Imaginez un joueur distant mourant à l'un des obstacles. Sa représentation locale est toujours active lorsqu'une notification arrive. Le joueur trébuche immédiatement. Il leur faut du temps pour se lever et recommencer à courir. En fait, cela prend autant de temps que si on les montrait en train de mourir à l'obstacle. Ainsi, lorsqu'ils sont à nouveau opérationnels, les positions locales et distantes sont synchronisées.