Je l'ai fait pour un jeu de course PSP commercial, qui fonctionnait à la fois sur un réseau ad hoc et via un point d'accès sans fil. (Ou vers un serveur statique sur Internet, si vous le souhaitez)
En raison du point 2, le système n'a pas besoin d'être complexe en ce qui concerne l'optimisation
D'après mon expérience, ce n'est pas vrai. Les appareils sans fil (en particulier les petits appareils portables) ne sont pas comme des ordinateurs avec des connexions réseau filaires - les smartphones et les consoles de jeux sans fil ont tendance à avoir des interfaces réseau lentes pour les jeux.
Ne vous méprenez pas - leur débit est généralement bon (c'est-à-dire la quantité de données par seconde; idéal pour les films en streaming ou etc.), mais la latence à la livraison d'un paquet particulier peut être extrêmement mauvaise, et peut l'être très variable qu'il est difficile d'estimer même combien de temps un paquet individuel prendra pour livrer. Cette variation devient encore pire lorsque de plus en plus d'appareils sans fil sont regroupés dans une zone générale, car leurs signaux commencent à interférer les uns avec les autres. À la suite de cela, j'ai passé beaucoup de temps à réduire le nombre de paquets à envoyer, nous aurions donc moins de collisions de paquets. (Notez que c'est un peu moins un problème dans le cas où un point d'accès réseau alimenté est impliqué, plutôt que d'avoir les appareils qui se parlent directement sur un réseau ad hoc)
Comme exemple de ce type d'optimisation, notre jeu de course s'est déroulé dans un monde qui avait des feux de circulation. Des milliers d'entre eux. Et nous devions nous assurer que leurs signaux étaient synchronisés entre tous les joueurs d'une session réseau. Plutôt que d'essayer d'envoyer des paquets pour dire à tout le monde quels feux étaient dans quel état, nous avons défini un calendrier statique pour tous les feux de circulation, puis nous nous sommes juste assurés que tous les clients étaient d'accord sur le "temps de jeu" actuel. Puisqu'ils connaissaient tous l'heure du jeu et que tous les états des feux de signalisation pouvaient être déterminés à partir de l'heure du jeu, nous avons synchronisé toutes ces données d'état sans envoyer de données spéciales. Ce seul changement a fait une énorme différence pour nos performances réseau.
Ce qui a dit, établir une synchronisation d'horloge fiable entre plusieurs appareils sans fil (avec des temps de ping très variables dus en grande partie à la perte de paquets) a été un énorme défi. Heureux d'en parler davantage si vous avez un intérêt.
Chaque client peut être une source de données faisant autorité sur lui-même et son environnement immédiat (par exemple des balles).
C'est ce que nous avons fait, et cela a bien fonctionné pour nous dans notre situation (voitures). La partie problématique, bien sûr, est lorsqu'un objet cesse d'être plus proche du joueur «a» que du joueur «b», et sa propriété est donc transférée d'un joueur à un autre.
Il s'agit en fait d'une négociation étonnamment complexe entre les joueurs, où le jeu 'a' propose le jeu 'b': "Je pense que cet objet est plus proche de vous. Vous devriez en prendre le contrôle." Et puis le jeu «b» peut soit accepter, soit décliner, selon sa propre vision de la situation. Les différences dans l'état de jeu perçu entre «a» et «b», et le changement de temps entre le moment où la demande et la réponse sont envoyées et reçues en font une petite négociation particulièrement désagréable pour devenir fiable, et il peut facilement dégénérer en un jeu de "patate chaude", avec la propriété d'objets rebondissant continuellement entre plusieurs joueurs. Et même quand cela fonctionne correctement, vu du point de vue du jeu «c», il »
Mon intuition est que ce type d'approche de «propriété d'objet» risque d'être trop lourd pour les petits objets à courte durée de vie comme les balles. Nous l'avons utilisé pour les voitures de circulation et les coureurs IA, qui ont tendance à vivre dans la simulation pendant une période relativement longue. Il semble qu'une approche plus performante, si vous êtes prêt à faire confiance aux clients, serait que le jeu de chaque joueur soit propriétaire de sa position et de ses projectiles, et de déclarer quand ce joueur a été touché par le projectile de quelqu'un d'autre. (Donc, en tant que "jeu A", je suis responsable de dire où sont les projectiles du joueur A et du joueur A, mais le joueur B est responsable de dire si j'ai touché le joueur B). Avec une bonne estimation, vous devriez pouvoir obtenir un comportement assez raisonnable d'un système comme celui-ci.