Mouvement et jeu en temps réel?

[niahoo]

Il n'y a pas de différence entre ce que propose oxman et moi. (enfin si, lui il met à jour le serveur à intervalles régulières, moi dès que la connexion est libre -- dans les deux cas tu peux également le faire au travers du websocket pour accélérer le traitement, ce n'est pas spécifique à AJAX)

Dans mon cas comme dans le sien, si un joueur se téléporte loin sur la carte et tire sur un ennemi, ton serveur aura en mémoire sa position précédente à partir de laquelle il ne peut pas atteindre cet ennemi, ou bien il recevra la nouvelle position et là ben ton contrôleur doit calculer que le joueur n'a pas pu se déplacer si vite.

Effectivement je me rends compte qu'en n'envoyant pas chaque déplacement ou chaque direction ça laisse une faille. Tu peux stocker les déplacements dans un tableau, et à chaque fois que tu clear la queue tu renvoies le contenu du tableau complet au lieu du dernier déplacement. Quand une requête part effectivement, tu effaces du tableau les déplacements qui ont été envoyés. Tu les identifies tous grâce à un nombre que tu incrémentes, et côté serveur tu gardes une trace de ce nombre pour savoir quel est le numéro du dernier déplacement effectué pour que quand l'envoi d'une requête chevauche le nettoyage de la précédente, on évite de traiter des mouvements déjà effectués. Mais bon ça fait un peu du bordel pour pas grand chose.

Donc reste plus qu'à envoyer tous les déplacement. J'aimerais bien voir ce que ça donne le jeu de Maks sur un serveur (pas en local), voir si c'est effectivement viable.

[Argorate]

Oui j'ai regroupé ta réponse avec celle de oxman dansm a réponse^^

Le coup d'envoyé la liste des déplacements durant l'elipse de temps où tu as pas informé le serveur, c'est bien, sauf que de la même manière ça peut être modifier non? es-ce que ça ne reste pas une faille?
Si on part du principe que tout le JS est falsifiable, c'est rapidement chiant en fait un jeu multijoueur avec bcp de JS...


PS: je veux bien une demo pour voir aussi maks, on pourrait potentiellement tous s'entraider sur ce genre de problème purement technique

[Ter Rowan]

Oui j'ai regroupé ta réponse avec celle de oxman dansm a réponse^^

Le coup d'envoyé la liste des déplacements durant l'elipse de temps où tu as pas informé le serveur, c'est bien, sauf que de la même manière ça peut être modifier non? es-ce que ça ne reste pas une faille?
Si on part du principe que tout le JS est falsifiable, c'est rapidement chiant en fait un jeu multijoueur avec bcp de JS...


PS: je veux bien une demo pour voir aussi maks, on pourrait potentiellement tous s'entraider sur ce genre de problème purement technique

on s'en fout que ce soit falsifiable, ton serveur vérifie la liste et n'envoie que les informations validées aux clients

[niahoo]

Ben oui. Pasque même ce qu'à fait Maks est falsifiable : tu coupes le Websocket et tu en réouvres un perso, tu peux lui faire envoyer ce que tu veux ...

---

Et puis la liste des derniers déplacements, si elle est falsifiable, elle va être contrôlée.

Donc, soit c'est des mouvements que le joueur n'aurait pas pu faire et tu ne les prends pas en compte, il est donc bloqué sur place + tu le déco un p'tit coup.

Soit c'est des mouvements qu'il aurait pu faire et là ben si il les a injectés il s'est grave fait chier pour rien, donc tu les acceptes et pis wala.

[Argorate]

Oui c'est pas faux ! Mais le problème alors c'est: comment vérifier à retardement?

Car admettons qu'on ait une liste de 5 cases qu'on envoi au serveur, elles sont correct car accessiblent et elles se suivent, tout est en règle, sauf que au moment où le serveur vérifie le monde n'est plus comme il l'était quand le mouvement c'est réellement fait, et du coup y avait peut être un obstacle sur l'une des cases à un des déplacements (autres joueurs sur la case ou un mob ou autre...)

A moins d'historisé tous les déplacements de toutes les entités (même non joueurs), comment faire?!
Et si on choisit de faire cet historique, es-ce que c'est pas un peu lourd?
Ca fait une table qui se remplit vite, avec des insert récurent + des select dessus très récurrent aussi pour la vérif des que qqun fait un déplacement... ça fait utiliser pas mal de ressources

