[Résolu] Php et le temps réel

[Blarg]

Bonjour,

j'ai une question simple pour les programmeurs professionnels en php : est-ce que c'est possible de faire un jeux multijoueur en temps réel grace à php?

Ce que j'appelle temps réel, c'est que lorsqu'il y a un changement au niveau du serveur (un message envoyé par un autre joueur par exemple), ça ne soit pas nécessaire pour le client de faire une requête avant de connaître ce changement. Le serveur doit être capable d'informer lui même les clients actifs.

J'ai bridé la conception de mes jeux en pensant que c'était impossible (j'ai bien pensé de demander au client d'envoyer une requête à toutes les 10 secondes, mais j'ai peur que ça surcharge le serveur dans le cadre d'un jeu multijoueur.)

J'aimerais savoir si il existe des méthodes plus «propre» pour atteindre le temps réel avec php?

[mdcarter]

Il existe une technologie nommé "Comet", dérivée de l'ajax qui permettrai de faire du temps réel.
Je n'y connais pas grand chose mais peut être que google ou d'autres membres du forum sauront t'en dire plus

[Harparine]

Tu peux utiliser un serveur socket (un programme, souvent en C/C++) qui est toujours "à l'écoute" des utilisateurs qui y sont connectés. Dès qu'il reçoit une info, il renvoie aux autres connectés. Par contre ça suppose d'avoir un serveur dédié pour l'installer (même s'il existe des serveurs sockets en PHP mais je n'ai jamais testé). Je sais que ça fonctionne avec Flash et je pense qu'il doit y avoir l'équivalent en javascript. Par contre, je ne sais pas trop comment ça fonctionne en PHP. Peut-être en regardant de ce côté là ? http://fr2.php.net/manual/fr/book.sockets.php

[Adrien A.]

Je trouve que ce n'est pas une question si simple que ca.

Dans tout les cas, il faudrait en savoir plus sur le jeu. Car un Action-RPG, un RTS, ou un FPS, ce ne sont pas les même contraintes qui entre en lignes de compte.

Je suis actuellement en train de 'créer' un jeu de stratégie 'temps réel' (AoE-like) utilisant un navigateur comme client, sans l'utilisation de Flash pour des raisons idéologique, et par défi. Mais pas de PHP coté serveur, pour encore une fois des raisons philosophiques.

Sinon, je ne pense pas qu'une requête toutes les 10 secondes soit un problème. Après cela dépend de beaucoup de chose, surtout du nombre de joueur. Un cycle de 10 secondes , c'est loin du temps réel, non ?

[Ter Rowan]

je vais plus poser une question que donner une réponse mais bon...

y a quand même un truc qui me chiffonne....

D'un point de vue architecture, c'est jamais le serveur qui envoie une donnée sans que le client lui demande non ?

A mon sens (qu on fasse de l'ajax, du flash, du c, du php, du je sais pas quoi) ce sera toujours au client de demander une info au serveur, à moins qu on puisse prendre la main à distance d'un pc ?

[wild-D]

je vais plus poser une question que donner une réponse mais bon...

y a quand même un truc qui me chiffonne....

D'un point de vue architecture, c'est jamais le serveur qui envoie une donnée sans que le client lui demande non ?

A mon sens (qu on fasse de l'ajax, du flash, du c, du php, du je sais pas quoi) ce sera toujours au client de demander une info au serveur, à moins qu on puisse prendre la main à distance d'un pc ?

je vais t'expliquer ça à ma sauce:

le client lui il va effectivement ouvrir la connection, mais c'est tout; après c'est le serveur qui "prend la main" pour transmettre au client des données quand il a des nouvelles infos.

pour schématiser:

le client ouvre connection (sockets) -----------> au serveur,
et ensuite les 2 communique librement (celui qui a une requête ou données à transmettre le fait): client <----------------------> serveur
(comme une conversation par téléphone chacun est libre de dire/demander ce qu'il veut, quitte à couper la parole à l'autre partie)

par contre les requêtes web classique sont effectivement comme tu le décrits:

client envoie requête ----------------- > serveur reçois la requête, traite & envoie réponse -------------------> client reçois réponse

(si je reprend la conversation téléphonique: c'est comme si le client faisait que poser des questions, et à chaque fois il attend de recevoir la réponse qu'on lui donne)


pas besoin d'être einstein pour se rendre compte qu'une des 2 situation est plus rigide/passive; alors que l'autre est plus souple/proactive.

[Harparine]

C'est vrai, Ter Rowan, mais Flash est une application client. C'est la raison pour laquelle elle est très adaptée à ce genre de situations !

[Adrien A.]

Il ne faut pas tout mélanger, et c'est très dur en informatique.

PHP, c'est un langage, alors, en théorie tu peux tout faire avec. Après quand tu utilise PHP via un serveur HTTP (Apache avec mod_php par exemple), c'est plus la même chose, utiliser des sockets dans se contexte est aberrant, du moins à mon sens.

HTTP, est un protocole qui fonction avec un système de requêtes clientes. Mais tout les protocoles ne fonctionne pas comme cela, par exemple, IRC (discussion instantané): Le serveur envoie les nouveaux messages des conversations auxquels le client participe, ce qui avec HTTP est impossible. Même si, HTTP dans sa version 1.1, intègre le Keep-Alive, qui permet de garder un connexion plus longtemps que prévu, pour justement que le serveur puise envoyer des données au client sans qu'il les est explicitement demandé, pour des raisons d'optimisation, la gestion des connections persistante diffère en fonction des applications, donc inutilisable.

Tout ca pour dire, que parfois lorsqu'on utilise une technologie, il est intéressant de la comprendre un minimum. Et pas besoin d'être un professionnel pour cela. :respect:

[Blarg]

J’aurais souhaité créer un action rpg multijoueur (pour une centaine de joueurs en simultané disons). C’est vrai que 10 secondes, c’est un laps de temps important, mais c’est mieux que rien du tout… Je préfèrerais quand même avoir un retour d’information à la seconde près pour la jouabilité.

Je n’ai effectivement pas accès à un site où je pourrais faire tourner une application en c, c++ ou java (pour des raison de budjet essentiellement). Je vais consulter comment fonctionne les sockets pour php, peut-être que la solution se trouve de ce côté.

edit: Je n'avais pas vu le dernier post d'Adrien avant d'envoyer le mien.

[keke]

Coucou Blarg.

En vraiment simpliste, utilise de l'AJAX couplé avec une table qui listerait l'ensemble des évènements.
Même avec 30 connectés simultané, j'arrive à de bons résultats avec mon tchat en ajax. Il n'est donc pas exclu de faire de bons résultat pour des déplacements, résultat de combats et tout ce qu'on peut imaginer avec un RPG.

Les sockets sont bien plus compliqués à appréhender ... Mais d'un autre côté, elles sont faites pour ça.

kéké