Déplacement temps réel

[jean-baptiste]

Bonjour,
Je suis actuellement entrain de faire des petits tests sur des déplacement en temps réel sur une carte. Un petit personnage est dirigeable sur une carte via les touches du clavier. Cependant je me pause la question du rafraîchissement en base et de l'affichage simultané d'autre joueurs. Je ne veux pas à chaque évènement de touche mettre à jour ses coordonnées en base car je trouve que cela fait énormément de requête.

Voici donc mes questions:
- Quand sont mis à jour les coordonnées d'emplacement du joueurs
- Comment afficher les déplacements des autres joueurs

Le tout bien sur est d'optimiser au maximum les requêtes en base.

Cordialement,
Jean-Baptiste.

[Sephi-Chan]

Dès qu'un joueur effectue l'action de déplacement côté client, tu envoies une requête Ajax vers ton serveur. Celui-ci n'a plus qu'à pusher la nouvelle position aux joueurs à proximité.

Le problème si tu n'écris rien en base, c'est que tu n'as aucune persistence : si le joueur recharge la page, tu ne sais pas où le placer (ni même sur la carte des autres joueurs).
Tu dois de toute façon faire une série de requête quand un joueur tente de se déplacer : ne serait-ce que pour tester la validité du déplacement.

Tu l'auras compris, te passer de persistence n'est pas pertinent. De plus, je ne comprends pas pourquoi tu cherches à l'éviter. Ça fait beaucoup de requêtes. Et alors ? On ne t'arrache pas un ongle par requête effectuée. Tu cherches à traiter un non-problème.

Le jour où ta base ne tient plus le rythme des écritures, tu pourras penser à utiliser un système de stockage plus efficace en écriture (MongoDB et Redis sont de bons prétendants).

Eviter les requêtes n'est pas un besoin dans ton cas, c'est seulement une envie.
L'optimisation prématurée n'est pas une bonne chose.

[jean-baptiste]

Ok alors
Tu peux développer le push ajax coté serveur ?

Cordialement,
Jean-Baptiste

[t.bodeux]

Dépend de ta disponibilité à installer un système de PUSH comme juggernaut qui nécessite un dédié. Sinon, il existe des alternatives telles que Pusher, Pubnub ou encore BeaconPush.

[Sephi-Chan]

Le push permet d'envoyer des informations depuis le serveur vers les clients. Pour cela, on utilise un serveur tiers (comme Juggernaut, Faye et plein d'autres, ainsi que des services tels que PubNub ou Pusher, mais c'est souvent moins bien) qui est taillé pour recevoir et de maintenir plusieurs connexions (au contraire d'un serveur Web classique qui est conçu pour des connexions assez courtes).

Le principe est donc qu'une fois sur ta page, les visiteurs établissent une connexion persistente avec ton serveur de push. Ainsi, quand ton application a besoin d'envoyer des données à l'utilisateur, elle n'a qu'à les transmettre au serveur de push qui se charge de les relayer.

Pour savoir à qui envoyer quoi, on utilise souvent la métaphore des canaux : un client peut écouter un ou plusieurs canaux. Par exemple, dans Conquest on Rails, quand un joueur s'inscrit à une partie, je lui fais écouter le canal games/:game_id pour qu'il soit notifier de ce qui se passe sur la partie. Il écoute également le canal players/:player_id/ecret_token pour ses propres notifications.

Comme tu peux le voir, j'utilise un jeton propre au joueur pour rendre le canal secret : ainsi, si je suis le joueur 2, je ne peux pas écouter les messages destinés au joueur 1 car je ne connais pas son jeton, et donc je ne sais pas quel canal écouter.

À l'inverse, le canal de jeu est publique, n'importe qui peut lancer une écoute dessus (à condition d'en connaître l'ID) car les informations qui y transitent ne sont pas sensibles : tous ceux qui l'écoutent reçoivent la même chose.

[jean-baptiste]

Ok je comprend la principale. J'ai regardé un certain script APE vous connaissez ?

http://www.ape-project.org/

[Sephi-Chan]

Oui mais c'est pas très bien. Des solutions plus ouvertes existent. Par exemple Juggernaut est basé sur Redis, et du coup est compatible avec tous les langages qui disposent d'un client Redis (en gros, tous).

APE c'est toujours obscur, il faut déchiffrer la documentation. Berk !

[atra27]

+1, la doc de APE est illisible et incompréhensible a mon gout!

J'ai pas testé juggernaut, mais j'ai eu de bons avis d'un ami dev.
J'ai aussi entendu parler de node.js (il me semble qu'il y a un sujet sur node.js et socket.io sur ce forum)
Je l'ai testé, ça tourne bien et en peu de ligne de code on peut avoir une base qui marche.
Aprés, je n'ai pas essayé bien loin pour donner un avis complet (faute de temps.... y me faudrais des jours de 48 heures!)

Je te conseille de regarder du coté de ces deux la!

[Sephi-Chan]

La plupart des serveurs de push (en Javascript) sont basés sur Node.

[Enlil]

Voici la solution que j'ai adopté pour ma part.

Frontend en js, qui, toutes les 100ms, envoie au serveur les déplacements du joueur, et récupère du même coup les infos des autres joueurs pour rafraîchir. Seules les infos concernant les joueurs ou éléments de décors qui doivent être affichés sont récupérées, pas celles concernant tous les éléments/joueurs de la map entière (vu que seule une partie de la map est visible à un temps donné). C'est le script côté serveur qui détermine quels éléments sont visibles par le joueur ou pas en fonction de sa position.

Côté serveur (en python), les infos relatives à tous les joueurs et éléments sont stockées dans un structure de données de type "dictionnaire" (en PHP ou autre ce serait un tableau multidimensionnel), qui est stocké en cache (avec memcache).

Le cache permet donc une pestistance, les données ne foutent pas le camp même si je redéploie l'app (vu que memcache stocke tout ça ailleurs), mais bien sûr si le serveur crash tout est perdu. Donc j'envisage une mise à jour de la bdd toutes les minutes, quelque chose comme ça.

Je serais curieux de l'avis de la communauté sur ce système, dans quelle mesure est-ce que ça vous semble "scalable", ou au contraire si ça vous semble assez barbare et inefficace. Je suis content d'éviter de trop agresser la db (car dans une ancienne version où tout était stocké dans la db, 10 requêtes par seconde par joueur ça se voyait quand même aux performances du truc, on m'arrachait pas d'ongles mais bon c'était pas intéressant). Ceci dit je ne fais que déplacer le problème en remplaçant la db par le cache. Ceci dit l'accès au cache est beaucoup plus rapide que l'accès à une bdd. Mais si le projet prend de l'ampleur, peut-être que se reposer de la sorte sur le cache deviendra inenvisageable...

J'attends avec plaisir vos remarques.

Edit : J'ai une démo à montrer mais tout d'un coup les arbres ne s'affichent plus... je balance l'URL dès que ça remarche.