[Maks]

Donc c'est ce que tu fais Maks, tu push au serveur les mvts? Sinon j’envoie aussi uniquement la direction et non des coordonnées, puis je vérifie coté serveur que la case de destination est dispo.

Oui. Un cas classique :
Client émet 'move', {direction: 3}
Serveur traite la demande de mouvement
Si c'est ok serveur émet pour tout le monde dans la room : 'move', {_id: "uuid", direction: 3}
Sinon émet pour tout le monde 'setDirection', {_id: "uuid", direction: 3}
pour replacer le personnage dans le bon sens (important pour la gestion des ciblages)

Après le problème de gérer la concurrence: le fait de faire une attaque alors qu'on ne devrait pas par exemple, c'est justement très lié au fait de vérifier tout les déplacements, non?

Si tu vérifies tout, avec un serveur dit "autoritaire", ça ne peut pas arriver.
Cf. j'avais linké : http://gamedev.tutsplus.com/articles/glo...rediction/
D'ailleurs ce site se remplit de plus en plus, il va rapidement devenir incontournable je pense

Ce qui m'amène à répondre aux propositions du système de queue ou de ne pas envoyer tous les déplacements (et donc ne pas faire toutes les vérifications), c'est quand même risqué. Il suffit qu'un mec ajoute sa fonction JS de téléportation, et ainsi il pourra facilement tricher et esquiver des attaques par exemple ou lancer des attaques alors qu'il ne devrait pas justement... C'est ça qui m’embête dans le fait de ne pas tout vérifier.

Il ne faut pas être trop parano non plus je pense, il vaut mieux ne pas passer trop de temps sur ces questions au début je pense vu le temps que ça prend

Pour l'histoire de l'IA maks, tu fais comment pour qu'il soit indépendant, tu as un script qui tourne en boucle quelque part sur ton serveur et qui lance des push pour les actions d'IA de temps en temps?
Puis pour l'histoire de l'attaque d'un mob mort, si tu vérifies l'existance du mob avant l'attaque ET juste avant le save() des dégats et autres sur la cible, ça devrait résoudre le pb non? Comme ça tu es sur que pendant toutes la "transaction" de l'attaque, le mob existe tjs.
Le problème c'est que ça te fais refaire une requête SQL à la fin de chaque attaque pour la valider, mais bon...

Oui, en fait côté serveur j'ai une boucle qui est l'équivalent de la boucle qui tourne sur le client. Et qui de temps en temps émet des actions.
Oui pour l'existence du mob, le workaround est simple mais ça ne devrait pas se produire idéalement.
Sinon il n'est pas question de requête SQL pour mon cas ^^ A dire vrai, je fais très très rarement des requêtes. La room s'auto-suffit et je met à jour la BDD uniquement lorsqu'un joueur la quitte ou la rejoint. C'est une stratégie risquée si Node crashe. D'autant plus que les requêtes étant asynchrones ça ne me couterait rien d'en faire plus souvent. Il faut encore que je réflechisse à la question.

Donc reste plus qu'à envoyer tous les déplacement. J'aimerais bien voir ce que ça donne le jeu de Maks sur un serveur (pas en local), voir si c'est effectivement viable.

Moi aussi, c'est un peu le bad honnêtement. J'ai prévu le coup en exposant au client les méthodes utilisées sur le serveur pour vérifier les déplacements/actions ce qui devrait me permettre de mettre en place la prédiction sans trop suer (on peut rêver).

PS: je veux bien une demo pour voir aussi maks, on pourrait potentiellement tous s'entraider sur ce genre de problème purement technique

Je n'ai pas de serveur en ligne pour faire le test malheureusement. Le code est prêt cependant.

Ben oui. Pasque même ce qu'à fait Maks est falsifiable : tu coupes le Websocket et tu en réouvres un perso, tu peux lui faire envoyer ce que tu veux ...

Non car il me suffirait de désactiver la reconnexion. Et lorsque l'on se connecte, l'id du joueur est défini côté serveur, non modifiable et toujours attaché à la socket sans que le client ne l'envoie en clair. Ainsi on ne peut pas voler la socket d'un autre joueur.

[Argorate]

