Un daemon… En PHP ?

[Lanwin]

Bonjour,

Ca fait très longtemps que je n'étais pas passé sur ce forum, et encore pire pour ce qui est d'y avoir posté... Cela dit, comme le monde de l'Internet est petit, me voilà sur ce topic.

Tout ça juste pour signaler qu'une autre piste serait peut-être le projet HipHop de nos confrères de Facebook, qui permet la conversion de scripts PHP en code C++ compilables par la suite.

Je ne me suis pas renseigné outre mesure sur le projet ni sur ses possibilités ni sur ses performances (bien que venant des devs de Facebook je pense que ça a été une des priorités), mais il pourrait éviter d'avoir à apprendre un autre langage pour créer le daemon en question.

Amicalement,

(et rendez-vous dans deux ans pour un autre post anémique)

[niahoo]

J'ai pas réussi à avoir un script qui marche avec leur truc. Bon j'y ai passé que deux heures (hors compilation de hip-hop lui même) donc si quelqu'un se le tente et que ça marche qu'il me fasse signe.

[Sephi-Chan]

Si si c'est justement ce que je suis en train de concevoir pour mon système ! ça me parle.

As-tu des premiers jets de code fonctionnel ? J'aimerai bien voir ce que ça donne globalement.
Comment est-ce que tu implémentes ça ? Juste un serveur qui reçoit des événements avec un peu de données pour savoir quoi instancier et quoi faire sur les instances ?
Si oui, comment est bâti ce serveur ? Tu utilises des quelque chose comme NodeJS, EventMachine, Twisted, etc. ?


Sephi-Chan

[niahoo]

Hmm pour le code fonctionnel je n'ai rien a présenter actuellement, je passe tout mon temps alloué à ce projet à la réflexion et à la prise de notes depuis presque un an.. ça commence à être problématique, mais je n'ai pas le temps de me lancer car j'ai pas mal de taf annexe en plus de mon job de dev php.

Dans mon jeu, l'entité que contrôle le joueur (à savoir un genre de village – mais ça peut être n'importe quoi d'autre) est géré par un serveur.

Tu peux considérer ça comme plein d'instances de la même classe, mais des objets qui vivraient chacun leur vie parallèlement et qui s'endorment et se réveillent au gré des messages qu'ils reçoivent.

Ces messages, ce sont eux-mêmes qui les envoient à leurs copains du style
— hé, pan, je t'envoie une attaque de 400 dégâts, tu résistes ?
— et oui, j'ai mon super boubou je ne manges que 25 dégâts électroniques ! :p

du genre (ça pique les yeux, je sais)

%% J'envoie une attaque au joueur 34

attack(nomdemonjeu:playerid2pid(34), #attack{spell=#spell{id=MySpell,type=electro, ...},

                                             damage=damages(MySpell, Player)

                                            }).







%% Et dans la fonction qui reçoit les messages

%% ici c'est un cast (asynchrone) et non un call car le joueur qui attaque n'attends pas de réponse 

%% particulière, il a juste balancé un missile ou je ne sais quoi et ce qui arrive ensuite ne dépends pas de lui. 

%% mais on lui envoie quand même en retour les informations

