Jeux multijoueurs lags et triches

[Aleskweb]

Bonjour,

Je suis me pose en ce moment quelques questions sur la façon de diminuer l'influence des lags et des triches dans les jeux multijoueurs en temps réel.
Posons un Mario like multijoueurs, donc avec une gestion des collisions et qui inclue donc un moteur physique.
La solution pour contrer les lags et les triches (par triche j'entends par la la modification des variables via la console par exemple) serait de faire tourner le moteur physique à la fois sur les clients ainsi que sur le serveur.
Mais cette solution requiert vite des gros serveurs.
Je me demandais donc comment sont gérées les interactions nécessitant une gestion des collisions. Metons un joueur A lance un projectile sur B. Ce serait le serveur qui détecterai la collision ou alors les clients qui enveraient au serveur l'information de collision.?

Voilà j'aimerais avoir votre avis sur le sujet.

Cordialement, Aleskweb

[Maks]

http://gamedev.tutsplus.com/tutorials/im...rediction/

[Aleskweb]

Merci, j'avais déjà lu cet article. Mais ce n'est pas exactement la réponse à la question que je me pose.
Pour les déplacements sur une surface plane pas de problème. C'est surtout en ajoutant un moteur physique que ça pose problème. D'autant plus que box2Dweb est asynchrone par rapport au rendu et doit tourner à un fréquence fixe. Si le client ralentis en dessous de cette fréquence ça rajoute encore plus de décalage.

[Maks]

Ah d'accord, j'avais lu un truc sur le sujet en anglais sur mes recherches en anglais sur la prédiction (j'avais créé un sujet ici si tu veux). Il me semble que dans le cas des animations du moteur physique, c'est le client qui décide. Dans le cas d'un projectile, c'est le serveur qui dit "ça touche" (ou qui confirme la prédiction) mais c'est le client qui décide si les particules générées par le projectile vont dans tel ou tel sens. Ainsi sur deux clients différents tu ne peux pas avoir exactement la même animation.

C'est le cas dans mon jeu par exemple. Quand je lance une attaque longue portée et que je touche un ennemi qui meurt, alors les particles sont générées mais selon un random dépendant du client. Sinon t'aurais pas fini de gérer tout ça avec le serveur

[Aleskweb]

Oui plus d'informations sur la prédiction me seraient utile. Mais je pense que l'utilisation de la prédiction à aussi des inconvénients. (c'est frustrant de se voir frapper l'adversaire mais ne pas lui faire de degats)
Si le client gère tout seul les collisions avec le décor alors il pourrait modifier les attributs des éléments et les rendre traversable par exemple. Ce qui poserait pas mal de problemes

[Argorate]

Non, cela ne pose pas de problème pour les déplacements, dans le sens où le serveur n'en tiendra pas compte s'il y a triche...
C'est exactement ce que j'ai fini de coder cette semaine: j'ai un json qui contient les cases bloquante de ma map, si tu le modifies, certes tu peux traversers les murs cotés clients (animation), mais en réalité, si tu fais f5, tu n'as plus bougé depuis que tu es collé au mur que tu as tenter de traverser "illégalement". Du coup si le joueur tente de déclancher une action suite a la triche coté client, le serveur verra tout de suite que le joueur n'est pas au bon endroit pour faire ce qu'il demande de faire.

Mais je suis d'accord que j'ai aussi pas mal de questions en suspens sur comment gérer justement les vérifs serveurs systématique pour un jeu en temps réel, sutout quand il y a des jets de projectiles pour faire calculer au serveur si le projectile touche bien, et puisqu'il y a des décalage dans l'animation, du au lag, il se peux qu'un projectile touche, mais qu'il ne le fasse pas coté client à cause d'une animation lancé en retard (pas de colision coté client), et du coup ne demande meme pas au serveur de véridié si ça touche (et donc pas de dégat), alors que c'est pourtant le cas...

[Aleskweb]

Oui mais si je veux que le serveur ne tienne pas compte de ce que me dis le client sur sa position, alors il faudra faire tourner le moteur physique aussi sur le serveur.
En fait, j'aimerais trouver une alternative pour éviter de faire tourner des scripts trop gourmands aux serveur tel que les moteurs physiques.
Aussi vu que je travaille en websockets, j'utilise pas trop f5 pour rafraichir :p
Sinon merci pour les infos

[Sephi-Chan]

Il faut effectivement un serveur qui fait résout tous les mouvements tout en envoyant certains éléments clé au navigateur (grâce au push) pour qu'il cesse/débute/change les animations et actions qu'il opère sur la représentation visuelle.

Bien sûr, pour améliorer l'expérience et ne pas systématiquement attendre le serveur, il faut exécuter tout dans le navigateur, pour avoir une représentation la plus fidèle possible de ce qui est réellement résolu par le serveur.

[Argorate]

Je pense que tu n'as pas compris ce que j'ai dis, mon jeu utilisera les websocket et n'aura pas de F5. Le fait de faire F5 ça te montre le jeu tel qu'il est coté server/bd, c'est pour ça que j'ai dis ça.

Tu es obligé de faire la vérif coté serveur puisque tu ne peux pas te fier au donnée client, donc je vois pas cmt faire autrement...

[Aleskweb]

Merci pour vos réponses. Oui j'ai compris le principe, même si le joueur triche, ce sera juste sur son ordinateur. Les autres verrons le jeu de la facon dont il devrais se dérouler.
Avez vous des approximations, si on fait des threads avec un moteur physique par thread (Hum d'ailleurs je crois que javascript ne gere pas les thread mais c'est une autre question) de la consommation de chaque threads?