La notion de "version du serveur", dans un jeu php?

[Maz]

Bonjour, j'ai juste une petite question qui me trottes depuis le temps où je jouait à un blockbuster du jeu php (travian pour ne pas citer), où ils mentionnait la "version du serveur".

Ayant aussi beaucoup joué au mmorpg de type wow, dofus, flyff, etc... où il y a réellement un logiciel "serveur" auquel on accès via un logiciel "client", cette fameuse notion sur un jeu php floutes un peu ma vision de ces blockbuster.

Je l'ai aussi vu dans des jeux beaucoup moins connus, mais peut-être à tord?

Ces gros jeux sont-ils réellement développer sous le schéma "logiciel client(dans un langage web tel que php ou ruby) > logiciel serveur(qui est peut-être développer dans un autre langage du type C qui est exécuté directement sur le serveur)"?

Si tel est le cas, quelqu'un a déjà développer ici sur ce forum un jeu se basant sur cette architecture?

Merci.

[php_addict]

je ne suis pas certain de comprendre...

il s'agit dans tout les cas de jeu ayant pour modèle serveur <--> client

dans les jeux par navigateur (travian puisque tu le cites) le client est le navigateur qui envois des requetes $_POST , $_GET , etc...

dans le cas de jeux "logiciel" c'est le logiciel le client qui envois je ne sais comment des requetes au serveur

le principe est le meme, seul le support client change

[Sephi-Chan]

Comme tout code source, celui de l'application Web peut être versionné.
Après, tu peux mettre en production une version spécifique de l'application. Ça se fait très bien avec des outils de déploiement comme Capistrano.

Tu peux même avoir plusieurs serveurs (au sens physique du terme, pas au sens "découpage en plusieurs royaumes") qui font tourner des version différentes, mais ça devient plus délicat à cause des éventuelles différences entre les bases de données.

[Maz]

Je penses avoir un peu de mal à me faire comprendre. En même temps j'ai l'impression que c'est moi qui vois les choses pas comme il le faudrait. En fait je vois vraiment les blockbusters codé d'une manière différente pour mieux les gérer, un peu du genre:
Un logiciel client codé en php juste pour généré la source html final comme le ferais un simple moteur de template.

Un logiciel serveur codé en C, pour établir tous les calculs sur les informations envoyées par les formulaires du logiciel client.

Moi quand je code, bien que la partie formulaire est séparé de mes calculs via un moteur de template où via une architecture MVC, au final il n'y a qu'une page qui est exécuter qui fait les include des modèle, vue et contrôleur pour prendre mon dernier exemple.

[srm]

Certain jeux très particulier le font car ils en ont le besoin, exemple : dofus.
Car il y a énormément de temps réel.

Si il n'y a pas un gros besoin de ce type, un serveur n'est jamais créé, on utilise Apache ou un équivalent, car sinon c'est des complications et du travail pour rien.

[Sephi-Chan]

Je penses avoir un peu de mal à me faire comprendre. En même temps j'ai l'impression que c'est moi qui vois les choses pas comme il le faudrait. En fait je vois vraiment les blockbusters codé d'une manière différente pour mieux les gérer, un peu du genre:
Un logiciel client codé en php juste pour généré la source html final comme le ferais un simple moteur de template.

Un logiciel serveur codé en C, pour établir tous les calculs sur les informations envoyées par les formulaires du logiciel client.

Moi quand je code, bien que la partie formulaire est séparé de mes calculs via un moteur de template où via une architecture MVC, au final il n'y a qu'une page qui est exécuter qui fait les include des modèle, vue et contrôleur pour prendre mon dernier exemple.

Je comprends très bien de quoi tu parles : un daemon qui tournerait sur et s'occuperait de certains calculs. Et le serveur Web servirait juste d'intermédiaire.

Ça permet de s'affranchir de l'aspect stateless d'un serveur Web où tout ne vie que quelques instants (généralement moins d'une seconde).

Il y a beaucoup de tâches qu'il est plus intéressant d'effectuer de manière asynchrone : c'est beaucoup plus performant et efficace de les sortir du cycle d'une page Web puisque ça permet de n'avoir que des pages très rapide, donc des connexions au serveur Web très courte, donc pas de file d'attente des requêtes à l'entrée du serveur Web. Ça donne l'impression d'un site plus rapide.

