Forum d'entraide PHPFrance

Bonjour,

Je suis entrain de réfléchir a un projet de mmorpg par navigateur.
Je me pose une question dont j'avais envie de vous faire part

Comment gérer cette actualisation 24/24h, à la seconde près ? Il faut une page qui s'actualise toutes les secondes et qui lance un script ? C'est une appli compilée hébergée sur le serveur qui s'exécute ?

Quand l'utilisateur est connecté, pas de soucis car on a des flux possibles (flash, js ...). Mais quand il n'est plus en ligne, ses données doivent continuer de s'actualiser (production d'une mine, attaque par un autre joueur). Et c'est là que ce pose la mega question :p

Merci de votre aide à tous !

Vincent

Bonjour,

De but en blanc, en HTTP, à la seconde près c'est tout simplement irréaliste (les aléas du réseau ne permettent pas une telle fréquence d'actualisation).

EDIT : ok tu mélanges un peu tout dans ta question. Au niveau de l'interface web, tu viseras une actualisation avec une fréquence raisonnable (pas en dessous de 10 secondes...) et tolérante aux erreurs (il se peut que ça déconne de temps en temps, en particulier _mais pas seulement_ quand ton site sera en maintenance).

Au niveau du moteur de jeu, tu peux faire tourner un script shell (le langage php est envisageable) dont l'éxécution sera illimitée dans le temps, qui va pouvoir modifier les paramètres du jeu à la fréquence que tu souhaites (il n'y a pas de composante réseau qui entre en jeu ici, donc pas de souci de latence/indisponibilité à craindre), et éventuellement transmettre un ordre qui va permettre à tes scripts web de savoir qu'il y a du refresh à faire pour les clients connectés.

Merci de ta réponse

Et pourtant, si je prend des jeux type Ogame, ils sont bien à la seconde.
Mais on peut faire le choix d'avoir une unité de mesure de base qui soit la minute, ce qui irait bien aussi.

La question reste cependant posée, comment actualiser les données quand le joueur n'est pas connecté ?

Merci de ta réponse

Et pourtant, si je prend des jeux type Ogame, ils sont bien à la seconde.
Mais on peut faire le choix d'avoir une unité de mesure de base qui soit la minute, ce qui irait bien aussi.

La question reste cependant posée, comment actualiser les données quand le joueur n'est pas connecté ?

J'ai édité mon post pour mieux te répondre.

Je ne connais pas le fonctionnement d'Ogame et ne peut donc pas te répondre là-dessus (faudrait que je regarde un jour tiens, depuis le temps qu'on m'en parle), bien sûr il y a toujours des astuces et des optimisations/allègements possibles, mais de là à arriver à une fréquence à la seconde, ce serait selon moi à la fois complexe à mettre en oeuvre, lourd pour le client et pour le serveur, hasardeux au niveau connexion et donc vraiment difficile à atteindre à pleine charge avec quelques centaines de joueurs connectés, je maintiens .

Edit : tu peux aussi poser ta question sur ce site spécialisé dans le développement de jeux web : http://www.creajeu.net/

EDIT : Au niveau de l'interface web, tu viseras une actualisation avec une fréquence raisonnable (pas en dessous de 10 secondes...)

Côté client, je vois assez clair la manière de faire. Des infos seront actualisées sur une action du joueur (changement de page, clique action ...) et la carte sera actualisée par flash.

et tolérante aux erreurs (il se peut que ça déconne de temps en temps, en particulier _mais pas seulement_ quand ton site sera en maintenance).

Tu pourrais me préciser ce que tu imagines ? Je n'avais pas encore pensé à cet aspect des choses. Comment vois-tu la gestion de cette tolérance (détection, traitement, info joueur ...)

Au niveau du moteur de jeu, tu peux faire tourner un script shell (le langage php est envisageable) dont l'éxécution sera illimitée dans le temps, qui va pouvoir modifier les paramètres du jeu à la fréquence que tu souhaites (il n'y a pas de composante réseau qui entre en jeu ici, donc pas de souci de latence/indisponibilité à craindre), et éventuellement transmettre un ordre qui va permettre à tes scripts web de savoir qu'il y a du refresh à faire pour les clients connectés.

C'est ça. C'est ici que se pose la question. Ce script (php je pense), comment l'exécuter de manière régulière ?

Vincent

Effectivement Flash peut être un bon appui pour ton cas car il dispose si je ne m'abuse d'une gestion de sockets directes (non HTTP), plus favorables à une vitesse de rafraichissement élevée.

Au niveau du moteur de jeu, tu peux faire tourner un script shell (le langage php est envisageable) dont l'éxécution sera illimitée dans le temps, qui va pouvoir modifier les paramètres du jeu à la fréquence que tu souhaites (il n'y a pas de composante réseau qui entre en jeu ici, donc pas de souci de latence/indisponibilité à craindre), et éventuellement transmettre un ordre qui va permettre à tes scripts web de savoir qu'il y a du refresh à faire pour les clients connectés.

C'est ça. C'est ici que se pose la question. Ce script (php je pense), comment l'exécuter de manière régulière ?

