[DB-RS] FPS élevé crash

[Scozor]

Bonsoir à tous,

J'ai un gros problème concernant mon jeu en réseau. Ça fait maintenant 2 jours que j'essaie de synchroniser la vitesse du joueur au FPS afin que tout le monde soit à la même vitesse. Après avoir réussi j'ai testé localement sur la même machine avec deux clients lancés.

1 Hôte et 1 Client :

L'hôte est avec la verticale synchronisation (60 FPS).

Le client est sans la verticale synchronisation (Environ 2300 FPS).

Lorsque le client se connecte, l'hôte crash. L'inversement ne crash pas mais les mouvements sont comme des petites téléportations pour le client uniquement.

Je ne sais pas si j'ai bien expliqué mon problème, en tout cas n’hésitez pas à me redemander de reformuler mon (mes) problème(s) si vous comprenez pas.

Je remercie d'avance les futurs commentaires.

[Farstone]

Tu a besoin d'un système de "tick" pour envoyer t'es packets au serveur, si tu envoie des packet toutes les frame avec 2300 fps, normal que le serveur crash. Tu peux par exemple faire une queue de tout les packets à sérialiser et a chaque tick tu les regroupe et tu les envoie au serveur qui dé-sérialise (bitshifting nécéssaire) , tu peux aussi essayer un simple dequeue avec 1 packet à la fois, chaque tick.

[Scozor]

Problème résolu concernant le crash.

J'avais une fonction cliente qui était demandée d'être lue par le serveur sauf que je faisais appel à cette fonction à chaque frame. (Logique que ça crash car le serveur ne suivait pas par rapport aux demandes du client qui sont ultra rapides)

Je ne clôture pas le sujet car j'ai toujours mon problème de déplacement en une sorte de mini-téléportation quand il y a une différence d'FPS serveur/client (Uniquement quand c'est le serveur qui a énormément de FPS et que le client est à 60 FPS. (Le serveur voit le client sans cette sorte de mini-téléportation, le client voit le serveur avec)

[Scozor]

Tu a besoin d'un système de "tick" pour envoyer t'es packets au serveur, si tu envoie des packet toutes les frame avec 2300 fps, normal que le serveur crash. Tu peux par exemple faire une queue de tout les packets à sérialiser et a chaque tick tu les regroupe et tu les envoie au serveur qui dé-sérialise (bitshifting nécéssaire) , tu peux aussi essayer un simple dequeue avec 1 packet à la fois, chaque tick.

Merci de ta réponse, j'étais justement en train de répondre avant que tu postes ton commentaire.

Concernant faire une queue des mes paquets, comment gérer ça ? Je suis débutant dans le monde du réseau.

[Farstone]

Tu doit serializer t'es donnée en bytes et les deserializer sur le serveur pour récupéré le contenue, comme tu la compris avec cette limite des tick on cherche a maximiser les bytes maximum transférable sur le serveur (genre 1024) en compilant pas mal d'info en 1 au lieu d'envoyer un packet quand le player bouge, reçois des dégâts etc... Tu les fusionne en 1 packet pour optimiser tout ça, mais il va faloir apprendre le bitshifting et la sérialisation de donnée (attention au BinnaryFormater de .NET qui est très lent pour du jeu vidéo)

[boubouk50]

Au delà de la conception serveur, tu peux décider du framerate de l'application.
Time.framerate permet de fixer le rafraîchissement dans le FixedUpdate (). Peut-être qu'utiliser le FixedUpdate () serait avantageux.
(Là, je ne m'avance pas, ce n'est pas du tout mon domaine, le FixedUpdate () est normalement utilisé pour la physique, mais ça ne veut pas dire qu'il ne peut pas être utilisé à d'autres fins)

[Scozor]

Enfin j'ai trouvé la solution !

Alors la solution était toute bête, depuis le début le serveur synchronisé les mouvements uniquement si le déplacement était supérieur à 0.5. (J'ai probablement confondu entre le mouvement et la velocity)

Enfaîte ça n'a aucun rapport avec le FPS du serveur et celui du client.

En ce qui concerne l'actualisation par le FixedUpdate je préfère le laisser par défaut. Comme mentionné dans la documentation il est généralement utilisé pour la physique.