Système de combat "en direct"

[Valter]

Bonjour à tous,

voilà, je rencontre une certaine difficulté dans la création d'un système de combat "en direct", pour mon jeu.
En gros, tour à tour, les deux joueurs s'attaquent (avec différentes options, différents algos,etc...). quelle originalité !
Seulement voilà, lorsqu'un joueur attaque l'autre (à partir de la page pvp), cette "attaque" (avec ses options,etc...) passe par ce schéma :

Code :

pvp => ajax.js => ajax.php => class_joueur.php => bdd => class_joueur.php => ajax.php => ajax.js => pvp.

Toutes les attaques se déroulent à l'aide de curl et/ou ajax (pas de rechargement de page).
Deux personnages (de la classe Joueur) sont mis en jeu, lors d'une attaque :
- celui qui attaque
- celui qui se prend les dégâts

Pour ce qui est des updates dans les bases de données, là il n'y a aucun problème.
Pour ce qui est du xhtml/javascript (en gros ce que voient les joueurs sur leur page pvp), le but étant d'actualiser la barre de santé,etc...
- Pour celle de l'attaquant, rien de plus simple, il suffit de renvoyer les valeurs depuis la page ajax.php
- En revanche, pour celle du "défenseur" je ne vois absolument pas comment.
J'ai pensé, mais je trouve cette solution assez nulle, de faire des requêtes toutes les 5, 10 ou 15 secondes vers la page ajax.php (en gros, pour "voir s'il s'est fait attaqué").

Voyez-vous une autre solution ?

Merci infiniment,

PS : Si je n'ai pas été assez clair en concis, faites le moi savoir. Mais il est vrai que c'est assez difficile à expliquer.

[keke]

Coucou,

Un système pourrait être de développer un peu plus cette solution "assez nulle". Au lieu de vérifier si tel joueur a reçu des dommage, ça serait de "voir" s'il y a eu des actions depuis sa dernière requête. Ainsi, par action, on peut sous entendre du Tchat, un évènement scénaristique programmé, un sort avec un effet visuel à proxymité.

Kéké qui ne voit pas vraiment d'autres solutions.

[Holy]

Y a l'éternel solution des flags qui pour moi reste la meilleure d'un point de vue optimisation.

J'ai créé plusieurs jeux multijoueurs de ce type (puissance 4, stratégo, uno) et j'utilisais un bête système de flag qui est beaucoup moins gourmand qu'une requête ou autre.

En gros lorsqu'il y a un changement, tu crées un fichier avec l'id du joueur. Dans le script ça donne que si le fichier existe c'est qu'il faut faire une mise à jour de certaines valeurs, si il n'existe pas, y a rien qui se passe.

Du coup, après ça pose plus trop de problème pour les perfs. Même en lookant une fois toutes les 5 secondes, bah c'est jamais qu'une simple petit verif de rien du tout, plutôt légère. Avec l'avantage que tu peux préciser dans ton fichier les données à mettre à jour: "pv-mana-..."

Sinon, y a la solution des sockets en php. C'est un peu moins drôle à travailler techniquement, mais c'est intéressant niveau perf.

[Valter]

Tout d'abord, merci de vos réponses.

Pour les flags, ça risque de remettre en cause tout ce que j'avais développé jusque là, sur ce module.

Pour les sockets en php (ou bien curl, non ?), c'est ce à quoi j'avais pensé mais le problème va être que rien ne différencie la page pvp de l'attaquant de celle du "défenseur", mis à part les sessions de chaque. Et puis, comment récupérer la valeur (POST ou GET) envoyée par la socket (ou curl), avec un langage client (javascript) ?
Puisque là est le but, faire à ce qu'il n'y ait pas de rechargement de la page pendant un combat.

Merci encore,

[X-ZoD]

je me susi deja confronté a cette question...
j'y avais trouvé que deux solution
- socket
- check des modifications toutes les x secodnes (moi c'etait 5 secondes)

je rejoins holy pour la queston des check.. c'est a dire que aprs li faut penser performances
tu peu faire une requetes sql toutes les x secondes ou bien checker un fichier cré au paravant par l'autre joueur chaque fois qu'il lance une attaque

voila ... pour ma part je pense que je vais prendre l'option des fichiers
mais je ne saurai en dire plus (si cest une bonne idee) car faut penser a la securite, a la triche, etc ...

[Valter]

Oui, merci, je crois que moi aussi je vais utiliser les checks (je me débrouillerais avec des fichiers temporaires).

Mais juste une question, comment procéderiez-vous pour faire ce genre de système avec les sockets ? Puisque, comme je l'ai dis, rien ne différencie la page pvp de l'attaquant de celle du "défenseur", mis à part les sessions de chaque. Et puis, comment récupérer la valeur (POST ou GET) envoyée par la socket (ou curl), avec un langage client (javascript) ?

Merci encore,

[X-ZoD]

pour les socket tu peux trouvé plein de bon tuto online
moi j'ai abandonné car j'ai l'impression que mon serveur a une config qui empeche son utilisation (au niveau de l'adresse je crois )
j'espere que toi ca se passera mieux

[Allwise]

J'ai eu le même problème, et j'ai choisi la solution des sockets, que j'ai plus le temps de développer d'ailleurs...
Pour mettre ça en place, il te faut développer un serveur, en PHP ou ce que tu veux, et un client, que tu fais en Flash, (ou peut-être sous forme d'applet Java). En Javascript ce n'est pas possible, ça gère pas les sockets.

En fait si tu passes par les sockets, y a plus de POST ni de GET, tu implémentes ton propre langage client / serveur. Les joueurs se connectent à ton serveur, s'identifient, et dialoguent avec lui avec un langage que tu as toi-même défini. Tu peux faire transmettre tes données via XML, en Json, ou sous la forme talkToNpc(3)... Tu es liiibre ! ^^

Mais pour pouvoir utiliser cette solution, il faudra que le serveur tourne sans relâche, ce qui implique un accès shell sur ton hébergement donc a priori une solution dédiée. Y a d'autres contraintes, liées à la performance et à la sécurité qui sont pète burnes à prendre en compte. Je sais pas si c'est une bonne solution, je ne connais pas de jeu qui tourne comme ça.

Y a aussi une 3ème méthode, qui est un compromis entre le refresh ajax et les sockets : le long polling, ou encore reverse ajax, ou encore comet, qui consiste à faire établir une connexion continue entre le serveur et le client en laissant tourner une requête Ajax en fond, jusqu'à ce qu'il se passe quelque chose et que le serveur renvoie une réponse au client. Si rien n'arrive et que la requête Ajax timeout, zou elle repart direct. C'est le système utilisé par facebook pour leur chat instantané. Mais ça implique aussi une configuration pointue de son serveur.

[X-ZoD]

interessant la derniere solution . je vais me pencher dessus

[lcfseth]

Cette methode consomme beaucoup de ressource serveurs. à utiliser avec moderation