Vincent

En fait deux approches sont possibles : soit celle que tu imagines, en "éxécution régulière", ce qui fait appel aux tâches planifiées (tâches cron sous les systèmes unix) mais à partir d'un certain niveau de complexité de la tâche à réaliser (que la plupart des jeux atteignent facilement) l'autre approche s'impose et s'appelle un démon. C'est un programme qui n'est éxécuté qu'une fois, et qui tourne ensuite en boucle infinie (donc sans limite de temps), et à l'intérieur de cette boucle tu éxécutes tes actions de mise à jour selon la périodicité qui te convient, en fonction bien sûr des performances qu'aura le programme à réaliser ces fameuses tâches (si elles prennent plusieurs minutes, c'est embêtant).

Tu connais déjà ce type de programme, presque tous les serveurs sont des démons (apache, mysql...). Sous windows ça s'appelle des services, mais ce n'est pas différent.

A cause de cette contrainte de performance, on choisit en général un langage compilé pour ce développement (mais php n'est pas complètement exclu, et il est possible par exemple de réaliser ton prototype de démon en php dans un premier temps et de le redévelopper dans un langage compilé par la suite si les performances ne sont pas à la hauteur).

Merci pour toutes ces infos !

Je suis parti sur la solution du flux continu après avoir réfléchi un temps à un système au tour par tour (sur des cycles de 10 mn ou une heure par exemple). Ca aurait l'avantage de ne pas trop charger le serveur même si le risque est un intérêt moindre pour les joueurs au début du jeu (quand il y a peu de choses à faire). Qu'en penses-tu ?

Vincent

Je viens de regarder Ogame, et pour info ça rejoint ce que je pensais : ce n'est pas du rafraichissement à la seconde, mais ils utilisent une petite astuce (un peu d'animation javascript) pour te le faire croire A ce que je vois il y a assez peu (peut-être même pas du tout) de rafraichissement automatique, tout se passe sur action de l'internaute.

Si tu veux creuser les possibilités techniques de rafraichissement automatique, je te conseille plutôt de regarder du côté des solutions de chat web (IRC notamment) qui n'utilisent pas ce genre d'artifice visuel

Merci pour toutes ces infos !

Je suis parti sur la solution du flux continu après avoir réfléchi un temps à un système au tour par tour (sur des cycles de 10 mn ou une heure par exemple). Ca aurait l'avantage de ne pas trop charger le serveur même si le risque est un intérêt moindre pour les joueurs au début du jeu (quand il y a peu de choses à faire). Qu'en penses-tu ?

Vincent

En fait il faut vraiment dissocier les deux (j'arrive pas à savoir exactement de quoi tu parles dans ce post par exemple) entre rafraichissement serveur=>client, qui obéit plus ou moins aux règles standards de conception d'un site web, et moteur de mise à jour effective côté serveur qui lui aura de toutes autres contraintes (performance du code, réactivité du SGBD, le tout lié à la conception des tables et leur optimisation, en particulier si la fréquence de mise à jour est élevée : des problèmes de concurrence et de verrouillage, empêchant les client de lire les données pendant que le démon les met à jour par exemple, peuvent survenir au niveau de la BDD).

Au niveau du démon, comme il tournera dans une boucle infinie, tu pourras choisir librement l'évènement qui déclenchera l'activité du démon (un joueur vient de lancer une action, par exemple), et il te faudra sans doute prévoir et gérer la transmission d'un ordre dans le sens inverse (le démon vient de mettre à jour les données du jeu => on pousse le rafraichissement des pages des joueurs connectés concernés par la mise à jour).

Je pense qu'il n'est pas judicieux de fixer arbitrairement une durée de cycle en minutes avant d'avoir un prototype fonctionnel du démon et de constater la charge de travail d'une mise à jour d'un jeu de données "réaliste", qui va dépendre principalement de la complexité de tes règles de jeu et de la performance du code qui va les implémenter... Il faut tester avant tout

Pas de script qui tourne en boucle, faut arrêter avec cette légende urbaine.

Ce qui se fait dans les jeux web amateurs, c'est stocker un timestamp représentant la date / heure de résolution de l'action.
Il n'y a pas de mise à jour à chaque seconde en continu mais plutôt des mises à jour ciblées sur des événements (dépense d'une ressource, passage de niveau, attaque...).

A+

Pascal

Pas de script qui tourne en boucle, faut arrêter avec cette légende urbaine.

Ce qui se fait dans les jeux web amateurs, c'est stocker un timestamp représentant la date / heure de résolution de l'action.
Il n'y a pas de mise à jour à chaque seconde en continu mais plutôt des mises à jour ciblées sur des événements (dépense d'une ressource, passage de niveau, attaque...).

A+

Pascal

