Gestion des actions

[ThErOr]

Tout d'abord pardonnez-moi si je relance un sujet déjà existant, j'ai recherché sur le topic Algo&Solutions mais je n'arrive pas à trouver un sujet clair résumant bien les possibilités.

J'arrive actuellement à la phase de gestion des actions de notre jeu BA-17. J'ai déjà plusieurs idées et solutions implémentées pour la résolution des actions (bâtiments, techno, combat et autres...) mais je voulais faire une revue de ce qui existe comme solution testées et approuvées sur le terrain.

En gros ça pourrait aider pas mal de monde, dont moi, de voir les solutions techniques qui existent et fonctionnent pour gérer une liste d'actions à résoudre. Une solution en soi ne m'intéresse pas je pense qu'il faut coupler plusieurs types de solutions (actions instantannées / décalées).
A mon niveau d'analyse je vois ça pour le moment:
1 - Résolution par action navigateur uniquement (le joueur charge une page on résout)
2 - Résolution par action navigateur et CRON/daemon (pour alléger la charge éventuelle à chaque chargement)


Voilà pour le moment les solutions que j'envisage (la 2 plus particulièrement), mais je ne sais pas si elles sont adaptées à une quantité de joueur importante. J'aimerais dès maintenant prévoir l'éventualité que le jeu marche... c'est pas gagné mais on ne sait jamais. :hahahaha:
Quelles solutions avez-vous déjà mises en pratiques ? Ont-elle étaient efficaces ? Pour quelle charge ?

Merci de votre retour d'expérience et désolé si cela fait dupliquer un topic (supprimez le et indiquez moi le sujet)

[Sephi-Chan]

Déclencher les actions dans le navigateur est rarement une bonne chose, surtout dans le cas de traitements couteux en ressources. Ça scale assez mal.

Des solutions comme Resque (et le port en PHP sont bien plus efficaces quand le traitement s'y prête.

[ThErOr]

Des solutions comme Resque (et le port en PHP sont bien plus efficaces quand le traitement s'y prête.

Justement certaines actions peu gourmandes en ressources (constructions de bâtiments, développement de tecnologies par exemple) doivent être forcément synchrone pour l'utilisateur.
Je pense que ces actions peuvent être gérées de cette manière.

Pour ce qui est des combats qui peuvent être plus gourmand (pas vraiment dans notre cas), il y a également une notion synchrone quand l'utilisateur est devant son écran. Je vois mal lui demander d'attendre le résultat du combat pendant 10 minutes si ses troupes doivent déjà être revenues par exemple.

La question est donc est-ce que les systèmes de job queue existants permettent de valider cette notion de synchrone. Je ne comprends pas comment une telle architecture peut le garantir étant donné qu'elle garantit seulement que le job soit effectué mais pas quand il le sera.

[niahoo]

Je suppose qu'on peut facilement demander à ce que les jobs soient résolus immédiatement si besoin.

Pour le côté synchrone il suffit d'attendre que le job soit résolu, soit sur une page d'attente, ce qui n'est pas terrible, soit dans l'interface du jeu avec un spinner qui tourne dans un coin, et qui attend un push ou qu'une requete AJAX soit terminée (et qui en arrière plan attend le job côté serveur)

[ThErOr]

Pour le côté synchrone il suffit d'attendre que le job soit résolu, soit sur une page d'attente, ce qui n'est pas terrible, soit dans l'interface du jeu avec un spinner qui tourne dans un coin, et qui attend un push ou qu'une requete AJAX soit terminée (et qui en arrière plan attend le job côté serveur)

Quand je parlais de synchrone ce n'était pas de faire en sorte que l'affichage te fasse patienter mais bien que l'action devant se résoudre à tel heure le soit réellement après telle heure.
Je ne sais pas si c'est possible et correcte de raisonner de cette façon mais je vois mal faire attendre quelqu'un pour une attaque... en lui disant dans 10 minutes ce sera résolu alors que ces troupes devra être rentré par exemple.
Ca me semble catastrophique comme expérience de joueur

[niahoo]

Oui mais la c'est avec un ordinateur que tu travailles, pas un développeur. Un ordinateur quand tu lui dis « fais moi ça pour dans 10 minutes » il le fait sans broncher.

A moins que tu aies des algorithmes vraiment vraiment complexes..

C'est pour ça que je te conseille de bosser sur la synchronisation backend/frontend, ce qui sera plus difficile que de régler ton gestionnaire de 'job queue' pour qu'il fasse les jobs le plus vite possible, et ce même si ce dernier est écrit en php3, avec les pieds et commenté en bantou.

[Sephi-Chan]

Il ne faut pas voir Resque comme un outil qui fait le boulot "dans 10 minutes". Il travaille juste de manière asynchrone. Le plus souvent tu y gagnes en expérience utilisateur : quand ton utilisateur effectue une action, la page de retour lui arrive tout de suite, et là tu as un joli chargement en Ajax (le temps que ton combat soit résolu par le système), bien plus classe qu'une page qui met du temps à se charger (dans le cas d'un lourd traitement synchrone).

Après, Resque n'est pas adapté à tout, et ce n'est pas un scheduler (je ne sais pas si Resque Scheduler a également été porté sur PHP), mais il faut bien réfléchir a ce qu'on peut rendre asynchrone.

[ThErOr]

Je vois mieux du coup ce que tu peux faire de resque est en effet il s'agit de résolution instantané. Le traitement est lancé parallèlement à la requête mais il est lancé aussitôt.
Ca m'a l'air pas mal du tout au niveau des possibilités, merci pour les précisions.