Projet Systèmes Distribués - 2018/19

Ce projet a pour but d'implémenter un jeu de dé, "le Cul de Chouette", librement inspiré de la série Kaamelott.

Règles du jeu

Principe général

Le Cul de Chouette se joue avec 3 dés à 6 faces et un maximum de 4 joueurs. Le joueur gagnant est celui qui atteint ou dépasse le premier le score de 343. Chaque joueur joue à tour de rôle et marque des points en fonction des combinaisons de son lancer de 3 dés. Certaines combinaisons impliquent une interaction entre les joueurs qui déterminera les points gagnés ou perdus.

Pour participer à une nouvelle partie, les joueurs désirant jouer se présentent auprès du maitre de jeu qui leur affecte un ordre et désigne le premier joueur à commencer. Une fois la partie lancée par le maitre du jeu, aucun nouveau joueur ne peut y entrer.

Combinaisons

Les dés se lancent en 2 fois : d'abord 2 dés puis le troisième. Le jet des 2 premiers dés est appelé la chouette et le troisième dé est appelé le cul.

Les combinaisons sans interaction :

Les combinaisons avec interaction :

Contraintes techniques

Identification des processus

Un serveur implémenté en C sera lancé avant les processus des joueurs. Son but est de donner un identifiant unique à chaque joueur. Un processus d'un joueur (implémenté lui aussi en C) qui se lance va créer localement une socket serveur TCP sur un port quelconque. Ensuite, il va envoyer une requête sur un groupe multicast UDP particulier en précisant l'adresse de sa socket serveur ainsi que le pseudo que le joueur a choisi. Le serveur est en écoute sur ce groupe multicast. Quand le serveur reçoit un tel message, il exécute les actions suivantes :

  1. Il détermine l'identifiant (un entier unique) du nouveau processus
  2. Il ouvre une connexion sur la socket serveur du nouveau client
  3. Il envoie via cette connexion au nouveau processus son identifiant ainsi que la liste des informations sur les processus déjà connectés, à savoir pour chacun d'entre eux : son identifiant, son pseudo et l'adresse de sa socket serveur TCP

Quand le nouveau client reçoit son identifiant et la liste des clients déjà connectés, il ouvre une connexion avec chacun d'entre eux puis leur envoie son identifiant et son pseudo. Ainsi, tous les processus effectuant ces actions, ils sont tous connectés les uns aux autres via des sockets TCP et se connaissent mutuellement.

Coté serveur, s'il y a déjà 4 processus corrects connectés, la demande d'entrer dans le jeu de la part d'un nouveau joueur est refusée.

Gestion d'une partie

A n'importe quel moment, un des joueurs peut décider de lancer une partie. Tant que la la partie en cours n'est pas finie, aucun autre joueur ne peut en lancer une autre. Ce joueur devient le maître du jeu. Il décide au départ du nombre de points à atteindre pour gagner et en informe les autres processus via les sockets TCP (un score de 343 est un peu long à atteindre).

Tous les joueurs actuellement connectés participent à la partie. L'ordre des joueurs est l'ordre déterminé à partir de leurs identifiants.

Il commence par lancer les dés (dont les valeurs sont choisies aléatoirement), d'abord la chouette puis le cul. Les valeurs de ces dés sont envoyés aux autres processus via les sockets TCP et affichés dans leur console (tous ce qui concerne l'évolution du jeu et des scores est affiché au fur et à mesure dans la console de chaque joueur).

Si le joueur fait une combinaison sans interaction, il marque les points et en informe les autres processus.

Si une combinaison nécessite une interaction, dans la console de chaque client, un mini-menu s'affiche en lui demandant de choisir entre "Grelotte ça picote !" et "Pas mou le caillou !". Le dernier ou le premier à répondre au maître du jeu (et à avoir envoyé la bonne réponse) perd ou marque des points comme précisé dans les règles en fonction de l'interaction. En cas de suite, si au bout de 5 secondes, un joueur n'a pas répondu, il est considéré comme perdant. Si plusieurs joueurs n'ont pas répondu dans les 5 secondes, ils sont tous considérés comme perdants.

Une fois que le maître du jeu a terminé son tour, il passe la main au joueur suivant qui lance ses dés et informe les autres joueurs de la même façon. Si une interaction est à gérer, c'est le maître du jeu qui s'en occupe.

A chaque tour, les nouveaux scores pour chaque processus sont envoyés par le maître du jeu à tous les joueurs et affichés dans la console.

Une fois la partie terminée, le maître du jeu envoie l'identifiant et le pseudo du gagnant à tous les processus. Il informe également des résultats un serveur en Java via une socket UDP (une socket unicast qui n'est pas celle du groupe multicast). Ce serveur conserve la liste des parties et fait la somme des points des différentes parties pour savoir qui est en tête. Chaque processus peut interroger via cette socket UDP le serveur Java pour connaitre les points cumulés de chaque joueur.

Gestion des crashs

Si pendant une partie, un joueur plante, chaque joueur doit être capable de le détecter. On considère dans ce cas que la partie est annulée.

Si un joueur plante entre deux parties, il faudra faire attention à ne pas le prendre en compte dans la liste des joueurs pour la prochaine partie.

Il faut prendre en compte aussi que le serveur Java peut également planter.

Travail attendu

Vous implémenterez le système distribué en respectant les spécifications précisées ci-dessus. Une évaluation sur machine de votre projet aura lieu le XXXX. Vous m'enverrez par mail un rapport ainsi que les sources de votre projet le même jour au plus tard.

Ce projet est à réaliser en binôme.