C'est toi le pro, là-dessus, pascal, mais je ne sais pas si le modèle que tu préconises, qui est beaucoup plus simple à concevoir au demeurant mais impose d'architecturer tout le jeu en fonction, conviendrait pour un jeu PvP tour-par-tour aux règles complexes (type civilization, dans l'idée) ou pour un MMORPG comme ici.

Mais c'est ptet pas le meilleur endroit pour en discuter

pascaltje : Dans ta solution, comment exécuter le script au timestamp donné si la page n'est pas consultée ?

Si débat il peut y avoir, je suis preneur

Merci pour toutes ces infos !

Je suis parti sur la solution du flux continu après avoir réfléchi un temps à un système au tour par tour (sur des cycles de 10 mn ou une heure par exemple). Ca aurait l'avantage de ne pas trop charger le serveur même si le risque est un intérêt moindre pour les joueurs au début du jeu (quand il y a peu de choses à faire). Qu'en penses-tu ?

Vincent

En fait il faut vraiment dissocier les deux

Oui oui. On a un moteur (une page de script exécutée en boucle) en local sur le serveur qui actualise les données à une certaine fréquence. Et l'interface du joueur qui s'actualise indépendamment du moteur (au chargement d'une page par exemple).

(j'arrive pas à savoir exactement de quoi tu parles dans ce post par exemple)

Je parlai du côté client. Au lieu d'avoir des infos qui s'actualisent "en temps réel", on aurait un rafraichissement toutes les n minutes. Comme dans un jeu tour à tour.

on pousse le rafraichissement des pages des joueurs connectés concernés par la mise à jour).

Je n'ai encore jamais eu besoin de faire ça. Va falloir que je me renseigne

Je pense qu'il n'est pas judicieux de fixer arbitrairement une durée de cycle en minutes avant d'avoir un prototype fonctionnel du démon et de constater la charge de travail d'une mise à jour d'un jeu de données "réaliste", qui va dépendre principalement de la complexité de tes règles de jeu et de la performance du code qui va les implémenter... Il faut tester avant tout

Oui et non. Oui d'un point de vue méthodologique. Non d'un point de vue concept du jeu. Y'a un choix qui peut être fait à la conception du jeu où on prend une orientation visant le temps réel ou des cycles plus longs, me semble-t-il.

J'ai tout compris ?

pascaltje : Dans ta solution, comment exécuter le script au timestamp donné si la page n'est pas consultée ?

Je retourne la question :
A-t-on besoin d'exécuter le script au timestamp donné ?

Les intérêts bancaires sont calculés chaque année au premier janvier sur les sommes présentes l'année précédente, en utilisant un taux d'intérêt et la durée de présence des sommes d'argent.
Est-ce que toutes les sommes sont calculées au cent près le 1er janvier à 0h00 pour des milliers de comptes ?

Je ne crois pas.
On calcule l'info dans la journée, en utilisant la date "premier janvier à 0h00" et les infos sur l'argent du compte.

Pour les jeux, c'est pareil. On ne calcule pas en temps réel ou au moment exact du passage, mais "après", en se basant sur les données stockées : taux de production, timestamp.

Quand / après quoi calculer et mettre à jour les données ?
Lorsqu'il y a des événements déclencheurs, tels que les attaques, les dépenses de ressources, les changements de niveaux.

Si le joueur se connecte sur son compte après une de ces actions, alors on calcule et met à jour la base de données.
Si le joueur effectue une dépense, c'est un effet immédiat et on calcule en temps réel.

Voilà en gros le fonctionnement, qui permet de faire ce type de jeu sur un serveur pas trop cher pour commencer.

A+

Pascal

@dryzd : la fréquence d'actualisation sur le serveur pourrait en fait être fixe ou ne pas l'être. C'est selon le travail à réaliser et aussi un choix de conception (je suis parti dans l'idée que ce travail serait important, avec beaucoup de traitements pour valider toutes les règles du jeu et tous les cas de figure possibles).

Au niveau client, il y aurait une actualisation ajax périodique avec une fréquence "raisonnable" (à quantifier suivant un tas de paramètres dont je t'ai parlé plus haut). Pour cela, une fréquence de l'ordre de la seconde étant, selon moi, clairement déraisonnable pour un MMORPG (pas impossible, mais très contraignant). Là aussi, il faut bien dissocier l'actualisation réelle, qui est une requête HTTP avec une réponse du serveur, avec une animation sur le client (cf Ogame qui joue très bien là-dessus). En fait selon les choix de conception l'actualisation peut même être évènementielle, comme dans une page web classique (cas d'Ogame), et non périodique, ce qui est idéal en terme de charge vu que tout se fait à la demande, et plus simple à mettre en oeuvre également. Cela va dépendre principalement de ce que tu veux qu'il se passe si le joueur reste passivement à regarder son écran, sans bouger la souris ni cliquer nulle part

Pour la transmission d'ordre entre démon et joueurs, cela revient à de la communication inter-process, et c'est moins compliqué que ça en a l'air (ça peut se résumer à la présence ou non d'enregistrements en base, ou toute autre utilisation astucieuse d'une techno de stockage compatible avec les contraintes).

Pour ta dernière question, ça dépend de trop de choses pour donner une réponse dans l'absolu de toute manière, pour moi c'est donc "faut voir" Mais rien ne t'empêche de te fixer un objectif et de te donner, lors de la conception, les moyens de l'atteindre, effectivement.