Boucle & tick coté server NodeJS?

[niahoo]

Non, Javascript est monothread donc le code suivant s'exécutera de façon atomique :

if(app.tick_in_progress) return false;

app.tick_in_progress = true;

Du coup, tu ne peux pas avoir deux tick() exécutés en même temps.

[Argorate]

@niahoo : NodeJS à une boucle interne pour traiter les events I/O, je t'invite à regardé ici http://stackoverflow.com/questions/15349...s-nexttick
tu verras que ça permet justement, de laisser le temps à node de dépiler les I/O avant de faire le tick suivant.

@xenos : Premièrement, un jeu en temps réel, ça n'a pas de BD... C'est un peu harakiri sinon. Une DB est trop lent, l’intérêt de node, c'est qu'il est statefull, donc tu partages les variable pour tous, pas besoin de BD (pour la persistance en cas de coupure du serveur, est un autre problème technique à traité (il suffit de dumpé les variables à intervalle régulier) mais qui n'est pas notre soucis ici).

Ensuite, si plusieurs tick ont sont raté, c'est que soit le jeu soit le serveur à un problème. Donc avec ce système, le serveur fait X ticks/par seconde, ou s'il n'est pas capable de suivre, il fera au plus vite qu'il peut, donc le jeu effectivement sera ralenti, c'est le principe d'un serveur qui ram...

Ensuite pour le app, je répète, c'est le principe même de node, d'avoir tout en global, il n'y a pas a recharger toutes les variables à chaque requete client comme en php traditionnel. Donc rien de choquant, tu peux ranger les variables ailleurs si ça te plait pas, j'ai fais au plus simple là.

Pour ce qui est de node (je ne suis pas encore expert désolé^^), je viens de me rendre compte que mon truc est débile...( EDIT: comme l'a dit niahoo à l’instant)
Car c'est mono trhead, il n'y a pas de parallélisme, ça veux donc dire que tout mon if ne sert à rien, le setInterval est prafait tout seul, car ça sera dépiller dans l'ordre, y comprit avec les I/O au milieu, donc c'est génial, c'est encore plus simple !

Il n'y a juste rien à faire, aucune variable boolean, le setInterval empilera et sera dépiler de manière linéaire ! Du coup ça me conforte beaucoup pour utiliser cette techno ^^

[Xenos]

Mais s'il est monothread, du coup, setInterval(tick, 10) ne pourra jamais lancer 2 ticks en même temps, ni "rater" un tick (il sera exécuté "à la bourre", mais ils seront tous exécutés et dans le bon ordre)? L'exécution des ticks sera caho-tick (dépendant de la fluidité à tout instant), mais pas "buggé".

(Ca revient à l'edit d'Argorate)

---

Ensuite, si plusieurs tick ont sont raté, c'est que soit le jeu soit le serveur à un problème

Moi, j'en suis pas convaincu.

---

Le app me pose problème car il est externe au scope de la function tick, c'est cela que je trouvais gênant (bon, après, JS, c'est assez particulier sur les scopes donc c'est peut-être qu'une question de préférence). Après, oui, ce n'est qu'un paramètre à passer, mais bon... T, la durée du tick à traiter, n'était aussi qu'un paramètre à passer :p

[Argorate]

Oui c'est ça, en fait c'est une pile géante node, du coup soit ça arrive à dépiler assez vite, soit ton serveur et trop lent, ou ton jeu trop mal codé (ou les deux) et du coup c'est exécuter, toujours dans l'ordre, mais moins vite que ça devrait, donc le jeu lagera et se calera à la vitesse du cpu maximum du serveur, tout seul ! (c'est magique^^)

Une variable app qui est global et qui contient tout ce dont tu as besoin, me semble très bien. les globales c'est pas "le mal", ça c'est des rhétoriques toutes faites qui ont eut lieu suite aux dérives des novices en PHP qui faisait n'importe quoi avec. Après, j'ai pas étudier la question, mais tu peux faire en sorte que tick() soit une méthode de ta classe Application ou Game, si ça te plait plus... Mais ça c'est du détails d'implémentation.

Enfin, j'insiste, le modèle avec le "t" passé en paramètre, n'est pas juste un paramètre, puisqu'il induit que toutes les mathématiques derrière y feront appel...

[Sephi-Chan]

Mais du coup c'est impossible à scale horizontalement.

[Xenos]

C'est pour ça que l'avantage d'avoir un delta Dt dans la fonction de tick me semblait intéressant: cela permet au serveur de faire des calculs plus "grossiers", sur des intervalles de temps plus grands quand i l est sollicité, et des calculs plus fins sur des intervalles courts quand il est à vide.

Note que si Node ne dépile pas assez vite (cas que tu ne pourras détecter qu'à l'exécution), alors le serveur finira par planter (la file n'est surement pas infinie). D'où mon intérêt pour la présence d'un Dt. Oui, toutes les maths y font appel explicitement, mais actuellement, tu y fais appel implicitement. Perso, je trouve que l'explicite est bien plus pratique et pérenne.

Pour la question des globals (je fais court car HS), quand tu travailles en équipe, le premier qui met une globale quelque part entraine tous les autres (et cela finis avec des flatras de globals et de statics). Des objets globaux, j'aime pas (difficilement changeables, que ce soit pour des tests ou autre). Après, un conteneur global qui renvoie un objet, pourquoi pas (pour mon Logger, c'est ce que je fais: Logger est une classe statique servant de conteneur à un objet ILog qui se charge de logger les évènements du code).

[Argorate]

Mais du coup c'est impossible à scale horizontalement.

Tu peux définir "scale horizontal", je n'ai pas comprit l'argument.


@xenos : de mon point de vu cette approche est très mauvaise car ça revient quelque part à masquer un problème de fond pourtant important !

Masqué un problème de charge en faisant en sorte que le jeu soit "grossier" (de qualité médiocre) en cas de charge, et "plus fin" (de qualité) le reste du temps, ne me semble pas pertinent et même assez cruel pour les joueurs eux même.
Je préfère implémenter un système qui monitor le temps de chaque tick et de détecter les problèmes, d'analyser ensuite si y a manière a optimiser le code à l'endroit du problème, voir de passer à un serveur plus performant si le problème persiste malgré les meilleurs optimisations...

[niahoo]

Ha oui bien vu pour le setImmediate, je l'avais oublié celui-ci. Mais bon, je demande à voir l'implémentation après. Parce-que si absolument tout ton code fonctionne avant le prochain tick, en gros ça veut dire que 1 tick machine correspond à 1 tick de ton jeu. J'y crois pas trop mais bon, sur le papier ça a l'air possible.

Xenos les objets globaux bah sur un système live t'as pas vraiment le choix de toute façon. Ton logger à beau être masqué derrière un service, c'est un objet global.

[Xenos]

Je viens de me refaire une partie sur Supreme Commander, et il a l'air de fonctionner sur ce principe de "ticks constants": quand le jeu est chargé (beaucoup d'unités), les calculs s'alourdissent, et donc le jeu ralentit (mais son affichage est toujours à 60FPS, bien sûr). Dans un jeu de stratégie, ça peut être une bonne méthode, en effet, puisqu'il y a plus d'unités, donc plus de choses à faire, et avoir un jeu calculé 3x plus lentement peut être intéressant. Pour un FPS ou un jeu d'aventure (façon Spyro sur EPSX2, qui semble aussi marcher à coup de "ticks constants"), je trouve cela bien moins pratique.

C'est de l'appréciation personnelle, alors je vais plutôt soulever une autre question: si tu fais des ticks à intervalles fixes, peu importe la méthode, alors si la machine est lente, une stack de "ticks en retard" se crée. Passons sur le fait qu'elle puisse déborder. J'aimerai m'intéresser à son enpilage/dépilage: quand les ticks s'empilent, le jeu ralentit. Ca peut être intéressant suivant le type de jeu (cf plus haut). Mais quand la stack se dépile, le jeu va s'accélérer?! Là, est-ce vraiment intéressant?
L'implé en setTimeout n'aurait pas ce problème (si le tick est plus lent que la durée entre deux ticks, alors le prochain tick sera lancé dès la fin de ce tick lent). On aurait toujours un ralentissement quand le calcul du jeu s'alourdit (et donc, admettons que c'est adapté au jeu que tu veux faire), mais pas d'accélération lors du dépilage.

Donc, t'as raison sur le fait que les ticks constants peuvent être adapté au jeu à faire, mais je ne suis pas encore d'accord sur l'implémentation

[Argorate]

Le jeu ne va pas "s'accélérer", quand la charge retombe, il revient à la vitesse normal du jeu.
Donc oui il "s’accélère" de manière relative par rapport au moment où c'est ralenti, mais là tu inverse les référentiels. C'est la vitesse normal qui doit être le référentiel à prendre.
Quand la charge diminue, le jeu se joue à nouveau à vitesse standard. Ce qui n'est pas normal, en définitive, c'est qu'il ralentisse, ça signifie que le jeu est trop gourmand ou le serveur trop lent (ou les 2).

Mais ce que j'ai du mal à comprendre, c'est que j'ai l'impression que dans votre esprit, l'histoire du delta règle se problème, alors que pas du tout. Si le serveur est trop lent, un tick sera très long, donc les mises à jours du jeu se feront avec plus d'écart, donc le joueur verra de la même manière un jeu qui "ralenti" ou on parlera sans doute de "lag".

Donc pour moi il faut bien dissocier le problème technique : es-ce que la machine est capable de simuler mon jeu à intervalle régulier sans lager, et l'implémentation des ticks en elle même.