JeuWeb - Crée ton jeu par navigateur
Push : Réception de donnée - Version imprimable

+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Push : Réception de donnée (/showthread.php?tid=5976)

Pages : 1 2 3


Push : Réception de donnée - Zack - 12-02-2012

Bonjour,

Ca fait depuis plus d'un an que je m’intéresse au push et au socket. J'ai eu pas mal de déboire avec ces technologies. Faute de ne pas avoir réussi à installer APE ou Juggernaut sur mon serveur, je ne suis pas très doué en administration serveur, à chaque fois, il manque des packets ou une erreur survient, je me suis dirigé vers du beaconpush.

J'avais donc refait tout mon système de map pour supporter le push, tout avait l'air de fonctionner. Mais lorsque je l'ai mis en ligne pour les joueurs, certains n'arrivaient pas à voir les personnages des autres bouger, etc...

De ce fait, j'ai l'impression que la réception de données ne se faisait pas par moment. Est ce possible ? (Il est probable que ce soit mon système qui n'était pas au point aussi avec le push)

Ma question principale donc est comment s'assurer qu'une donnée est bien reçue par les autres joueurs ?


RE: Push : Réception de donnée - Anthor - 13-02-2012

Il me semble qu'il serait bon de commencer par poser la question à BeaconPush, ils doivent avoir une garantie sur l'envoi des données.

Peut-être que certains de tes joueurs qui ne reçoivent pas de réponses n'ont pas un navigateur compatible ?
Quels genre de tests as-tu réalisés ?


RE: Push : Réception de donnée - Zack - 13-02-2012

La plupart avaient un navigateur de dernière génération. Je leur avais même demandé de tester sous différents navigateurs.

En fait, c'est une carte en flash où on voit tous les joueurs se déplacer, on voit aussi les animations des joueurs lorsqu'il lance un sort, etc..
Il devait y en avoir une bonne dizaine de joueurs au même endroit entrain de jouer, et c'est là que ça foire, moi même je ne voyais pas tous les joueurs bougeaient alors qu'ils s'étaient bien déplacé.

C'est possible qu'une donnée se perde et n'arrive pas jusqu'au joueur ? J'ai d'ailleurs remarqué que parfois entre le temps de la réception d'une donnée et le temps que la connexion se relance, je ne recevais pas les données qui avaient été envoyé entre ces 2 moments.

Mais alors que faut-il faire ? Envoyer toutes les secondes, l'envoi de toutes les positions des joueurs pour refixer tout ça sur la carte ? Ce serait lourd non ?


RE: Push : Réception de donnée - keke - 13-02-2012

Je ne connais pas le framework ... et je parle donc dans le vide.

Une synchro semble un bon plan, mais uniquement tous les X secondes. (une fois par minute par exemple, en fonction de la consommation en ressource).
Ensuite, un système d'évenement est une méthode pas trop lourde pour gérer ce type de problèmatique. Selon la manière de procéder, ça peut même être très léger.
L'idée principale étant d'enregistrer dans une table, toutes les actions de manière minimaliste :
1 - joueur toto - heure - deplacement - coordonnée X, coordonnée Y, X_origine, Y_origine, id_animation
2 - joueur titi - heure - deplacement - coordonnée X, coordonnée Y, X_origine, Y_origine, id_animation
3 - joueur toto - heure - deplacement - coordonnée X, coordonnée Y, X_origine, Y_origine, id_animation
4 - joueur toto - heure - lance un sort - coordonnée X, coordonnée Y, NULL, NULL, id_animation
5 - monstre - heure - apparait spontanément - coordonnée X, coordonnée Y, NULL, NULL, id_animation

Ensuite, chaque joueur récupère la liste des évènements et en déduit les actions à afficher.
1°/ suis-je concerné (en fonction des coordonnées) ?
2°/ Je joue l'animation correspondant aux évènements me concernant (celle qui sont donc visible)
3°/ Ok : j'ai récupéré toutes les actions jusqu'à l'étape 5. Dans une seconde, je vais chercher les actions supérieur ou égale à l'étape 6 et je recommance à l'étape 1°

Resynchroniser pourrait alors être fait toutes les minutes, et à chaque déplacement.

Un tel système ne devrait pas poser de problème, même avec 2000 joueurs simultané, car le requêtage est très léger (une table qui ne fait que s'incrémenter à chaque action + un index léger. Pas de requêtage pour déterminer l'ensemble des éléments visibles, sauf à l'initialisation et à la synchro toutes les minutes)

kéké


RE: Push : Réception de donnée - Ter Rowan - 13-02-2012

(13-02-2012, 12:43 PM)keke a écrit : Ensuite, chaque joueur récupère la liste des évènements et en déduit les actions à afficher.
1°/ suis-je concerné (en fonction des coordonnées) ?
2°/ Je joue l'animation correspondant aux évènements me concernant (celle qui sont donc visible)
3°/ Ok : j'ai récupéré toutes les actions jusqu'à l'étape 5. Dans une seconde, je vais chercher les actions supérieur ou égale à l'étape 6 et je recommance à l'étape 1°


le 1) devrait être côté serveur. Ce n'est pas au client de valider si il doit voir ou non un événement (sinon avantage au bidouilleur par rapport au joueur "standard" qui captera des informations qu'il n'a pas d'un point de vue gp à voir)