C'est bien pensé pour l'anti vol!
Au fait tu fais ça en canvas toi du coup?

Sinon, tu ne réponds pas au problème de la vérification des mouvements (voir mon post ci-dessus)?!

[Maks]

J'envoie case par case

Oui j'utilise canvas.

Dans le cas d'un pathfinding, idéalement en cas d'obstacle je recalculerais le chemin pour que le déplacement continue.

Sinon si ça bloque, principe de la prédiction, tu dois réajuster le client pour replacer le joueur à la case bloquante.

Je trouve pas de vidéo sur youtube là, mais je me souviens que sur le jeu Gears of War (le premier) sur Xbox, les parties étaient hostées par un joueur et non un serveur. Et on voyait clairement le système de prédiction lorsque ça laggait énormément : le personnage avançait normalement et lorsque l'on recevait les infos du serveur, on était téléporté loin en arrière.

Dommage que le code source de bombermine n'est pas dispo, car ça marche parfaitement sans lag : http://bombermine.com

En ce qui concerne le nombre, ça n'est pas réellement un problème. Il suffit de créer des instances différentes (plusieurs serveurs) comme ça se fait actuellement sur les MMORPG et de mettre un nombre de joueurs limite. Limiter aussi la taille des maps. Mais les essais que j'ai fais sur de très grosses maps étant concluants (en local encore une fois).

[niahoo]

Mais le joueur peut utiliser ton code d'ouverture de socket, il n'a qu'a simplement remplacer les handlers par les siens ... Du coup tu ne sais pas s'il vient d'ouvrir une page ou si c'est une reconnexion.

Mais je pense que tu as raison, tout ça c'est un peu prématuré, mieux vaut d'abord avoir un système qui tourne proprement que de vouloir vérifier la triche.

Argorate si tu fais des snapshot de toutes tes cases à intervalles réguliers ça va être bien lourd oui. Si certaines cases ont des rochers qui empêche le déplacement mais qui peuvent être détruits ça complique pas mal les choses. Mais il ne faut pas oublier qu'on reste, normalement, sur des latences moyen-courtes (2 secondes au maximum, ensuite on considère qu'on a du lag et ça ça s'éradique au lieu de penser le jeu pour gérer le lag totalement).

Donc, pendant deux secondes, si ton joueur essaie de marcher sur contre rocher en continu (mode lara croft) ben le serveur refuse et ne le déplace pas.. Puis quand le rocher est détruit, le serveur se met a accepter ses déplacements. Donc, le cas où un joueur "triche" en envoyant au serveur une position sur un rocher et où le serveur l'accepte n'arrive que si le joueur "triche" moins de 2 secondes avant la destruction du rocher et que la requête qui pète le rocher est arrivée avant celle du déplacement. Les requêtes se faisant souvent, tu ne stockes pas cinquante déplacements côté client avant de les envoyer. Le serveur garde une trace du dernier déplacement et ne doit autoriser que X déplacements par seconde. Si le dernier déplacement qu'il a date de 3 secondes et que quelqu'un lui en envoie 50, il sait que c'est de la triche et balance tout dans /dev/null

C'est pas clair mais en gros tu vois l'idée : la marge d'erreur pour ces obstacles correspond peu ou prou à la précision temporelle de ton jeu (dison la précision temporelle de ta connexion client/serveur) .. donc autant l'accepter.

Maintenant faudrait implémenter tout ça pour voir si ça rend bien au feeling.

[Argorate]

je ne vois pas pourquoi tu parles de pathfinding alors que le déplacement ce fait au clavier au choix du joueur, tu n'as pas d'algo a faire...
Donc le truc c'est que toi tu n'as pas de bd derriere et que tu ah juste un serveur node, du coup tu mets a jour la variable coté node et c tout? forcement c plus rapide, en plus de l'utilisation des ws, je comprends que ça lag moins^^


Pour bombermine, hote moi d'un doute, je suis habitué a push avec pubnub (n'ayant pas d’hébergement autre que mutu pour l'instant), qui lui utilise le longpolling, du coup y a tjs une trace de requête qui tourne en boucle dans firebug, hors là pour bombermine, je ne vois absolument rien dans firebug, les websocket ne laisse pas de trace?
j'avoue qu'il y a l'air d'avoir pas mal de joueur syncro en meme temps, et ça marche plutot bien...