Un daemon… En PHP ?

[Argorate]

Pour moi ça n'a rien de "sale", c'est des conceptions différentes... Après chacun choisis celle qui veux.

Je ne trouve pas logique de faire des mises à jour pour... personne! Il esct plus logique que ce soit lorsqu'on en a besoin qu'il y est une mise a jour.
Le fait que tes événements se déroulent dans une pile n'est pas un problème en sois non? Tu lance le script qui gère la pille au fur et a mesure et qui prend les décisions au fur et a mesures dans le même ordre que si tu avais un cron qui venait toutes les heures.

Après le truc du "si personne c'est connecté durant un long moment, le mec va se prendre toute la MAJ", c'est vrai, mais c'est un faux problème a mon sens:
Soit tu n'as pas beaucoup de joueurs et donc la mise a jour n'est pas excessivement longue, soit au contraire tu en as beaucoup, et donc le temps entre deux connexion (et donc MAJ) est extrêmement courte, donc MAJ rapide.

Enfin après, je ne connais pas assez le projet pour juger, il se peu qu'en ton cas, une autre solution soit plus adéquate...

[niahoo]

Si c'est crade. Bon j'ai un peu la flemme d'argumenter mais disons que c'est de la paresse intellectuelle de coder comme ça (tout comme de ne pas argumenter sa réponse).

Ieyasu si tu dois prendre un dédié alors je ne peux que te conseiller d'oublier php pour le traitement des données côté serveur et d'opter pour un langage concurrent et distribué. (perso j'ai choisi erlang et pour l'instant je dois dire que c'est prometteur – mais il y en a d'autres).

Ce qui ne t'empêche pas d'utiliser php pour l'affichage des pages.

[Sephi-Chan]

Si c'est crade. Bon j'ai un peu la flemme d'argumenter mais disons que c'est de la paresse intellectuelle de coder comme ça (tout comme de ne pas argumenter sa réponse).

N'hésite pas à développer car c'est un sujet intéressant. Et comme c'est récurrent dans les jeux par navigateur, on pourrait créer un article sur le sujet.

De manière générale, dès qu'on le peut, il est intéressant d'externaliser les tâches, des les traiter de manière asynchrone. Ça améliore l'expérience utilisateur et ça permet de conserver un code clair.


Sephi-Chan

[Ieyasu]

@Argorate : je pense que tu n'as pas saisi certains aspects de ce que j'aimerais concevoir.

Il ne s'agit pas de faire des mises à jours pour "personne", mais de proposer aux IA les nouveaux paramètres.

Je pourrais très simplement exécuter mes évènements avec des crons ou une connexion utilisateur dans une optique "classique", mais ce n'est tout simplement pas adaptés à mes besoins.

Prenons une pile de 10 évènements, si l'évènement 1 entraine des circonstances dans lesquelles l'évènement 2 ne se serait pas produit.
Et si l'IA concerné par l'évènement 2 décide de faire autre chose de plus profitable et donc supprime l'action 2 pour la remplacer par une action X qui sera placé dans la pile.
Cette nouvelle action interfèrera avec d'autres actions dans la pile, et même si tous les évènements ne seront pas concernés par un petit changement, il se peut que de grands changement se produisent au bout de quelques temps et après que le changement ait influencés de nombreuses actions.


Ceci est une explication assez maladroite de ce qu'on appelle vulgairement la théorie du chaos, je te conseille le très bon mais difficile d'accès (à mon gout) "La théorie du Chaos" de Gleick chez Flammarion.

Cette théorie est issue originellement des premières simulations météorologique, ou les scientifiques se sont aperçu qu'une erreur très loin derrière une virgule flottante avait entrainé des modifications radicale sur le modèle météorologique.

En conclusion, un tout petit changement dans ma base de donnée pourra avoir des effets important sur le reste à long terme, dans cette optique, je me dois d'actualiser les variable et de les soumettre à l'IA régulièrement.

J'espère ne pas avoir été trop vaseux :S

bref, comme tu le dis, dans un cas tout simple d'exécution procédural des scripts de la pile la solution d'exécution de script via utilisateur serait une solution viable.


