Créer un jeu sur maps, existe t-il une alternative à ajax ?

[mang1]

Bonjour,

Imaginons un jeu type mmorpg qui serait jouable sur navigateur, comment faudrait-il recharger les maps (pour les déplacements des joueurs entre autre) ?

Je pensais à ajax, mais outch, il faudrait constamment envoyer une requête au serveur pour savoir où sont les personnages sur la map, ça prend du temps et ça demande énormément de traitement, 50 personnes sur une même map ce serait au moins 50 requêtes par seconde avec autant de requêtes sql et de traitement php.

Vous qui avez de l’expérience dans le domaine, pouvez-vous m'éclairer, qu'utilisez-vous ?


J'ai entendu parlé des websockets, mais c'est tellement incompatible avec les navigateurs actuels que ce n'est même pas pensable.

Mise à par ça... rien.

Bref, j'aimerai savoir comment vos jeux fonctionnent.


Merci d'avance.


PS : je cherche des solution applicables en php et javascript, je ne connais aucun autre langage et je souhaite d'abord me perfectionner dans ces deux-là en créer un petit jeu avant de me lancer dans autre chose (java et ruby sûrement).

[quentin01]

Websockets non-crossbrowser ? En natif peut être, mais avec une librairie non ! http://socket.io/#browser-support ( Tu peux voir que même IE 6 est supporté comme quoi c'est vraiment très très compatible ). En tous cas si tu utilises les Websockets il faut bien te rendre compte que derrière il faut un serveur, pas un simple hébergement mais bien un log' qui tourne 24 / 24 pour recevoir les sockets et renvoyer des réponses. ( Node.JS + Socket.io c'est vraiment super \o )

Après il reste aussi les système de push en Javascript.

[Sephi-Chan]

Hello,

Effectivement, la récupération régulière d'information — aussi appelée polling — est une technique fonctionnelle, mais plutôt inefficace. En effet, on y gâche énormément de ressources.

Une technique plus efficace consiste à envoyer des données du serveur vers les clients pour les informer d'un changement, c'est ce qu'on appelle le push. L'utilisation de Websocket fait effectivement partie de cette catégorie.

Contrairement à ce que tu crois, les Websocket sont déjà très répandus, puisque très bien supporté par Chrome et Firefox (et bientôt IE10), avec un support correct de Safari et Opera. On a donc déjà un taux de support conséquent.

De nombreuses librairies Javascript permettent d'abstraire le mécanisme de réception des données de façon à utiliser différents protocoles, selon ce que supporte le navigateur client. Parmi ces techniques.

• WebSocket, la meilleure technique.
  
• Adobe Flash Socket, qui passe par Flash.
  
• XHR long-polling, de l'Ajax tout simple, qui marche partout.
  
• Server-Sent Events, notamment utilisé par Opera.
  
• ActiveX HTMLFile, pour les vieilles version d'IE.
  

Depuis quelques années, le push se démocratise. Plusieurs services tiers te permettent d'en faire à moindre frais (souvent rien du tout pour des apps en développement ou petites).

• PubNub
  
• BeaconPush
  
• Pusher
  
• Etc.
  

Après, le must est encore d'avoir un serveur dédié et d'y installer un serveur de push.

• Juggernaut
  
• SocketIO
  
• Faye
  
• Etc.
  

La plupart sont bâties sur un serveur Node (donc du Javascript server side) et un client (souvent basé sur Socket.IO). Ils sont généralement accessibles via une API. En ce qui me concerne, c'est Juggernaut.

[mang1]

Merci pour vos réponses.

Je capte mal le coup des websockets, comment fonctionnes les librairies qui sont sensés l'émuler ? Il faut développer en fonction d'elles où elles sont totalement transparente (il faut juste les avoir ?) ?

Pour le serveur pas de problème, je peux tout à fait me prendre un kimsuffi à 20€/mois.

Quel est le principe du serveur push ? Là encore je capte mal le concept, comment le serveur push peut savoir que tel chose doit être envoyer à un client, par exemple, un personnage de la map bouge et il envoi l'info aux autres personnages (c'est bien ça ?), mais comment le serveur push sait qu'un personnage à bougé ?

Voilà je cherche juste quelques éclaircissement avant de me plonger là dedans pour ne pas trop patauger.

[Sephi-Chan]

Les solutions de push sont généralement composées de trois éléments.

• Un serveur de push qui tourne en plus du serveur Web classique de l'application.
  
• Un client côté client. C'est un script Javascript qu'on charge dans le navigateur du joueur. Ce client va établir une connexion avec le serveur de push selon le meilleur protocole de communication disponible sur le navigateur.
  
• Un client côté serveur. C'est généralement une classe qui va permettre côté serveur d'envoyer des informations aux serveurs de push (quelles données et à qui les envoyer). Le serveur de push les enverras à son tour aux navigateurs connectés à lui.
  