C'est pour ça que j'insiste souvent sur l'utilisation d'outils de queuing comme Resque. Une utilisation bien connue de ce genre d'outils : l'envoi de mails, qui peut prendre plusieurs secondes.

C'est également pour ça qu'il faut utiliser des crons quand c'est possible. Ça permet de sortir beaucoup de choses du cycle de vie des requêtes HTTP : ça permet d'avoir un code plus simple et plus performant.

De nos jours, tout ça se marie très bien avec le push, puisque nos scripts exécutés tranquillement sur le serveur — en dehors d'une requête HTTP — deviennent capables de communiquer avec le navigateur.

Bref, le développement d'un daemon dédié n'est que la suite logique de tout ça. Mais avant d'en arriver là, il y a bien d'autres choses à faire.

[Hideaki]

Tu confonds le terme version du serveur et jeux de type client(lourd)-serveur.
1er cas : Voir le message de Sephi-chan
2ème cas : http://fr.wikipedia.org/wiki/Client/serveur et http://khayyam.developpez.com/articles/c...hitecture/

Micro résumé des 2 liens et dans sa formation la plus simple :
-- Partie Client --
Couche de présentation ( MVC s'occupe que de la couche de présentation ! ) contenant l'accès aux moteurs graphiques.
Couche de connexion aux serveur

Joueur <-> Couche de présentation <-> Connexion serveur

-- Partie serveur --
Couche de communication
Couche de traitement
Couche BDD

Jeu <-> Couche de communication <-> Couche de traitement <-> BDD

En le transposant à une application web, tu aurais simplement ton serveur avec les actions classiques et se connecterait à un serveur de Web Service, c'est à dire un autre serveur s'occupant du traitement et de la BDD.

[Maz]

Et vous pensez que certains gros jeu php sont développé ainsi? Juste de la curiosité.

[Hideaki]

Modèle N-tiers oui surement avec en couche de présentation le design pattern MVC.

Le modèle exposé plus haut, je n'y crois pas, il n'y a pas d'intérêt à faire une telle architecture hormis pour intégrer des fonctionnalités issus d'un portail offrant une interaction entre plusieurs jeux comme une messagerie commune mais dans ce cas. L'intérêt de ce type d'architecture est ici http://fr.wikipedia.org/wiki/Service_Web

Pour les gros jeux ayant un énorme trafic une architecture de répartition est mise en place dans ce cas, il ne s'agit pas forcément d'une architecture logicielle mais plus une architecture réseau.

[EDIT] On peut retrouver cette architecture sur les jeux flash contenant des interactions entre joueurs puisque que le module flash est exécuté chez le client et peut-être considéré à juste titre comme un client-lourd

[niahoo]

Les serveurs type WOW utilisent un protocole de communication entre le client et le serveur, unr interface réseau qui gère les entrées et les sorties, une base d'exécutables qui contiennent le code métier, et une base de données.

Ensuite, ben tu prends ce que tu veux.

Totalement au hasard, comme protocole tu prends HTTP. Comme interface réseau tu prends apache, comme base d'exécutables tu prends PHP et comme base de données tu prends mysql.

Pfiouh ça en fait des trucs a apprendre, mais c'est le même pricipe que coder un serveur wow.
(mangos utilise mysql pour tourner les serveurs wow).
(on pourra me dire qu'une partie du code php fait aussi partie de l'interface réseau. de la partie logique, oui.)

Et vous pensez que certains gros jeu php sont développé ainsi? Juste de la curiosité.

Je pense que Travian/Ogame utilisent ça très largement.

Effectivement, PHP ne tourne pas en arrière plan. Le post de Sephi te donne quelques infos pour réaliser des queues avec PHP. il y a aussi un topic ici sur la gestion de lignes de production en asynchrone.

Je pense que c'est très utile pour faire un jeu multijoueurs élaboré. Un jeu de poker online bien connu tourne avec un serveur asynchrone derrière.

Si il n'y a pas un gros besoin de ce type, un serveur n'est jamais créé, on utilise Apache ou un équivalent, car sinon c'est des complications et du travail pour rien.

Je pense que tu te trompes, ce ne sont pas des complications. Si tu as des PNJ, une IA, une gestion de construction, d'armées en déplacement, c'est au contraire beaucoup plus simple avec une appli qui tourne non stop derrière et qui gère ça pépère ; ne serait-ce qu'un cronjob