Unity Networking, The Experience en 3D

[schouffy]

Cependant, nous sommes en 2015 et des techniques permettent de masquer cette horreur.

Quand tu dis "nous sommes en 2015" c'est une façon de parler, ou ces techniques sont vraiment récentes ? Car ça parait vraiment trivial comme concept ?!

[Orhin]

Quand tu dis "nous sommes en 2015" c'est une façon de parler, ou ces techniques sont vraiment récentes ? Car ça parait vraiment trivial comme concept ?!

C'est une façon de parler, ça existe depuis un paquet d'année.

[Louck]

Comme dit, c'est une façon de parler .

Par contre il faut savoir que j'ai mis en place une interpolation toute bête pour ces démos.
En réalité, il faut réfléchir si notre jeu-vidéo est viable avec de l'interpolation ou de l'extrapolation, et il faut penser à comment bien le mettre en place. Car dans les faits, l'interpolation génère une certaine latence: l'information du serveur arrive un peu plus tardivement à notre écran.

Une mauvaise interpolation combiné à de la prédiction, tu as le fameux "peeking advantage" de CS:GO .

Mais cela n'a jamais été un problème très simple à régler. Tous les jeux ont ce genre de défaut ou quelque chose qui s'en approche.

[xviniette]

Le problème c'est que le tickrate signifie le nombre de "simulation" du monde par seconde et non le nombre d'envoie de snapshot/sec. Donc oui ça impacte les collisions, hittest, etc...

Pour plus d'informations : https://developer.valvesoftware.com/...sic_networking

Je pense qu'il est compliqué de critiquer le networking de CS:GO qui est un des (si ce n'est le) plus propres des jeux actuels.
Le peeking advantage est logique (même sans interpolation il y a peeking advantage), et je ne vois pas de façon de le supprimer.

[Louck]

Concernant la définition, de ce que je disais:

Tout d'abord, lorsque je parle du tickrate, je fais référence à la fréquence d'envoi des snapshots/mises à jours/données sur le réseau par le serveur ou le client.

Je suis d'accord que dans ta définition - où le serveur peut restreindre la fréquence de simulation de son monde - le tickrate peut avoir un certain impact sur le gameplay du jeu.

Si je l'ai précisé, c'est que la définition varie selon les moteurs utilisés, ou selon le contexte. Même si nous sommes d'accord que le wiki de Valve est une grosse référence quand on s'intéresse aux jeux en réseau, leurs définitions de tickrate/sendrate/updaterate sont propres à eux et à leur moteur de jeu.
Par exemple, dans l'ancienne version de l'API d'Unity3D, il est possible de paramétrer le "SendRate" du côté client et du côté serveur. Pour Valve, le "SendRate" n'est invoqué que du côté client. Ce n'est pas la même chose .

Bref, je ne veux pas jouer avec les mots non plus . Mais il est vrai qu'il est important de bien détailler sa propre définition des termes afin qu'il n'y ai pas de confusion. Certains joueurs possèdent ta définition du tickrate, d'autres ont la mienne (et bien d'autres ont leurs propres termes).

Je pense qu'il est compliqué de critiquer le networking de CS:GO qui est un des (si ce n'est le) plus propres des jeux actuels.
Le peeking advantage est logique (même sans interpolation il y a peeking advantage), et je ne vois pas de façon de le supprimer.

Sans aucun doute.

Il y avait eu une certaine mise à jour de CS:GO qui impactait un paramètre de l'interpolation (je n'ai plus le nom malheureusement). Hors à ce moment le paramètre était mal réglé, et le peeking advantage était obvious.
Mais je suis d'accord que tant que le jeu supporte la prediction, il y aura le peeking advantage. Etant donné que l'avantage est mesuré en dixième de secondes (sauf si mauvais paramétrage), je ne sais pas si cela une vrai importance dans les jeux compétitifs (EDIT: Sur les parties publiques, c'est "contré" par le lag compensation).


PS: Comment je vais bien me casser la tête sur mon jeu multijoueur pour bien configurer l'interpolation et la prédiction.