Le plus souvent, on ne raisonne pas en destinataire mais en terme de canaux. Et les navigateurs vont en fait attendre des messages sur des canaux (on parle alors de listen ou de subscribe). L'astuce est ensuite d'avoir un canal par utilisateur et d'autres plus génériques.

Pour cela, on va définir des conventions. Par exemple, le canal de l'utilisateur 1 s'appellera "users/1", le canal pour tout le monde s'appellera "users", etc.

Pour que le navigateur se connecte au bon canal, on va donc écrire du Javascript qui aura conscience des canaux à écouter. Pour cela, il suffit de transmettre le nom des canaux au Javascript.

Quand je génère mon HTML, j'ai le droit de mettre du code Javascript dedans, par exemple.

<script type="text/javascript">

window.currentUserId = <?php echo $current_user->getId(); ?>;

</script>

Ensuite, dans les fichiers Javascript de notre application, on peut faire (avec Juggernaut) :

jQuery(function(){

  // On définit une variable global Juggernaut une seule fois : Inutile

  // d'instancier la classe à chaque fois, on conserve la même instance.

  window.juggernaut = (window.juggernaut || new Juggernaut());



  // On détermine le nom du canal réservé à notre utilisateur.

  var userChannel = "users/" + window.currentUserId



  // On s'inscrit au canal de l'utilisateur et on donne une fonction qui sera

  // appelée à chaque fois que des données sont envoyées sur ce canal.

  juggernaut.subscribe(userChannel, function(data){

    console.log("New confidential data received!", data);

  });



  // Et on peut s'inscrire à d'autres canaux. Ici le canal commun.

  juggernaut.subscribe("users", function(data){

    console.log("New public data received!", data);

  });

});

Et voilà ! Si tu as compris ça, on pourra aller plus loin : j'expliquerai comment envoyer des informations sur ces canaux.
Mais mieux vaut y aller petit à petit et déjà encaisser ça.

[quentin01]

Comme Sephi' a très bien répondu pour le Push je ne vais pas redire tous ça mais je vais répondre à ta question sur l'émulation des fonctionnalités des Websockets. En faite, je vais surtout te parler de Socket.IO vu que c'est cette lib' que j'utilise. Celle ci s'utilise avec ses propres fonctions, ce n'est donc pas une surcharge de l'objet Websocket si jamais il n'existe pas sur le navigateur. Il faut donc apprendre son fonctionnement, mais ce qui est bien avec lui c'est qu'il a un module qui va directement avec Node.JS si tu l'utilises côté serveur.

Concernant la façon dont il émule, en faite il va utiliser des fonctionnalités tierces supportés par les navigateurs, par exemple l'utilisation de Java ou de Flash pour faire les Websockets, si jamais ils ne sont pas supportés nativement par le navigateur. En dernier recours je crois qu'il passe par de l'Ajax, mais je n'en suis pas sûr, a vérifier.

Concernant le serveur si jamais tu te décides à utiliser Socket.IO et Node.JS. Sache que ceux ci marchent par événements, tu envois en faite un événement au serveur ou au client, si c'est le serveur qui envoit, cette événement est accompagné de données envoyées en même temps. Tu peux donc très bien faire un événement "personnageABouger" côté serveur, que lui envoit le client, et ensuite le serveur va faire appelle chez tous les clients à un événement "unClientABouger" en leur envoyant. Bien sûr ce n'est qu'un exemple, mais c'est le principe, cela permet de bien séparer les messages reçus comparés au système de push où l'on écoute un canal ( comme expliqué par Sephi' ) et où il y a donc un seul événement qui est un message reçu ( les données ) sur un canal.

[niahoo]

Est-ce qu'il existe une bonne lib javascript qui propose une API unique pour websockets/long-polling/flash&XML/etc. mais qui nous laisse libre de l'implémentation côté serveur ?

[quentin01]

Je doute que tu trouves une librairie qui fasse tous ça et qui te permette de faire toi même le côté serveur sans là aussi l'utiliser. Mais je pense que c'est quand même faisable, suffit de la mettre en place côté client et de trouver comment récéptionner correctement les données côté serveur, là tout dépend de la lib' utilisé.

[niahoo]

Ben pour le côté serveur j'ai déjà le long-polling d'implémenté, les websockets c'est presque fait grâce au serveur web (yaws) qui gère ça très bien. Pour le flash et le reste pareil c'est pas bien dur à implémenter s'il le faut. (mais WS+long-polling me suffirait)

Mais ne fait je me rends compte que je n'ai qu'à utiliser socketio et juste mettre le serveur de mon choix derrière, non ?

[quentin01]

Tu peux surement, mais comme je le dis il faudra adapter ton serveur au fonctionnement de Socket.IO qui ne marche pas parfaitement comme des Websockets ( a cause de son système d'événements ). Il faudra donc bien que tu adaptes quand même ton serveur pour.