Boucle & tick coté server NodeJS?

[Xenos]

Pour un joueur, le serveur va ralentir par rapport à la vitesse normale quand la stack s'empile, et il va s'accélérer par rapport à la vitesse normale quand il sera en sous-charge (jusqu'à ce que la stack soit vidée, auquel cas il sera en vitesse normale).

Schématisé par une voiture roulant à 130km/h en temps normal, le serveur sera à 60km/h quand il surcharge (et la stack s'empile), puis à 200km/h quand il dépilera la stack, jusqu'à revenir à 130Km/h une fois ce retard rattrapé. C'est un comportement voulu?

Après, je me trompe peut-être dans le fonctionnement de setInterval sur NodeJS, mais c'est actuellement ce que j'en comprends.

(si j'avais à le faire, perso, j'aurai 3 unités de temps: les secondes réelles, l'unité de temps du jeu, et la fréquence des ticks; pour pouvoir jouer sur les 3 indépendamment et pouvoir accélérer/ralentir le jeu par rapport au réel, ou affiner/grossir les calculs de manière séparée)

[Argorate]

Oui, mais encore une fois, c'est pas un cas supposé arrivé. Les retards doivent être léger et très peu récurent. Donc le rattrapage du retard doit se faire quasiment de manière transparente à 1 ou 2 ticks. Si tu commences à partir avec un tick qui fait du retard, le tick suivant en aura aussi, voir un peu plus, et ainsi de suite. Je ne sais plus sur quel site j'ai lu qu'ils appelaient ça "boucle de la mort" ou un truc comme ça, en gros tu plantes ton serveur et c'est pas vraiment récupérable.

Donc en gros, avoir des pics ponctuels doit être toléré, mais tu n'es pas supposé accumuler du retard sur long terme, et la probabilité que lorsque ça arrive, ton serveur puisse récupérer tellement vite de sorte que ça "accélère", me semble peu réaliste.

[Xenos]

"Sur 1 ou 2 ticks", à 30Hz (voire 60Hz ou 100Hz comme t'avais initialement voulu je crois), ça me semble utopique.

[Argorate]

Pourquoi ça? ça dépend de combien dépasse le tick qui nous embête, mais on a déjà dit que si c'est trop important, on entre dans une spiral qui aggrave (en économie on parle de phénomène pro-cyclique).
Donc si ça ne dépasse qu'un peu, et si on considère qu'entre chaque tick il y a du temps libre, on doit pouvoir jouer dessus pour rattraper.

[Xenos]

Donc t'es conscient que ton système va générer des cas où le serveur va crasher, mais tu n'envisageras pas de changer d'implémentation quand même... Tu fais comme tu veux.

Le problème n'est pas uniquement le dépassement du tick, mais la durée pendant laquelle ce dépassement perdure. A 60Hz, un dépassement de 5% qui durera pendant tes 8 heures de sommeil génèrera une stack de 86.400 ticks de retard (sur 1.728.000 ticks) qui soit fera planter le serveur, soit devra être vidée (et on en revient à l'implé setTimeout, sans stack), soit fera accélérer le temps perçu in-game (en augmentant la capa serveur qui traitera donc plus de ticks/seconde et les joueurs verront un jeu qui s'accélère).

PS: Dans Medal Of Honor Allied Assaut (sûr de moi) et dans NeoAxis (moins sûr de moi), la fréquence des ticks peut être changée à la volée, sans que le jeu ne se mette à accélérer (ou ralentir).

[niahoo]

Ce cas est assez facile à gérer : lors d'un tick du set interval, si le tick précédent est encore en cours il suffit d'incrémenter un compteur au lieu d'empiler un appel supplémentaire. Et de décrémenter en fin de tick si on boucle directement.

De cette manière, ta stack est toujours de 1 appel.

[Xenos]

Pas faux, tu résous le problème de la stack avec ce genre de compteur.

Mais quoi qu'il en soit, si le serveur ralentit sur une période assez longue (de quelques heures, genre pendant la nuit ou les vacances du superviseur), alors il accélèrera quand cette stack (compteur ou pile d'appels) sera traitée... Si le jeu n'est pas un "fil rouge" étalé sur plusieurs jours ou semaines façon univers persistant, ok, le soucis est moindre, mais s'il s'agit d'un jeu persistant, en tant que je joueur, je trouverai déroutant le fait de le voir accélérer quand la charge diminue.

[Ter Rowan]

tu es sûr que ce sera une "accélération" et pas une unique "téléportation" ?

d'ailleurs dans quel sens cette accélération ? côté utilisateur le tick restera à son temps habituel, le tick côté serveur sera lui en retard

du coup  si ca lag côité serveur pendant 8 heures (imaginons un freeze total), le seul inconvénient c'est que y aura énormément de mort d'un coup ("téléportation" des tirs au retour serveur)

ou bien je me trompe ?

[Xenos]

La téléportation est un cas extrème d'accélération: tout dépend de la puissance que le serveur pourra dédié au rattrapage des ticks en retard.

S'il freeze et que les ticks sont en fait instantanément calculés, alors oui, il va stacker des ticks pendant 8h et les dépiler instantanément, ce qui fera un "bond dans le temps dans le jeu" (=téléportation).

S'il ne freeze pas mais qu'il accumule des ticks pendant la nuit (car, par exemple, on demande 50ticks/seconde → 1tick toutes les 20ms, mais qu'en pratique 1 tick = 25 ms de calcul) et que pendant la matinée, il dépile ces ticks plus vite qu'ils ne s'empilent (parce qu'au matin, on demande toujours 50ticks/seconde mais le serveur étant moins chargé, 1 tick = 10ms), alors le jeu sera accéléré pour les joueurs (car le serveur va traiter son tick normal, puis dépiler un tick accumulé, donc il traitera 2x plus de ticks pour dépiler sa stack/compteur)

D'où l'accélération (qui est un cas plus "lent" de la téléportation )

[Argorate]

Le jeu ne peu pas laguer pendant 8h, car dès que le lag va atteindre quelques minutes, plus aucun joueur ne donnera d'ordre, puisque rien ne marchera à son écran. Donc le lag se résorbera d'autant plus vite qu'il n'y aura plus rien à dépiler ensuite.

Si vous parlez du cas où la boucle serveur elle même surcharge sans aucune intervention client, on retombe dans le cas qu'il y a un problème avec votre jeu ou votre serveur... Cela ne doit pas arriver.