Discussion :

[francortes]

Bonjour à tous,

je travaille un projet de jeu de société pour 3 ou 2 joueurs sur plateau (Chifoomix) avec une approche tactique paradoxale (type Pierre-Ciseaux-Feuille). J'ai codé un prototype monoposte et j'aimerais l'étendre à un vrai multl-ijoueurs sur un site responsive.

Techniquement le site se présentera comme une application SvelteKIt,avec un échange de données bidirectionnel avec SocketIO et un back-end NodeJS avec base de données PostgrSQL ou SQLite.

Ma question porte sur le mécansisme de validation des règles du jeu par les différents joueurs dans un souci de minimiser lle charge CPU et mémoire sur le servcur.

Le moteur de règles du jeu est en cours de développement (d'apres un prototype) et se présente comme une lib JS indépendante, utilisable aussi bien sur le navigatreur que sur le serveur (module UMD); j'aimerais que le serveur ne s'occupe que du strict minimumu en ce qui concerne la validation d'un tour de jeu et qu'il ne serve que de "passe-plats".

J'imagine un système de "validation par les pairs", un peu comme dans la vie réelle, on valide sa partie/grille de jeu de lettres ou ses plies de tarot/belote par les gens autour de la table de jeu, sans avoir à nécessiter d'arbitre à chaque fois qu'on joue dans sa cuisine...

Imaginons 3 joueurs A, B et C chacun sur son portable avec une situation de jeu 'NOW'

* A joue PLY et applique les règles à NOW et calcule NEXT = rules(NOW, PLY)
* B qui stocke NOW recoit PLY et NEXT[A] calcule NEXT[B] et envoie PLY et NOW[B] au joueur C
* C qui stocke aussi NOW recoit PLY et NEXT[C] et calcule NEXT[C] qu'il envoie à A

Le joeur A compare NEXT[A] à NEXT[C] s'ils sont égaux envoie l'ordre de patching à B qui met à jour son état de jeu et le propage à C, qui met à jour son état interne et envoie confirmation à A.

Ensuite on peut passer au tour suivant et c'est à B de jouer et le cycle peut recommencer

A-B-C, B-C-A, C-A-B, et on recommence !

Le serveur lui se contente de passer les plats et n'historise que le mouvementeffectué et n'interviendrait qu'en cas de désaccord flagrant ou de triche pour ihnterrompre la partie le cas échéant.

QUESTIONS:

* Qu'ne pensez vous ?
*Faudrait il que je révise le fonctionnement d'anciens protocoles tels que les token rings pour les réseaux ?
* Est-ce qu'une telle mécanique de jeu est elle formulée quelque part sur le net ?

[Bousk]

Est-ce que c'est un truc temps réel ou tour par tour ?
Pourquoi un joueur ne serait pas host de la partie ?
Est-ce que le serveur a autant de logique que ça que son coût exploserait s'il gérait les règles du jeu ?

[francortes]

merci pour ces remarques très pertinentes. voici quelques éléments de réponse :

* Jeux en Tour par tour

* joueur-host: je n'avais pas envisagé cette possibilité mais pourquoi pas ? de toutes les façon il y a ura bien un joueur qui amorce la partie donc... bonne idée !

* serveur-host: je pense héberger sur un petit hosting plan du coup je ne vloulais pas surcharger le serveur en cas de grand nombre de parties,apres tout, il faut d'abord lancer le jeu, et scaler vers le haut que si nécessaire...

apres si j'ai envisagé de faire tourner le process de validation, c'est bien pour

* diminiuer la charge CPU et mémoire du serveur
* éviter latricher

[Bousk]

En tour par tour c'est plus simple.
Ton serveur est ce qu'on appelle un serveur relay. Il n'a aucune logique, il ne fait que transférer les données entre les clients.

Si tu as un host, il peut servir d'arbitre : c'est lui qui joue les coups et envoie l'état du plateau de jeu à jour aux autres joueurs après chaque coup. Il peut aussi valider ou non le coup. Chaque joueur envoie son coup à jouer uniquement.

Sans host, voici un exemple plutôt simple à mettre en place.
Quand le joueur envoie son coup à jouer, il envoie aussi un hash de l'état du jeu (avant ou après le coup joué localement).
Quand les autres joueurs reçoivent le coup à jouer, ils vérifient le hash.
Si le hash est ok, alors le coup est à priori valide : le plateau était dans un état cohérent, et le coup est acceptable et accepté et peut être appliqué.
Si le hash n'est pas ok, alors quelque chose a merdé : soit le joueur en question a un plateau désynchronisé, et le coup est potentiellement interdit. Soit le joueur a appliqué un hack chez lui pour désynchroniser le plateau.
Si tu n'as pas d'host, le joueur désynchronisé peut être exclu de la partie par les autres joueurs, et les joueurs restants continuent entre eux.
Si c'est une partie à 2 joueurs, il est impossible de savoir qui a raison et la partie est simplement avortée.

[francortes]

merci à toi !

la piste que je vais suivre sera bien celle d'un hash (ou checksum) que les joueurs calculeront pour valider le plateau. En deux tours :

1. envoi du coup joué et du hash. joueur suivants : jouent le coup, calculebnt leur hash et comparent à celui qu'ils ont reçu. Si OK, transmettent au joueur suivant le hash, si erreure un hash vide ou remplacé par une chaîne de caractères d'erreur.

2. quand le premier joueur recoit le hash du dernier, si toujours OK, fait tourner (ou brodcast) l'odre de commit du coup joué. En gros vu que c'est un petit plateau, c'est le joueur courant qui sert de host.

(pas besoin d'arbitre centralisé quand on joue au tarot à 5 autour d'une table, le consensus sifffit...)

En cas de désaccord flagrant, la partie sera purement et simplement arrêtée.

encore merci et bonne soirée ;-)