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