Pardon, je pense avoir été mordant à tort sur mon précédent message (pour des causes externes à jeuweb), j'aurai pas dû.
Donc, il me semble qu'on est d'accord pour dire que le jeu stocke, d'une manière ou d'une autre, la date (IRL on va dire) des évènements qui se sont produits ou qui vont arriver (peu importe comment c'est stocké, souvent, sous la forme d'une date+heure en BDD, dans une ou plusieurs tables). En revanche, il me semble qu'on diffère sur la façon dont ces évènements sont résolus.
De ce que je comprends, pour toi, tu pars du principes qu'une cron task/démon/qu'importe unique tourne en boucle, et se charge de résoudre les évènements de cette pile. Auquel cas, oui, ce système a un pas temporel (1 minute pour un cron chaque minute par exemple) et le jeu est donc bien "figé" entre deux boucles de ce système: le joueur ne voit le nouvel état qu'après la fin de cette boucle de calcul.
C'est pour ça, oui (enfin, si je te comprends bien) que le calcul de simulation doit en pratique se faire avant de servir les données (la page) que le joueur a demandé (ce que tu appelles "forcer" la résolution). En revanche, je ne vois pas en quoi cela ne marcherait pas sur un jeu avec de nombreux joueurs?! La cron task (ou démon ou assimilé, l'essentiel étant de dire "l'achi dans laquelle j'ai 1 seul système séquentiel continu qui résout les actions de la stack") marchera encore moins: il va s'engorger quand il y aura du monde, et les joueurs verront des données de jeu qui ne sont pas cohérente avec la date de leur visualisation.
La finesse de ta "temporalité", osef totalement, c'est le principe de vouloir résoudre les évènements au moment où ils ont lieu qui pose soucis. Monter la fréquence de cette boucle, c'est juste un ersatz pour limiter les dégats de ce mauvais principe.
D'où le fait qu'il me semble bien plus approprié de ne pas pousser les créateurs de jeux à raisonner de cette manière (avec un séquenceur d'actions de jeu). Mieux vaut les (enfin, "nous") pousser à considérer qu'ils doivent résoudre la liste des évènements au début du traitement de la requête de la page (aka avant de servir la page web à leur joueur), pour servir un jeu à jour aux joueurs. Donc, le calcul de résolution peut avoir lieu 40 minutes voire des heures après que l'évènement de jeu ne soit censé s'être terminé. D'où l'importance de bien distinguer le moment (Y-m-d H:i
) où le calcul est exécuté du moment où l'évènement de jeu est censé avoir eu lieu. Et quand je parle de CRON dans cette archi là, c'est uniquement pour éviter que trop d'évènements ne se stackent si aucun joueur ne passe par là le week end (par exemple).
Sinon, perso, je trouve que faire son jeu web est justement une excellent occasion de faire de l'ingénierie "propre", et de pouvoir appliquer des principes fiables et robustes: on n'a pas de contrainte de temps, pas de contrainte de finalité, donc on peut se faire plaisir sur la qualité. Ca permet de donner aux dev et créateurs de jeux en général de bons réflexes pour leur taff.
Edit @TerRowan (enfin, @tous mais c'est parce que t'as posté entre temps
)
Oui, j'ai l'impression qu'on est d'accord sur 90% des choses, mais le problème de cette périodicité de cron me donne l'impression que ces 10% restant cachent la montagne. En fait, j'ai l'impression qu'on est d'accord sur la forme, alors que sur le fond, pas du tout. Il me semble, mais Linconnu me corrigera si je me trompe, que cette périodicité que tu veux pousser jusqu'à la minute, voire au delà masque le problème que tu assimiles le moment où la résolution est faite et le moment où l'action in-game aurait dû avoir lieu. Or, pour moi, il faut bien considérer que ce sont deux timestamp totalement différents. On fait de la virtualisation somme toute, et on détache donc la ligne de temps du jeu et la ligne de temps des calculs.
[edit2 en réfléchissant à voix haute]
En fait, quand on détache les deux timelines, pour moi, la fréquence (et même l'existence) du cron/démon n'ont plus aucune importance. On peut le faire à la seconde si on veut, ou à la minute, ou à l'heure, ou à la journée, ou ne pas en mettre du tout: le principe de l'archi ne pose aucun soucis dans tous ces cas. Or, j'ai l'impression que pour Linconnu, ne pas être à la minute ou à la seconde est un problème. Ergo, on ne peut pas parler de la même archi.
"Si on parle de la même archi, alors la fréquence du CRON n'a aucune importance. Or, la fréquence du cron semble avoir de l'importance pour toi. Donc, on ne parle pas de la même archi".
Donc, il me semble qu'on est d'accord pour dire que le jeu stocke, d'une manière ou d'une autre, la date (IRL on va dire) des évènements qui se sont produits ou qui vont arriver (peu importe comment c'est stocké, souvent, sous la forme d'une date+heure en BDD, dans une ou plusieurs tables). En revanche, il me semble qu'on diffère sur la façon dont ces évènements sont résolus.
De ce que je comprends, pour toi, tu pars du principes qu'une cron task/démon/qu'importe unique tourne en boucle, et se charge de résoudre les évènements de cette pile. Auquel cas, oui, ce système a un pas temporel (1 minute pour un cron chaque minute par exemple) et le jeu est donc bien "figé" entre deux boucles de ce système: le joueur ne voit le nouvel état qu'après la fin de cette boucle de calcul.
C'est pour ça, oui (enfin, si je te comprends bien) que le calcul de simulation doit en pratique se faire avant de servir les données (la page) que le joueur a demandé (ce que tu appelles "forcer" la résolution). En revanche, je ne vois pas en quoi cela ne marcherait pas sur un jeu avec de nombreux joueurs?! La cron task (ou démon ou assimilé, l'essentiel étant de dire "l'achi dans laquelle j'ai 1 seul système séquentiel continu qui résout les actions de la stack") marchera encore moins: il va s'engorger quand il y aura du monde, et les joueurs verront des données de jeu qui ne sont pas cohérente avec la date de leur visualisation.
La finesse de ta "temporalité", osef totalement, c'est le principe de vouloir résoudre les évènements au moment où ils ont lieu qui pose soucis. Monter la fréquence de cette boucle, c'est juste un ersatz pour limiter les dégats de ce mauvais principe.
D'où le fait qu'il me semble bien plus approprié de ne pas pousser les créateurs de jeux à raisonner de cette manière (avec un séquenceur d'actions de jeu). Mieux vaut les (enfin, "nous") pousser à considérer qu'ils doivent résoudre la liste des évènements au début du traitement de la requête de la page (aka avant de servir la page web à leur joueur), pour servir un jeu à jour aux joueurs. Donc, le calcul de résolution peut avoir lieu 40 minutes voire des heures après que l'évènement de jeu ne soit censé s'être terminé. D'où l'importance de bien distinguer le moment (Y-m-d H:i
) où le calcul est exécuté du moment où l'évènement de jeu est censé avoir eu lieu. Et quand je parle de CRON dans cette archi là, c'est uniquement pour éviter que trop d'évènements ne se stackent si aucun joueur ne passe par là le week end (par exemple).Sinon, perso, je trouve que faire son jeu web est justement une excellent occasion de faire de l'ingénierie "propre", et de pouvoir appliquer des principes fiables et robustes: on n'a pas de contrainte de temps, pas de contrainte de finalité, donc on peut se faire plaisir sur la qualité. Ca permet de donner aux dev et créateurs de jeux en général de bons réflexes pour leur taff.
Edit @TerRowan (enfin, @tous mais c'est parce que t'as posté entre temps
)Oui, j'ai l'impression qu'on est d'accord sur 90% des choses, mais le problème de cette périodicité de cron me donne l'impression que ces 10% restant cachent la montagne. En fait, j'ai l'impression qu'on est d'accord sur la forme, alors que sur le fond, pas du tout. Il me semble, mais Linconnu me corrigera si je me trompe, que cette périodicité que tu veux pousser jusqu'à la minute, voire au delà masque le problème que tu assimiles le moment où la résolution est faite et le moment où l'action in-game aurait dû avoir lieu. Or, pour moi, il faut bien considérer que ce sont deux timestamp totalement différents. On fait de la virtualisation somme toute, et on détache donc la ligne de temps du jeu et la ligne de temps des calculs.
[edit2 en réfléchissant à voix haute]
En fait, quand on détache les deux timelines, pour moi, la fréquence (et même l'existence) du cron/démon n'ont plus aucune importance. On peut le faire à la seconde si on veut, ou à la minute, ou à l'heure, ou à la journée, ou ne pas en mettre du tout: le principe de l'archi ne pose aucun soucis dans tous ces cas. Or, j'ai l'impression que pour Linconnu, ne pas être à la minute ou à la seconde est un problème. Ergo, on ne peut pas parler de la même archi.
"Si on parle de la même archi, alors la fréquence du CRON n'a aucune importance. Or, la fréquence du cron semble avoir de l'importance pour toi. Donc, on ne parle pas de la même archi".