Ensuite, la gestion en tache de fond de la base de donnée, par l'exécution en petites séquences exécuté de manière asynchrones permet d'après moi deux choses :

- Un énorme gain de temps d'exécution à l'évidence, vue que le temps d'exécution d'un script est réduit par le facteur de division qu'on lui applique.(ca se dit ça?)

Un script qui mettrait 10 secondes est divisé en 10 process exécutés simultanément, la base sera à jour en une seconde.

- Une facilité de maintenance évidente.
Bien sur il est tout à fait possible de fragmenter son code et de le ranger de manière claire et compréhensible même en codant en procédural, mais je pense que l'externalisation des taches est plus en adéquation avec la POO.

Après il faut relativiser, rien ne sert de sortir un bulldozer pour labourer le petit carré de terre du jardin, mais je pense que cette structure est plus adapté aux projets complexes et "lourds".


@niahoo : Effectivement, l'utilisation d'un langage différent pourrait être intéressant, tant du coté performances que pour l'intérêt d'explorer de nouveaux terrains, mais je trouve que le principal attrait de php, est sa communauté et l'engouement qu'il génère.

Partir de zéro sur un projet qui pourrait s'avérer me prendre des mois de codage et devoir apprendre un nouveau langage pourrait être un peu trop à la fois, en tout cas je ne m'en sent pas la force.
Certe php est incomplet, contient certaines incohérences et vides, mais il a l'avantage d'être très documenté.

Tu as cependant raison, si php m'impose trop de limite je devrais passer à autre chose, un Daemon en dur pourrait régler toute ou partit de ma problématique, mais j'explore encore le champ de mes possibilités.

[niahoo]

Tant qu'on est dans l'abstrait le plus total, comment se fait-il que ton évènement 2 se soit retrouvé dans la pile d'évènements alors que a posteriori le déclenchement de l'évènement 1 rends caduque celui de l'évènement 2.

[usus]

Pour ma part je me suis retrouver confronter a un problème similaire il y a quelque temps, et l'idée de faire exécuter mes script d'actions temporisé (déplacement de troupe, construction d’élément ...) par les joueur me plaisais guère car je voulais qu'il s’exécute a un moment précis et nom a l'actualisation d'un joueur.

Moi j'ai opté pour un "Daemon" (je connaissais pas le terme avant d'ouvrir se topic xD) en JAVA bien que je ne connaissait pas se langage ayant de bonne base en PHP après quelque essai j'ai réussi a faire se que je voulais grâce au plug-in JDBC.

Courage pour ton Daemon

[Ieyasu]

Parceque les conséquences ne sont pas pré-calculés.

Admettons des choses plus concrètes :

L'evenement 1 est l'attaque d'un dépot de nourriture par un joueur.
L'evenement 2 est une expédition d'une IA se rendant à ce même dépôt pour acheter des denrées.
L'evenement 3 n'a rien à voir avec tout ca.
L'evenement 4 n'a rien à voir avec tout ca.
L'evenement 5 n'a rien à voir avec tout ca.
L'evenement 6 n'a rien à voir avec tout ca.
L'évènement 7 n'a rien à voir avec tout ca.
L'évènement 8 n'a rien à voir avec tout ca.


