Opérations en Hors ligne

[jean-baptiste]

Bonjour à tous,
voilà je veux rechausser les crampons au niveau des jeux après 2 ans de retraite. Cependant une petite question me turlupine au niveau de la gestion des actions quand un joueur est Hors ligne.

Dans le cas d'un site ou l'on doit développer des ressources et des petits soldats. Comment fait-on lorsque le joueur lance un construction ayant pour but de développer la rapidité de production d'une ressources ?

- quand il ce reconnecte on lance le calcul de ressources qui doit avoir sur le barème de l'ancien niveau de ressources
- on lance le calcul sur le nouveau calcul de ressources si celui-ci est terminé
- on fait un prorata avec calcul des ressources avec l'ancien niveau et calcul de ressources avec le nouveau niveau.

Je penses que pour coller au mieux à la réalité c'est le dernier qui est le mieux. Cependant là c'est le cas d'une seul ressources et d'une seul évolution quand la personne est hors ligne mais si la personne à évolué de plus de 1 niveau et plusieurs ressources cela ne complexifie pas la chose ? Quelle structure de table adopté pour faciliter ce calcul ?

Merci de votre aide.

Cordialement,

[Nosrehl]

Question qui revient fréquemment j'ai l'impression.

Je n'y répondrai pas mais une autre solution consiste à devoir "valider" une construction en se connectant, donc c'est l'ancien niveau qui compte en production de ressources tant que le joueur ne s'est pas connecté.

[niahoo]

Ça revient souvent et je ferai la même réponse : ton jeu doit évoluer en temps réel. Compter sur la connexion du joueur pour gérer tout ce qu'il s'est passé depuis sa dernière connexion trois mois auparavant est un mauvais plan.

Tu auras des traitements plus longs et des problèmes de race condition

[Sephi-Chan]

Comme Niahoo, je pense (en fait, je ne fais pas que le penser, je le sais) qu'il ne faut pas attendre que les actions des joueurs déclenchent des événements. Mieux vaut tabler sur l'asynchrone, c'est beaucoup plus performant et bien meilleur pour l'expérience utilisateur.

C'est sûr, c'est un peu plus délicat à mettre en place car c'est un mode de pensée différent qu'il faut s'imposer. De même, ça nécessite un peu plus d'infrastructure (type serveur dédié), mais comme toujours, pour faire de bonnes choses, il faut s'en donner les moyens ! Et puis, pour ceux qui s'intéressent, il y a moyen d'avoir les avantages du dédié à moindre frais (voire aucun frais), notamment grâce au cloud (cf. Cloud Foundy)


Sephi-Chan

[jean-baptiste]

Je ne comprend pas trop de quoi tu parle en asynchrone. Tu veux dire que l'on doit gérer genre toute les nuits ?( cron) afin de faire en sorte de mettre à jour tout les comptes des joueurs qui ne ce sont pas connecté ?

[Sephi-Chan]

Le cron est l'une des nombreuses méthodes pour faire ça, mais il y en a d'autres (un système de queue avec des workers, type Resque). C'est pour ça que l'utilisation d'Ajax (et dans une certaine mesure le push) est capitale, d'autant que sa nature asynchrone t'habitue à penser comme ça.

Un cas typique où l'asynchrone est plus efficace : un envoi de mails. C'est généralement une opération longue (dans le sens où ça dépasse la seconde) pour laquelle on peut rendre la main à l'utilisateur sans se soucier.

Avec un système synchrone, quand je vais cliquer sur mon formulaire, le script qui traite le formulaire d'envoi de mail est appelé, il envoie les mails et répond (il rend une page Web). Le problème, c'est que l'envoi de mail est lent et donc l'utilisateur va avoir l'impression que le site met du temps à répondre.

Avec un système asynchrone, on traite le formulaire de la même façon sauf qu'on envoie pas les mails directement, on met les informations pour les envoyer dans une queue (une fille d'attente) et on dispose d'un daemon (qui peut être installé sur la même machine, sur une autre ou même sur plusieurs machines) qui va lire cette file en exécutant les tâches mises en file. Ces outils supportent en plus plein de trucs cools comme la gestion des tâches qui échouent, la priorité des tâches, etc.


Les serveurs comme Apache ne sont pas adaptés à des requêtes longues (cas typiquement d'un script lents, qui va durer 10 secondes). Dans le cas d'une requête HTTP qui lance un script asynchrone, la requête va durer quelques millisecondes et sera de nouveau libérer pour un autre utilisateur.

Le gros avantage de l'asynchrone, outre la meilleure expérience pour l'utilisateur (puisqu'il n'a pas à attendre qu'une page charge lentement), c'est que ça se fait bien dans la durée et ça peut se faire quand le serveur a peu de charge.

Un autre avantage : le code reste propre, on n'a pas un plat de spaghettis qui déclenche des événements.


Cela ne veut pas dire pour autant qu'une tâche va être effectuée une plombe après avoir été mise en queue, les délais sont plus souvent de l'ordre de quelques secondes.

Après, déterminer ce qui doit être asynchrone se fait avec l'expérience. C'est propre à ton jeu et ses mécanismes. Et là dessus, on pourra probablement t'aider. Parfois, effectuer des actions synchrones est une meilleure idée.

[atra27]

Il est clair que dépendre d'une action d'un user...

Quand tu te dis qu'il faut faire la maj quand le joueur consulte sa page... mais aussi quand quelqu'un consulte ce joueur...

Et puis si tu commence a vouloir gerer les changements dans les constructions, mais aussi les consommations de ressources in game (ex, je produite 10 planche pour 10 bois, sauf qu'a un moment je tombe a 0 bois, donc je produit plus de planches)sa devient monstrueusement compliqué.

Maintenant, pour un jeu sans argent ni dédié, quelles sont les solutions? A mon sens pas beaucoup...
Y a quelques plateformes qui proposents des trucs comme le souligne Sephi... mais sa reste minoritaire, et si elles proposent ce genre de service elles ne proposent pas souvent des programmes comme php (ou alors j'ai pas trouvé)
Conclusion, faut se mettre a rails, ou trouver la méme chose, mais gérant plusieurs langages (je me vois pas réaliser toute l'appli en Java ou en Rails! J'y tiens a mon php... même si il faut le remplacer par un autre a cause de ces lacunes pour faire certaines opérations)

Faudrai vraiment trouver un hebergeur ouverts aux daemons

[Sephi-Chan]

Pas besoin de Ruby, PHP fait l'affaire, il faut juste un hébergement dédié. Or, si on veut développer un jeu complexe, on peut bien payer un tout petit VPS à 6€ par mois.

Faire un système de merde pour que ça tourne partout, c'est vraiment pas rentable.


Sephi-Chan

[jean-baptiste]

D'accord, j'ai bien lu ce que vous dite. Cependant je trouve quand même quelques lacune dans votre raisonnement. L’intérêt de mettre à jour les joueurs connecté, intérêt de mettre à jour en permanence tout les joueurs ( daemon, et il y en a d'autre). Je ne pensais pas qu'en soulevant ce sujet je me heurterai à un tel problème.

Pensez vous que les gros jeux comme Travian ou Ogame (que je prend pour exemple) utilise ce procédé ?

PS: Sinon pour ce qui est des ressources serveur c'est pas du tout un problème pour moi.

Cordialement,

[niahoo]

Quelles sont les lacunes que tu trouves dans notre raisonnement ?

Je pense que Travian et Ogame utilisent ce procédé depuis toujours, ça me paraît assez évident, sinon ils n'auraient pas pu atteindre une telle échelle. (Quoique, ils sont chacun fractionnés en de nombreux serveurs)