Citation:
Envoyé par
Fraggy
Y a tj la possibilité du cryptage et des signatures. le serveur refuse les paquets non ou mal signés (evite les pb de faux clients). le client crypte (clé double) pour empecher les modifs à la volée (évite les patchs pirate)
J'ai du mal à voir comment tu peux t'assurer de la non modification du client en cryptant. Tu peux détailler ?
Citation:
En gros, si tu dates pas, tu t'en sors pas.
+1
Citation:
Halo 2 aussi faisait du datage de paquet reseau : les grenade sont rigolotes, elle explose en "retard", cad une fois que tous le monde a recu l'information d'explosion de grenade. Ca permet de "tuer" sans erreur ni besoin de rollback.
C'est le principe évoqué plus haut du "pour les événements importants", on préfère attendre un confirmation du serveur (l'exemple avait été pris des pertes de points de vie dans Counter Strike).
Par contre, je ne comprend pas pourquoi tu dis qu'elles explosaient 'en retard'. Parles-tu du feedback visuel dans le jeu (question ouverte: je ne connais pas le jeu) ?
Parce que logiquement (si c'est une grenade à explosion à T+x secondes après l'avoir lancée, x constant) le client peut déterminer dès le lancer de la grenade à quelle date exacte l'explosion doit avoir lieu, et jouer l'animation d'explosion au bon moment, quitte a ne répercuter les 'morts' et pertes de points de vie qu'après. Ce que fait Counter Strike par exemple.
Citation:
D'ailleurs, les données transferées ne correspondaient pas au deplacement pas a pas, mais aux évènements (je tourne, j'avance a x m/s, je tire, je me baisse etc...) ca permettaient de réduire drastiquement la quantité de données à transférer.
Par voie de conséquence il faut non pas stocker les positions de objets sur les 8 dernieres frames, mais stocker les évènements qui ont eu lieu pour tous les objets en mouvement.
Tout dépend si ton stream réseau est fiable ou non: s'il n'est pas fiable (UDP), tu es obligé d'envoyer des valeurs absolues ; s'il est fiable (TCP), là tu peux te permettre de n'envoyer que des deltas.
De toute façon, envoyer une trame de quelques vecteurs une vingtaine de fois par seconde reste largement en dessous des capacités des lignes actuelles. C'était surtout vrai du temps du modem RTC 56k.
Citation:
Le lag compensation ne résould pas tout : comme la gestion du lag augmente arithmétiquement avec le nb de joueur, on se retrouve rapidement a bout de solution quand on a plus de 32 ou 64 joueurs.
Pas nécessairement le lag peut être introduit par deux facteurs:
- le lag au niveau couche 'réseau' dépend de la capacité de ta connexion. Or les connexions sont largement dimensionnées maintenant pour supporter le streaming des infos de 100 utilisateurs en simultané.
- le lag au niveau capacité de traitement du serveur: le traitement et le renvoi des données pour 100 utilisateurs peut prendre un temps infime (moins d'une ms) même pour un jeu avec 100 utilisateurs connectés, la différence de lag serait alors tout aussi négligeable pour 2 utilisateurs que pour 100. A ce niveau, tout dépend du jeu et de sa complexité.