20-04-2008, 11:16 PM
En effet le système est assez dur à imaginer... Enfin le plus compliqué à prendre en compte est la différence de connexion des joueurs. Si tous avaient la même connexion, c'est-à-dire qu'ils accédaient à la même page en même temps, ça faciliterait les choses, mais on va faire avec... (moi aussi j'aime me prendre la tête sur des trucs comme ça, après je suis bien fier de ce que j'ai fait ^^).
Cela dit l'avantage premier de l'Ajax, c'est de recharger des morceaux de pages. Donc à ce moment là, autant faire charger un morceau le plus adapté possible à la situation. L'idée c'est d'utiliser PHP et Ajax en parfaite symbiose. (ouh c'est beau ça xD). Bref, partons dans la grande théorie.
Partons d'un cas simple : 3 joueurs (A B C), 2 monstres (M1, M2). Bon y'a plus simple, mais bon comme ça on généralise. Ordre d'initiative : A M1 B M2 C. Pour chaque joueur, un tour : 30 secondes.
/me est en train de se rendre compte qu'il est train de faire aussi sa propre réflexion sur son système de combat pour son RPG xD
Ce que j'ai : une table MySQL indiquant les combats, avec notamment le timestamp du début du combat, et un champ indiquant combien de joueurs sont impliqués, et combien ont "accepté". Chaque joueur possède un rafraichissement toutes les 5 secondes de son état dans le jeu.
Le groupe ABC croise donc les monstres M1 et M2 sur la route. Le joueur A décide d'activer le "mode combat".
Ce mode appelle donc une nouvelle page (par ajax ou non), qui notamment ajoute le combat dans la table SQL, en indiquant que le joueur A accepte le combat et attend les autres (en faisant un rafraichissement toutes les 15 secondes cette fois). Le joueur B, qui a un décalage "de base" de 2 secondes avec A, va donc voir, deux secondes après A, "l'invitation" au combat, qu'il accepte (cela mettant à jour la table SQL). Enfin le joueur C, au décalage de 4 secondes, a l'invitation le dernier, et l'accepte. En gros, 5 secondes après la validation du A, tout le monde a accepté (B ayant accepté entre temps).
10 secondes après l'acceptation de C, le joueur A rafraichit automatiquement. Le serveur lui envoie que tout le monde est prêt, le lancer d'initiative se fait, l'ordre est défini, le timestamp du début de combat est inscrit dans la table SQL : 1000 (pour faire simple).
On dispose d'un outil sur JS, qui permet lui aussi de connaitre le Timestamp au moment où JS le demande. On va s'en servir pour connaître les décalages. L'idée est que, techniquement, malgré les décalages de chaque personnes, on les cale une fois pour toute sur la même fréquence d'actualisation, c'est-à-dire faire en sorte qu'ils rafraichissent tous au même timestamp (à quelque petites choses près ^^). Et ce tout au long du combat.
A commence son tour au timestamp 1000, il le terminera donc à 1030. La résolution du montre M1 étant faite par le serveur, donc en un minimum de temps, on peut estimer qu'elle sera instantanée. B commencera donc son tour à 1030, pour le finir à 1060. M2 : IA donc instantané aussi. C commencera son tour à 1060 pour le finir à 1090.
A partir de là tout est quasi-joué.
A joue donc sont tour à 1000. Pendant ce temps là, B et C sont encore sur l'ancien écran (leur 15 secondes de rafraichissement ne se sont pas encore pleinement écoulé).
A 1015, B et C rafraichissent. Ils voient que A est en train de jouer son tour. Côté "caché", JS se rend compte que mince, on est déjà au Timestamp 1015, donc le prochain tour est à 1030. Le prochain rafraichissement aura donc lieu dans 15 secondes.
A 1030, le tour de A est joué, il est résolu. Par la même occasion, M1 joue son coup, la résolution est aussi faite. A a sa page qui rafraichit, et du coup, B et C également. C'est au tour de B. Pendant ce temps-là, chez A et C, Javascript sait qu'il devra rafraichir à 1060, donc dans 30 secondes. Pas besoin de le faire avant.
A 1060, rafraichissement de A, B et C. Les trois joueurs rafraichissent alors ensemble, tout est synchronisé. A partir de là, tout est vraiment joué... Il suffit de continuer sur la lancée des rafraichissement toutes les 30 secondes.
En gros, voilà comment je ferai. Ca a plusieurs avantages, plusieurs inconvénients.
Avantages :
- C'est JS qui prend l'initiative de recharger, il ne recharge pas dans le vide entre les tours, juste pour demander à PHP si c'est à son tour de jouer. Du coup ça relâche la charge du serveur.
- Dans le cas où, comme je le dis au début, on recharge vraiment que ce qu'on l'a besoin (c'est-à-dire les données brutes, les messages pouvant être gérés par JS), la technique est, je pense assez fiable. Il y a peu de chance que le décalage entre chaque joueur soit énorme, sauf si le serveur peine un peu...
Inconvénients :
- Cette technique, comme tu l'auras deviné, fait que les joueurs rechargent en même temps, pour faire la même requête "Est-ce à moi de Jouer?". Cette page étant demandée en même temps par 3 personnes, il va falloir faire en sorte qu'elle soit hyper-optimisée... Sait-on jamais, peut-être auras-tu à gérer des combats avec plus de 40 joueurs... A ce moment là la même page sera demandée 40 fois en même temps... Ca devra assurer autant côté PHP que MySQL...
- La limite de temps est constante, c'est-à-dire que même si un joueur envoie son ordre dans les 10 premières secondes, tous les joueurs n'auront le résultat que 20 secondes plus tard... Bah, pourquoi ne pas en profiter pour faire un peu de RP? (genre jeter une phrase du genre "MOUAHAHAHA TU VAS MOURIR SALE GOBELIN!" sur le chat ^^). Ca remplira parfaitement les 20 secondes pour le joueur, et dans tous les cas, les deux autres attendront 30 secondes... Après il faut trouver le bon timing au niveau des tours, pour qu'ils ne soient ni trop long, ni trop courts...
Bref, voilà comment je ferai moi, et je le ferai sans doute pour mon projet, car c'est pour moi l'une des meilleures solutions sur le rapport charge serveur / "impression" de temps réel / plaisir de jouer.
Amicalement,
Lanwin, content de sa tirade...
Cela dit l'avantage premier de l'Ajax, c'est de recharger des morceaux de pages. Donc à ce moment là, autant faire charger un morceau le plus adapté possible à la situation. L'idée c'est d'utiliser PHP et Ajax en parfaite symbiose. (ouh c'est beau ça xD). Bref, partons dans la grande théorie.
Partons d'un cas simple : 3 joueurs (A B C), 2 monstres (M1, M2). Bon y'a plus simple, mais bon comme ça on généralise. Ordre d'initiative : A M1 B M2 C. Pour chaque joueur, un tour : 30 secondes.
/me est en train de se rendre compte qu'il est train de faire aussi sa propre réflexion sur son système de combat pour son RPG xD
Ce que j'ai : une table MySQL indiquant les combats, avec notamment le timestamp du début du combat, et un champ indiquant combien de joueurs sont impliqués, et combien ont "accepté". Chaque joueur possède un rafraichissement toutes les 5 secondes de son état dans le jeu.
Le groupe ABC croise donc les monstres M1 et M2 sur la route. Le joueur A décide d'activer le "mode combat".
Ce mode appelle donc une nouvelle page (par ajax ou non), qui notamment ajoute le combat dans la table SQL, en indiquant que le joueur A accepte le combat et attend les autres (en faisant un rafraichissement toutes les 15 secondes cette fois). Le joueur B, qui a un décalage "de base" de 2 secondes avec A, va donc voir, deux secondes après A, "l'invitation" au combat, qu'il accepte (cela mettant à jour la table SQL). Enfin le joueur C, au décalage de 4 secondes, a l'invitation le dernier, et l'accepte. En gros, 5 secondes après la validation du A, tout le monde a accepté (B ayant accepté entre temps).
10 secondes après l'acceptation de C, le joueur A rafraichit automatiquement. Le serveur lui envoie que tout le monde est prêt, le lancer d'initiative se fait, l'ordre est défini, le timestamp du début de combat est inscrit dans la table SQL : 1000 (pour faire simple).
On dispose d'un outil sur JS, qui permet lui aussi de connaitre le Timestamp au moment où JS le demande. On va s'en servir pour connaître les décalages. L'idée est que, techniquement, malgré les décalages de chaque personnes, on les cale une fois pour toute sur la même fréquence d'actualisation, c'est-à-dire faire en sorte qu'ils rafraichissent tous au même timestamp (à quelque petites choses près ^^). Et ce tout au long du combat.
A commence son tour au timestamp 1000, il le terminera donc à 1030. La résolution du montre M1 étant faite par le serveur, donc en un minimum de temps, on peut estimer qu'elle sera instantanée. B commencera donc son tour à 1030, pour le finir à 1060. M2 : IA donc instantané aussi. C commencera son tour à 1060 pour le finir à 1090.
A partir de là tout est quasi-joué.
A joue donc sont tour à 1000. Pendant ce temps là, B et C sont encore sur l'ancien écran (leur 15 secondes de rafraichissement ne se sont pas encore pleinement écoulé).
A 1015, B et C rafraichissent. Ils voient que A est en train de jouer son tour. Côté "caché", JS se rend compte que mince, on est déjà au Timestamp 1015, donc le prochain tour est à 1030. Le prochain rafraichissement aura donc lieu dans 15 secondes.
A 1030, le tour de A est joué, il est résolu. Par la même occasion, M1 joue son coup, la résolution est aussi faite. A a sa page qui rafraichit, et du coup, B et C également. C'est au tour de B. Pendant ce temps-là, chez A et C, Javascript sait qu'il devra rafraichir à 1060, donc dans 30 secondes. Pas besoin de le faire avant.
A 1060, rafraichissement de A, B et C. Les trois joueurs rafraichissent alors ensemble, tout est synchronisé. A partir de là, tout est vraiment joué... Il suffit de continuer sur la lancée des rafraichissement toutes les 30 secondes.
En gros, voilà comment je ferai. Ca a plusieurs avantages, plusieurs inconvénients.
Avantages :
- C'est JS qui prend l'initiative de recharger, il ne recharge pas dans le vide entre les tours, juste pour demander à PHP si c'est à son tour de jouer. Du coup ça relâche la charge du serveur.
- Dans le cas où, comme je le dis au début, on recharge vraiment que ce qu'on l'a besoin (c'est-à-dire les données brutes, les messages pouvant être gérés par JS), la technique est, je pense assez fiable. Il y a peu de chance que le décalage entre chaque joueur soit énorme, sauf si le serveur peine un peu...
Inconvénients :
- Cette technique, comme tu l'auras deviné, fait que les joueurs rechargent en même temps, pour faire la même requête "Est-ce à moi de Jouer?". Cette page étant demandée en même temps par 3 personnes, il va falloir faire en sorte qu'elle soit hyper-optimisée... Sait-on jamais, peut-être auras-tu à gérer des combats avec plus de 40 joueurs... A ce moment là la même page sera demandée 40 fois en même temps... Ca devra assurer autant côté PHP que MySQL...
- La limite de temps est constante, c'est-à-dire que même si un joueur envoie son ordre dans les 10 premières secondes, tous les joueurs n'auront le résultat que 20 secondes plus tard... Bah, pourquoi ne pas en profiter pour faire un peu de RP? (genre jeter une phrase du genre "MOUAHAHAHA TU VAS MOURIR SALE GOBELIN!" sur le chat ^^). Ca remplira parfaitement les 20 secondes pour le joueur, et dans tous les cas, les deux autres attendront 30 secondes... Après il faut trouver le bon timing au niveau des tours, pour qu'ils ne soient ni trop long, ni trop courts...
Bref, voilà comment je ferai moi, et je le ferai sans doute pour mon projet, car c'est pour moi l'une des meilleures solutions sur le rapport charge serveur / "impression" de temps réel / plaisir de jouer.
Amicalement,
Lanwin, content de sa tirade...