20-04-2014, 06:19 AM
De mon point de vue, le combat se déroule de toutes façons dans ton serveur. Les joueurs (qu'ils jouent en temps réel ou au tour par tour) vont envoyer les actions au serveur, qui va les traiter et envoyer en retour la réponse (IE : le nouvel état du combat) à tous les joueurs.
La façon exacte de procéder dépend de ton type de combat. Quelques exemples :
- Combat au tour par tour, méthode simple, sans même javascript : Les joueurs ont un temps défini pour effectuer leurs actions, par exemple une minute. Le serveur garde trace (si tu part sur un jeu php / sql simple sans accès ou quoi au serveur pour faire du persistant, via une table "combats" dans la base de données) de qui a le droit de jouer. Chaque minute, la fenêtre du combat s'actualise pour mettre à jour le tour et indiquer l'action de l'autre. Ce système permet par exemple de faire un combat du type "heartstone", en un contre un.
- Combat au tour par tour plus lent : même principe que précédemment, sans l'actualisation de la fenêtre. Dans cet exemple, il n'y a plus de temps limité pour un joueur ; il agit quand l'autre a agit, et cela envoi un message à son adversaire pour lui dire d'agir. Le workflow devient donc : Joueur A joue => joueur B reçoit un message lui disant qu'il peut jouer => Joueur B joue => Joueur A reçoit un message lui disant qu'il peut jouer. L'inconvénient de cette méthode est que le combat devient très lent.
- Combat en temps réel avec action chronométrées : ici, les deux joueurs ont le choix de leurs actions et ne dépendent pas de l'adversaire. On suppose que le joueur ayant accepté reste devant son écran pour le combat. Il va donc effectuer ses actions quand elles sont prêtes, et la fenêtre de combat sera périodiquement rafraîchie pour mettre à jour l'état du combat. Cette méthode a l'avantage d'être plus agréable pour le joueur, mais l'inconvénient d'être assez lourde.
-Utilisation de websockets : On en arrive maintenant à la méthode que je trouve la plus propre pour gérer ce genre de choses. Le principe est ici un peu différent et nécessite un accès plus grand qu'un simple hébergement web. L'idée va être de faire tourner un serveur persistant, sur lequel tes clients vont se connecter en websocket. Une websocket est une connexion réseau persistante ; tu n'as plus de chargement de page, mais uniquement des données qui vont dans un sens ou dans l'autre. Tu trouveras un exemple d'implémentation ici : https://code.google.com/p/phpwebsocket/ . L'intérêt de cette méthode est qu'elle ne dépend pas d'actualisation chronométrée de page ; à la place, le combat se déroule au même titre que dans un mmorpg classique, avec l'envoi des données en direct. Ici, c'est le serveur de websocket qui garde en mémoire ton combat en cours (plus besoin de le stocker en base de données ; c'est une bonne chose car ces données sont temporaires et l'accès à la base de données est plus lent que l'accès à la ram). Les connexions en websocket étant identifiées, il peut associer un joueur à un combat ; et le workflow devient donc : Joueur fait une action => Javascript envoi l'action au serveur => Serveur traite l'action => Serveur envoi les nouvelles données aux clients des joueurs. Techniquement, le code est un peu plus complexe, mais le résultat est nettement plus agréable pour les visiteurs.
Je ne détail pas plus car je ne suis pas certain que ce soit exactement cela que tu veux comme réponse ; mais si oui, n'hésites pas à préciser quelle(s) solution(s) te plais(ent), et je la détaillerais volontiers plus !
La façon exacte de procéder dépend de ton type de combat. Quelques exemples :
- Combat au tour par tour, méthode simple, sans même javascript : Les joueurs ont un temps défini pour effectuer leurs actions, par exemple une minute. Le serveur garde trace (si tu part sur un jeu php / sql simple sans accès ou quoi au serveur pour faire du persistant, via une table "combats" dans la base de données) de qui a le droit de jouer. Chaque minute, la fenêtre du combat s'actualise pour mettre à jour le tour et indiquer l'action de l'autre. Ce système permet par exemple de faire un combat du type "heartstone", en un contre un.
- Combat au tour par tour plus lent : même principe que précédemment, sans l'actualisation de la fenêtre. Dans cet exemple, il n'y a plus de temps limité pour un joueur ; il agit quand l'autre a agit, et cela envoi un message à son adversaire pour lui dire d'agir. Le workflow devient donc : Joueur A joue => joueur B reçoit un message lui disant qu'il peut jouer => Joueur B joue => Joueur A reçoit un message lui disant qu'il peut jouer. L'inconvénient de cette méthode est que le combat devient très lent.
- Combat en temps réel avec action chronométrées : ici, les deux joueurs ont le choix de leurs actions et ne dépendent pas de l'adversaire. On suppose que le joueur ayant accepté reste devant son écran pour le combat. Il va donc effectuer ses actions quand elles sont prêtes, et la fenêtre de combat sera périodiquement rafraîchie pour mettre à jour l'état du combat. Cette méthode a l'avantage d'être plus agréable pour le joueur, mais l'inconvénient d'être assez lourde.
-Utilisation de websockets : On en arrive maintenant à la méthode que je trouve la plus propre pour gérer ce genre de choses. Le principe est ici un peu différent et nécessite un accès plus grand qu'un simple hébergement web. L'idée va être de faire tourner un serveur persistant, sur lequel tes clients vont se connecter en websocket. Une websocket est une connexion réseau persistante ; tu n'as plus de chargement de page, mais uniquement des données qui vont dans un sens ou dans l'autre. Tu trouveras un exemple d'implémentation ici : https://code.google.com/p/phpwebsocket/ . L'intérêt de cette méthode est qu'elle ne dépend pas d'actualisation chronométrée de page ; à la place, le combat se déroule au même titre que dans un mmorpg classique, avec l'envoi des données en direct. Ici, c'est le serveur de websocket qui garde en mémoire ton combat en cours (plus besoin de le stocker en base de données ; c'est une bonne chose car ces données sont temporaires et l'accès à la base de données est plus lent que l'accès à la ram). Les connexions en websocket étant identifiées, il peut associer un joueur à un combat ; et le workflow devient donc : Joueur fait une action => Javascript envoi l'action au serveur => Serveur traite l'action => Serveur envoi les nouvelles données aux clients des joueurs. Techniquement, le code est un peu plus complexe, mais le résultat est nettement plus agréable pour les visiteurs.
Je ne détail pas plus car je ne suis pas certain que ce soit exactement cela que tu veux comme réponse ; mais si oui, n'hésites pas à préciser quelle(s) solution(s) te plais(ent), et je la détaillerais volontiers plus !