J'ai actuellement entrepris un projet assez ambitieux. En bref, c'est un jeu de stratégie multijoueur en temps réel qui a une mécanique bactérienne.

Essentiellement, j'ai deux joueurs distants dans l'environnement, et ils peuvent engendrer des unités semblables à des bactéries qui s'attaquent et se multiplient, se dupliquant jusqu'à ce qu'une limite de ressources soit atteinte. Cela se traduit souvent par environ 200+ objets de jeu rendus à l'écran, chacun avec son propre état et son propre mouvement. Cela semble mauvais, mais le gameplay local contre un bot est en fait très bon, et j'ai réussi à le rendre assez performant.

Cependant, le problème se pose lorsque j'essaie de mettre en réseau ce jeu. J'ai déjà tenté de suivre ce guide pour implémenter cette fonctionnalité: http://www.paladinstudios.com/2013/07/10/how-to-create-an-online-multiplayer-game-with-unity/

Cela produit une expérience de jeu assez lente et déplaisante même avec la meilleure latence. Cela est probablement dû au fait de devoir transmettre des données de mouvement pour des centaines d'unités.

La question que je pose:

Comment puis-je optimiser la mise en réseau et la synchronisation de nombreuses unités mobiles entre deux clients?

J'ai déjà pensé à une façon de procéder. Après avoir engendré une unité, ils ne voyageront que dans une seule direction jusqu'à ce qu'ils touchent quelque chose - peut-être que je ne peux synchroniser que lorsque les unités sont générées et lorsqu'elles interagissent avec un autre objet? Cela aurait-il beaucoup d'avantages? Quelle est la façon idéale de mettre cela en œuvre?

Merci d'avance pour les réponses!

Pour plus de 200 objets en mouvement, vous voudrez certainement faire de votre jeu le pas. Avec le lockstep, vient le besoin de déterminisme mais cela ne devrait pas être trop difficile pour les bactéries (qui peuvent être simulées avec des collisions cercle-cercle).

Si cela ne vous dérange pas mon auto-plug sans vergogne et que vous voulez un exemple avec la logique de mise en réseau et de simulation d'un jeu de verrouillage, consultez cet atout gratuitement: https://www.assetstore.unity3d.com/en/#!/ content / 36206 . Malheureusement, cette version n'inclut pas tout le code source mais n'hésitez pas à le pirater avec ma bénédiction;). Voici une vidéo d'un premier test de DPhysics: https://www.youtube.com/watch?v=NEzOghxfMdU .

L'essentiel du verrouillage consiste à synchroniser l'entrée au lieu de la sortie. En effet, avec une simulation synchrone, la seule chose que tous les clients ignorent, ce sont les entrées des autres clients. L'article que vous avez lié dans votre commentaire l'explique assez bien. Je ne sais pas à quel point vous aimeriez que j'explique le verrouillage, alors je vais le couper ici et développer cette réponse si vous avez d'autres questions.

Mise à jour: Considérez-le comme un serveur faisant autorité, sauf que le serveur envoie des entrées au lieu de l'état du jeu. Étant donné que chaque joueur peut produire l'état du jeu pour lui-même à partir de l'entrée, il n'est pas nécessaire que le serveur distribue l'état du jeu.