Boucle & tick coté server NodeJS?

[Xenos]

Pourquoi les joueurs ne donneraient pas d'ordre? Si j'ai bien suivi ce qui a été dit, les I/O (commandes utilisateurs donc?) seront traitées entre deux ticks. Donc le jeu fonctionnera toujours, seulement les joueurs percevront un jeu légèrement ralentit par rapport à ce qu'il devrait être.
En un sens, cela ne laggera même pas, puisque les I/O seront bien traités, les choses seront juste lentes à se dérouler; je t'invite à essayer Supreme Commander à l'occasion, car c'est un excellent exemple de ce style: le compteur de temps in-game a beau indiquer "20 minutes", en pratique, cela fait parfois 1h que t'es dans la partie (mais dans celle-ci, les actions sont plus lentes que la normale à s'exécuter). Pour autant, les I/O ne rament pas (tu donne un ordre, c'est directement pris en charge).

La seule différence, c'est qu'une fois que le jeu revient à sa vitesse normale, il "n'accélère" pas pour rattraper les éventuels ticks de sa stack.

[Ter Rowan]

encore une fois

coté io, pas de retard, puisque le perso se déplace sans attendre le retour serveur, on est bien d accord ?


donc qu'elle expérience négative va vivre le joueur ?

être blessé / mourir avec retard ?
attendre de savoir si son coup porte ?
voir apparaitre les bords de la carte plus lentement quand il se déplace ?
attendre pour un échange ?

[Xenos]

les joueurs percevront un jeu légèrement ralentit par rapport à ce qu'il devrait être

Si le joueur est en véhicule, celui-ci réagira correctement, affichera "Vitesse: 200km/h", mais se déplacera hyper lentement en pratique.

Tu vois un film au ralenti (façon VLC)? Pareil: les commandes répondront impec, tout sera fluide à l'affichage, mais cela se déroulera lentement.

Ca, c'est commun aux deux implémentation, et c'est un choix de design.
En revanche, quand la stack sera dépilée, les ticks seront exécutés plus rapidement que la normale, et cela fera comme si VLC était en vitesse x2.

A mon sens de joueur, c'est pas terrible. Je préfère que le film soit en x0.5 quand le serveur rame et en x1 le reste du temps qu'en x0.5 quand il rame et x2 quand il rattrape ses ticks en retard.

[niahoo]

Les cas extrêmes sont censés être rares. Ces ralentissement et accélérations sont censés ne durer que quelques secondes tout au plus.

Effectivement comme toi, en tant que joueur, je n'aimerais pas les accélérations je pense : si le jeu demande quelques réflexes ou prises de risque, ça peut être galère à gérer. Mais si on peut continuer à donner des ordres de façon fluide, et que par exemple on sait que tel missile arrive dans 5 secondes, ça peut être cool de pouvoir se coordonner sur ce temps prévu sans trop tenir compte de l'affichage : si on a balancé la roquette au bon moment, elle devrait atteindre sa cible.

D'un autre côté, si on compte sur ses réflexes pour esquiver une roquette qu'on ne voit arriver que visuellement, l'accélération est pénalisante. Il y a là un compromis.

Bon, on ne sait toujours pas de quel type de jeu il s'agît.

Et de plus, je me répète, je suis quand même curieux de voir quel jeu à besoin d'une précision sur des ticks à 50ms cordonnés entre le serveur et le client, tout ça en passant par du HTTP.

[Argorate]

Attention, vous faites un amalgame boucle serveur et boucle client. Si vous lancez un missile, même si son traitement se fait en accélérer coté serveur, coté client ça ne sera pas le cas. Puisque si le jeu est assez avancé, il dispose d'un système de prédiction qui lance le missile avec la bonne physique, bien timé vis à vis des FPS clients, donc aucune accélération visuelle à mon sens...

Le cas inverse l'est plus. Il peut y avoir un lag sur les informations serveur reçu par le client. Mais là encore, les animations n'iront ni plus, ni moins vite. C'est juste que les dégâts ne s'afficheront pas après l'impact, mais une seconde en retard par exemple...
Donc, ça dépend du type de jeu, mais des "lag" assez léger peuvent être largement contrer par le système de prédiction (c'est fait pour couvrir la latence réseau, mais selon les cas ça peut même contrer les petits lags serveur).

[niahoo]

On avait bien compris. Mais tu n'as pas bien lu mon message.

Si un joueur lance un missile et que ce missile est traité pendant une accélération, le joueur qui a lancé le missile va voir un affichage correct, les dégats seront juste en avance.

Par contre, le type qui se mange le missile, il va juste avoir le temps de voir qu'on tire vers lui qui'il aura déjà pris le missile, sans aucune chance d'esquiver.

[Xenos]

Heu, si le client n'affiche pas ce qu'il y a sur le serveur, c'est encore pire: les joueurs peuvent juste pas jouer dans ces conditions...

D'autant que, vu qu'on ne sait toujours pas de quel type de jeu il s'agit ni même si c'est persistant ou non, difficile de savoir si les joueurs peuvent rejoindre la partie en cours de route (auquel cas, dur de prédire quoi que ce soit quand on vient de rejoindre le jeu).

Cela nécessite aussi plus de code si tu veux "prédire" coté client.

PS: comme dit par Niahoo, celui qui se mange le missile et celui qui l'envoie finissent par ne plus jouer au même jeu. C'est à peu près ce qui se passe dans Supreme Commander: j'ai déjà fait des 1vs1vs1vs1 où personne n'a joué à la même partie, et où chacun (dans sa partie) a gagné...

[Argorate]

Heu, si le client n'affiche pas ce qu'il y a sur le serveur, c'est encore pire: les joueurs peuvent juste pas jouer dans ces conditions...

C'est pourtant exactement le cas ! C'est d'ailleurs de là que viennent les débats sur le fameux "lerp" de valve sur counter-strike ou left4dead2.
En gros, plus tu diminues l'interpolation, plus tu te rapproches uniquement des frames de la boucle serveur, du coup ça sacade, car sans l'interpolation, tu n'as plus de mouvement fluide. Mais tu es sur que le jeu affichera uniquement les "vrai" positions des ennemis (les vrai frames serveur), alors que l'interpolation créer des frames coté client qui n'existe pas vraiment, et c'est le mécanisme de lag compensation qui essai de recalculer l'état du tick correspondant coté serveur pour savoir si en fait, là où tu visais était bien le bon endroit...
Du coup beaucoup de gens crient au scandale quand tu baisses ton lerp, car en jouant avec un jeu saccadé, ils ont aussi l'avantage de voir les "vrai" frames, ce qui évite par exemple de tirer un head shot et que celui-ci ne soit pas comptabilisé (car coté serveur, le joueur été plus loin qu'affiché sur l'écran client), ou encore dans le cas de left4dead2, on peut bloquer les attaques des zombies si on appuis sur la touche de contre sur la bonne frame, du coup jouer sur le lerp aide les joueurs expérimenté à définir le bon moment pour cliquer...

Bref, c'est vraiment pas évident tout ça^^

@niahoo : oui j'ai pas fait la réciproque.
Pour le cas que tu décris, il faudrait donc que le serveur lag, puis qu'un joueur tire un missile, et que juste après le serveur se mette a ne plus lager, et là les ticks suivants feraient effectivement, que le missile arriveraient très vite à la cible sans qu'elle n'est eu le temps d'esquiver...
Encore une fois, de mon point de vu, c'est pas censé arriver...