RE: Push : Réception de donnée - keke - 13-02-2012

Je ne sais pas comment fonctionne ton script. Mais de manière asynchrone, c'est la requête envoyée au client, avec les coordonnées du joueur qui permet de déterminer les évents à récupérer.

"select * from table_event where id_event > '$mon_id_event_local' AND x between , and y between ,"

Normalement un bidouilleur n'a pas possibilité de gruger ... non ?

kéké qui est parfois très naif.


RE: Push : Réception de donnée - Ter Rowan - 13-02-2012

(13-02-2012, 05:23 PM)keke a écrit : Je ne sais pas comment fonctionne ton script. Mais de manière asynchrone, c'est la requête envoyée au client, avec les coordonnées du joueur qui permet de déterminer les évents à récupérer.

"select * from table_event where id_event > '$mon_id_event_local' AND x between , and y between ,"

Normalement un bidouilleur n'a pas possibilité de gruger ... non ?

kéké qui est parfois très naif.

(pas mon script, je réagissais juste à ton post)

tu dis :
Citation :Ensuite, chaque joueur récupère la liste des évènements et en déduit les actions à afficher.
1°/ suis-je concerné (en fonction des coordonnées) ?

je le comprends comme :

j'envoie tous les événements possibles au navigateur "chaque joueur récupère la liste des évènements" ==> select * from table_event where id_event > '$mon_id_event_local'

puis le navigateur (via le "programme client") vérifie si oui ou non l’événement concerne le joueur " et en déduit les actions à afficher." donc y a pas de between dans ton sql, mais du javascript, ou flash, ou je sais quoi qui traite l'affichage

c'est complètement différent que de faire côté serveur la requête sql avec le between(qui de fait sera différente par joueur ou par groupe de joueur)


RE: Push : Réception de donnée - Argorate - 13-02-2012

Bin voyons... Donc on envoi un max d'info inutile, on perd du temps et on charge le serveur, et en plus on donne des infos potentiellement secrète/confidentiel (surtout s'il s'agit de jeu de stratégie) à tout le monde en disant ce que chaque joueur a fait?! (un bidouilleur peut très bien allez voir se que l'ajax a renvoyé, et si - comme il est suggéré, il renvoi tout, alors il a accès à tout se qui se passe de partout... pas très malin selon moi Smile ou en tout cas c'est risqué et non optimisé).


RE: Push : Réception de donnée - keke - 14-02-2012

>>> Ter rowan

Bon, je vais editer mon post :

1°/ suis-je concerné (en fonction des coordonnées) ?
=> une requête AJAX en fonction de mon id_joueur. Côté server on récupère les infos et on les renvoie.
"select * from table_event where id_event > '$mon_id_event_local' AND x between , and y between ,"

Ca te semble plus correcte ? S'il le faut, on peut hasher les informations en entrée et en sortie pour les petits malins. (perso, je ferais pas.)

kéké




RE: Push : Réception de donnée - Ter Rowan - 14-02-2012

oui :p c'était juste un problème de compréhension, mais autant lever les incertitudes