Le script de résolution de l'attaque est lancé, le dépôt est détruit et le joueur l'a pillé...
L'IA est avisé des informations qu'elle est censé pouvoir prendre en compte. (Disons qu'un messager préviens le convois)
Après avoir pris en compte ces nouvelles informations, l'IA n'a plus trop d'intérêt à aller acheter des denrées à ce dépôt.
Elle revoit donc ses plan et change de route.
L'IA décide d'envoyer son convoi au dépôt d'arme le plus proche afin d'acheter au meilleur prix un stock à revendre ailleurs.


Après traitement de l'évènement 1 et ré-examen des nouvelles variables d'environnement par l'IA la pile à changée (je laisse les numéros pour illustrer:

L'évènement 1 est résolu.
L'évènement 2 est annulé, une autre action est venu s'intercaler dans la pile.
L'évènement 3 n'a rien à voir avec tout ca.
L'évènement 4 est l'expédition qui arrive au dépôt d'arme.
L'évènement 5 n'a rien à voir avec tout ca.
L'évènement 6 n'a rien à voir avec tout ca.
L'évènement 7 n'a rien à voir avec tout ca.
L'évènement 8 n'a rien à voir avec tout ca.


Dans ce cas simple, on supprime une entrée pour une autre, exécuté plus tard.

Dans des cas plus complexes, concours de circonstances ou je ne sais quoi, des entrées pourraient simplement apparaitre :

Avant même l'exécution et la résolution de l'évènement 4, le convoi rencontre (passe dans la zone d'action) d'une troupe de bandit itinérants, le moteur génère un nouvel évènement :

L'évènement 1 est résolu.
L'événement 2 est annulé, une autre action est venu s'intercaler dans la pile.
L'évènement 3 n'a rien à voir avec tout ca.
Nouvel évènement : les bandit interceptent le convoi.
L'évènement 4 est l'expédition qui arrive au dépôt d'arme.
L'évènement 5 n'a rien à voir avec tout ca.
L'évènement 6 n'a rien à voir avec tout ca.
L'évènement 7 n'a rien à voir avec tout ca.
L'évènement 8 n'a rien à voir avec tout ca.

Dans ce cas, un nouvel évènement est apparu, mais ce n'est rien encore.
Admettons que l'évènement 3 arrive, soit exécuté.

Aucun influence sur notre affaire, mais 1 minute avant l'interception des bandits, l'IA du convoi se rend compte qu'elle est suivit de très prêt et engage une manœuvre de fuite vers la bâtiment le plus proche.

Hop l'évènement 4 est annulé et l'interception par les bandits est repoussée dans le temps... (Oui si le convoi fuit, cela prendra plus de temps).

Une fois le convoi détruit et pillé, la "police" locale est avertit et mobilise deux patrouilles pour traquer les criminels... Etc etc etc.




Quelle histoire hein? :hahahaha:

J'aurais pu être plus inventif, et trouver des interactions plus étroites entre les évènements, désolé pour le manque de créativité.

Ce que je voudrais démontrer avec tout ceci, c'est que chaque évènement influe sur les suivants, bien entendu dans un univers vaste et riche, les conséquences sont parfois minces, ou subtiles, mais parfois elles seront catastrophiques.

Il est impossible d'établir une sorte de déterminisme absolu en pré calculant tout cela, par exemple, qui aurait pu prévoir le résultat de l'attaque sur le dépôt de denrées?
certes on peut le pré calculer, mais dans un environnement de jeu ou les joueurs peuvent intervenir soudainement, et protéger le dépôt alors le calculs devient obsolète.
Ainsi tout les calculs liés à ce mauvais calcul le deviennent et doivent être modifiés.

Un univers en permanente mutation, avec un calcul en temps "réel" des mouvements et changements qu'un calcul à la connexion des joueurs ne peut satisfaire.

[niahoo]

Ah non là c'est différent, dans ton premier exemple, ton évenement 2 n'est pas remplacé par un autre, il à déjà commencé, les troupes se sont déplacées déjà, elles changent juste de destination.

`A moins que tu ne permettes à tes joueurs de planifier à l'évance un déplacement, mais je ne l'ai pas compris comme ça. (et dans ce cas, laisse le se démerder pour annuler le dpélacement)

[Ieyasu]

Ah oui, je vois, dans mon premier exemple, effectivement mon évènement 2 a déjà commencé. Effectivement si il s'agit d'un joueur, il devra gérer ceci lui même c'est évident, à contrario, l'IA se gère seule.

Si elle à connaissance des changements de son environnement, l'IA sera à même d'envisager un changement dans son attitude.

Il sera possible de changer de destination même en cours de route, de manière manuelle pour les joueurs, ou autonome pour les IA.

Certaines évènements seront "éditables", par exemple lorsque je me rend à un endroit, je génère un évènement "départ" et un évènement arrivé, avant le départ on peut tout annuler, après on peut seulement annuler "arrivé" et le remplacer par une autre action.


Bref, je suis pas sur d'être clair

[niahoo]

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.