15-02-2011, 01:08 PM
(15-02-2011, 12:53 AM)niahoo a écrit : 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.