handle_cast({attack, Attack#attack{spell=Spell,damage=Damage}}, FromPlayer, Player) -> 

    DamageDone = resists_passthru(Attack, Player),

    PlayerUpdated = perdre_de_la_vie(DamageDone, Player),

    nomdemonjeu:notify(FromPlayer, {attackresult, Spell, Damage}),

    {noreply, PlayerUpdated};

Les identifiants de ces serveurs (qui sont en fait des processus) seront stockés dans une table, que la fonction nomdemonjeu:playerid2pid(Id) va parcourir pour retrouver l'identifiant du processus associé au joueur. (la table est en mémoire, pas en dur).

Éventuellement, il y a un timeout sur les processus afin qu'un processus qui dort depuis une heure se termine. la fonction nomdemonjeu:playerid2pid(Id) pourra en créer un nouveau si on a besoin d'interagir avec le joueur. Je ne sais pas encore si je vais faire comme ça mais ça sera approchant.

Pas de node JS non, je pensais utiliser un framework erlang pour le push. Voilà si tu as des questions n'hésite pas, j'ai du mettre une bonne heure à écrire ce post (surtout pour inventer le code qui s'y trouve) ça me permet de mettre en place un peu tout ce qui se mélange dans ma tête depuis trop longtemps



edit: bien sur tout ça c'est le serveur de jeu, ensuite il y a l'interface web qui reçoit l'ordre d'attaquer et qui va en informer le code précédent. Mais le truc intéressant c'est que chaque joueur va piloter son serveur

[Ieyasu]

Si si c'est justement ce que je suis en train de concevoir pour mon système ! ça me parle.

En fait j'étais en train de me dire que ton daemon doit regarder régulièrement chaque event, et voir s'il les continue. C'est chiant car ça bouffe des ressources, mais il devrait "réfléchir" toutes les 5 minutes pour voir s'il continue chaque event.

Ce qui me plait c'est que la réalité dicte l'implémentation chez mio : Un dépôt à été détruit, pouf, toutes les entités (factions, troupes, villes, tout ce que peut comprendre un jeu) qui l'apprennent envoient un messages à leurs membres/amis/relations. J'envoie un message à tous les processus/objets et ceux qui représentent les entités susceptibles d'être intéressées vont réagir et aller modifier leurs évènements dans la pile (bon, pour moi chacun aura sa pile, ou pas, je ne sais pas encore)

Edit: note que dans ce modèle, le site internet qui représente le jeu ne s'occupe plus que de la connexion/inscription/entrée de commandes/réception d'information, ce n'est que l'interface et la logique est bien séparée. On sort un peu du cadre de la tache cron. Mais ça me semble la meilleure voie, sachant que tu peux à tout moment passer de php à Rails ou à autre chose sans toucher à ta DB et au "Core", et surtout parce que ça te permet d'ouvrir ton jeu à plein d'interfaces différentes, puisque le site internet n'est plus qu'une interface parmi d'autres.

C'est ca, mon démon devrait regarder (disons surveiller) les changements de variable.
Je part sur le principe qu'un IA donné fera exactement les même choix si on lui propose exactement les mêmes variables d'environnement.
Ainsi, je ne soumet mes évent à l'examen du moteur que lorsque des paramètres varient et les concernent.

Dans l'idéal cependant, la surveillance doit avoir lieu systématiquement après chaque exécution d'un évènement, et les comme les évent seront classés dans la pile par timestamp, l'idéal serait un rafraichissement à la seconde !

Dans ce système (idéalement, dans la pratique je ne sais pas si je pourrais implémenter un Daemon qui a un rafraichissement à la seconde), le Daemon vérifie la pile et prend en mémoire tous les évent correspondant au timestamp actuel.

Il lance de manière asynchrone autant de processus qu'il a d'évents, ainsi, étant donné la complexité très minime des scripts d'évènements, il seront tous résolus quasi-simultanément.


Ensuite une fois l'ensemble des processus exécutés, le moteur lancera un script correspondant à l'action qui vient de se terminer.


Dans mon système les processus ne sont pas persistant, ils sont représentés par une "trace" en base, et sont réexaminés très très régulièrement.

Ceci dit, j'aime l'idée d'instancier chaque objet du jeu et de lui attribuer un processus, cela colle bien plus à l'idée d'indépendance et de réactivité de mes IA, mais pose cependant un soucis...

Si mon système pêche par le fait de rafraichir toute la pile très très régulièrement, il à l'avantage de stocker tous les évènements en dur, et de les mettre en mémoire que lors de leur exécution.

Ce qui m'inquiète avec ton idée, c'est qu'avec la croissance de population de joueur, lorsque le jeu atteint 1000 joueurs, que chacun d'eux possède quelques troupes, quelques bâtiments et que les IA en font tout autant, nous arrivons à des quantités de processus actif assez effrayant.
Disons 1000 joueurs pour 500 IA, comptons 10 processus par entité, cela nous donne déja 15000 processus actifs... :/

Même si effectivement, une grande partit de ces processus dorment en attendant de recevoir les changement, je craint que cela n'emmène inéluctablement le jeu vers une saturation mémoire.

Après, peut être que je me trompe, ou peut-être qu'un hybride entre ces deux façons de voir serait plus viable.

Qu'en dis tu?


Alors concernant le fait que le moteur est totalement indépendant de l'interface de jeu, je pense que c'est effectivement un sacré atout.

Cela permet une fois le jeu en place, de changer totalement l'interface du jeu, de faire une belle V2.0 sans toucher à une seule ligne de code du noyau, ce qui est vraiment bien, et vice & versa.

Dans l'absolu, moteur un CORE en dur dans un langage compilé est bien plus judicieux, mais c'est tout de même plus costaud niveau codage.


Concernant le codage lui même, je partais dans l'idée de créer une super classe d'objet type "conteneur" et ensuite d'en hériter tous ce qui pourrait bien exister dans le jeu.
Avec une construction intelligente des objets, bien géré avec les processus, le jeu pourrait tourner "tout seul".


@Lanwin : très intéressant ce projet, je vais voir ce que ca donne, ce pourrait être très utile.

[niahoo]

Tes troupes qui sont en train d'aller chercher des armes au dépot X25, elles partent au timestamp t0 pour arriver à t20, et le dépot se fait détruire à t10 ..

Donc, ton daemon qui traite ta pile, comment il sait que c'est l'event 2 qu'il doit traiter ? il va petre obligé de traiter tous les events dont le timestamp de fin dépasse le timestamp actuel(t10), donc logiquement à peu près tous les events de la pile quoi.

Et à chacun il va leur faire revérifier les variables qui les concernent.

ça me semble lourd mais si tu fais ça en C ou en C++, pour un jeu amateur je pense que ce sera tellement rapide que ce n'est pas un problème. mais perso je ne le ferais pas en asynchrone, je prendrais les events dans l'ordre de la pile. ça sera très puissant car C est très rapide. Même php pourrait s'en sortir humblement, il faudrait voir un peu quelles sont ces variables dont nous parlons, si elles sont nombreuses, volumineuses, etc..


Concernant les processus, je parlais de processus BEAM, la VM sur laquelle tourne les programmes erlang. la je viens de faire un petit test, il me crée 10000 processus en moins de 2 secondes.. (bon c'est des processus qui meurent rapidement mais c'est pour dire ..). Rien à voir avec des processus de l'OS qui vont, oui, tuer ta machine si tu fais ce que je disais avec !
(edit: en fait il le fait en moins de 500 ms, c'est les print console qui prennent du temps xD


Comme je ne prends qu'un seul processus par joueur quelques soient ses troupes, villages, etc.. je ne vais pas saturer car si j'ai un jour 10000 joueurs (champomy!) alors j'espère que ça génèrera assez d'argent pour avoir un gros serveur multicoeurs et tout plein de RAM. (ou bien 3 ou 4 ordinateurs différents, mais je ne sais pas vraiment si je pourrais distribuer ainsi la base de données si je prends postgres, mais je ne connais pas bien d'autres SGBD et les api REST pour les données c'est vraiment sympa pour des appli web genre twitter, todolist, trucs comme ça mais pour un jeu ça va vite être casse couilles)

[Ieyasu]

Et bien justement c'est la toute la lourdeur de la chose, repasser la pile en revu pour chaque évent.
J'avoue que ca ne me parait pas très optimisé...

En fait de processus, il s'agirait plus de thread.

Reste a bien penser une structure globale pour ne pas avoir 10000 threads.

En faisant en sorte que php communique directement avec le moteur sans passer par la base de donnée alors on économise le CPU à mort.

reste a faire en sorte que le moteur enregistre régulièrement l'état du jeu sur la base.

Tout reste en mémoire vive, rien ne transite par la base.

Php fait ca nativement, avec les flux je crois...

[niahoo]

Ah le multithreading, ça aussi c'est bien galère je crois !

Enfin voilà, je t'ai présenté ma solution, dans un langage pensé pour ces problématiques.

Si tu veux faire du multithreading, je crois que python à un bon support. Couplé au serveur web Tornado+nginx ça peut être sympa.

À toi de voir

[ThErOr]

Ce sera mon premier "vrai" post sur le fofo.

Je suis actuellement dans la problématique de résolution d'actions. Je pense qu'il ne faut pas choisir forcément une solution mais plutôt voir comment plusieurs solutions peuvent fonctionner ensemble pour répondre aux besoins du jeu tout en gardant une bonne expérience utilisateur.

Pour ma part je dirai que la résolution de certaines actions/mis à jour à l'appel d'une requête HTTP est viable pour des petits traitements (calculs de ressources, résolutions de constructions, de combats...). Ces actions (sous réserve de votre jeu) ne demandent pas d'énormes ressources serveur.

Un autre système de résolution avec un "daemon" ou un "cron" peut s'occupper d'autres actions plus lourdes à traiter et qui ne nécessitent pas d'être instantannées. Avec une bonne gestion de l'affichage il est compréhensible de faire patienter un peu le joueur (cf: eRepublik pour ceux qui ont déjà testé)

Je ne suis qu'au début de ma réflexion mais ce genre d'architecture (que j'utilise de façon professionelle dans d'autres langages que php) est viable.

La gestion du stack d'actions, des annulations éventuelles d'actions ou des impacts entre actions doit faire partie de l'intelligence de l'application (à savoir votre code) et donc cela restera très indépendant des choix techniques (requêtes http, cron, daemon...). La problématique se posera de toute façon.

Voila pour ma contribution, l'article sur les processus php est super intéressant merci