Mouvement et jeu en temps réel?

[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.