Description générale du projet

1 Description générale du projet

1.1 Objectif

L'objectif est de créer des costumes (des tee-shirts en l'occurrence) et un logiciel permettant de jouer à un jeu collectif. Le jeu s'intitule 'le jeu du mouton" et il consiste à parier sur la réaction des autres joueurs.

1.2 Règle du jeu

Avant le lancement d'une partie, chaque joueur choisit le rôle du mouton blanc ou le rôle du mouton noir. Dans le rôle du mouton blanc, le joueur doit s'efforcer de suivre le même comportement que les autres joueurs quelque soit leur rôle. Dans le rôle du mouton noir, le joueur doit arriver à se distinguer des autres joueurs. Dans cette version du jeu, les groupes sont constitués en fonction de leur position. Les cinq positions possibles sont : buste droit, buste penché vers l'avant, buste penché vers l'arrière, corps penché vers la droite, corps penché vers la gauche.

Un étape commence par un avertissement de la part du contrôleur, les joueurs ont alors quelques secondes pour prendre position. Les positions sont relevées et les groupes formés. Un mouton blanc se trouvant dans un groupe de cardinalité non maximale est éliminé. Un mouton noir se trouvant dans un groupe de cardinalité non minimale est éliminé. Une autre étape est lancée avec les joueurs non éliminés. Le jeu se termine quand il ne reste plus qu'un ou deux joueurs. Ces joueurs sont déclarés gagnants.

1.3 Architecture générale

Les costumes remontent les informations de leur capteur de position à un serveur de jeu qui décide des joueurs éliminés à chaque phase du jeu. Le costume est réalisé à base d'Arduino Lilypad.

La remontée des données se fait par communication sans fil XBee entre le costume et un processus client tournant sur le PC associé au costume puis par TCP/IP entre le processus client et un serveur de jeu central. Le serveur central est choisi parmi l'un des processus client.

L'architecture de communication est établie en utilisant un exécutable d'administration sur chaque PC qui demande au processus client d'établir une connexion TCP vers le serveur de jeu. La communication entre l'exécutable d'administration et le processus client est réalisée par une file de messages (IPC).

1.4 Conception du costume

Le costume est réalisé avec un module Lilypad intégrant un micro-contrôleur atmega328p, un module de communication série sans fil XBee et divers capteurs et actionneurs ; un accéléromètre, une led RVB, un vibreur et un buzzer.

La programmation du micro-contrôleur se fait en utilisant l'IDE arduino. L'algorithme du micro-contrôleur consiste en la lecture des ordres arrivant sur le port série et en la réalisation des actions ou mesures demandées. Les valeurs mesurées sont renvoyées via le même port série.

Prenez soin de configurer vos deux modules XBee pour qu'ils puissent communiquer entre eux sur une fréquence leur étant propre.

1.5 Conception de l'application client/serveur

L'application implante deux fonctionnalités. Une fonctionnalité de gestion de costume qui est activée si le joueur participe à un jeu et une fonctionnalité de serveur de jeu qui est activée si d'autres gestionnaires de costumes se connectent à lui.

La gestion du costume est à implanter dans un processus léger dédié. Ce processus se contente de lire les instructions du serveur de jeu arrivant par la connexion TCP et à les répercuter au costume via le port série du PC.

La fonction de serveur de jeu consiste à accepter les connexions des autres gestionnaires de costumes et a superviser un jeu sur demande de l'administrateur. Un processus léger doit être utilisé pour conduire le déroulement du jeu.

Enfin, un dernier processus léger est chargé de traiter les requêtes de l'exécutable d'administration.

1.6 Connexion au serveur de jeu

Quand un gestionnaire de costume C se connecte par TCP au serveur de jeu J, le protocole décrit ci-dessous doit être respecté.

C se connecte sur le port d'écoute TCP de J ;
C indique son pseudo par la commande pseudo suivie du dit pseudo ;
J indique si le pseudo est libre par OK ou NOTFREE ;
C indique son mode de jeu par la commande mode suivie du mot blanc ou noir ;
J doit répondre par OK si la syntaxe est correcte et par ERROR sinon ;
J peut demander à C de déclencher un actionneur par la commande SET, C doit répondre par OK, si ce n'est pas le cas la connexion est rompue ;
J peut demander à C de récupérer la valeur d'un capteur par la commande GET, C doit répondre par OK value où value est la valeur retournée par le capteur ;
si C se déconnecte, J arrête le processus léger correspondant et retire le joueur du jeu ;
si J se déconnecte, C arrête le processus léger de gestion de costume.

La commande SET est suivie d'un mot clef indiquant l'actionneur concerné et de paramètres permettant de le configurer. Voici les syntaxes à utiliser pour ce projet :

SET LED color : color est un octet écrit en hexadécimal dont les deux bits de poids faibles représentent le niveau de bleu, les deux bits suivant le niveau de vert et les deux bits suivant le niveau de rouge (les deux bits de poids forts sont fixés à zéro) ;
SET BUZZ frequency : frequency est un octet écrit en hexadécimal représentant la fréquence à jouer sur le buzzer (0 pour le la 220Hz et 6 pour sol) ;
SET VIBE duration : duration est un octet écrit en décimal représentant la durée de la vibration en secondes limitée à 15 secondes.

La commande GET n'a qu'une syntaxe : GET ACCEL. Aucun paramètre n'est requis mais le gestionnaire de costume doit retourner un octet écrit en décimal représentant la position du joueur. Les positions sont notées de 0 à 4 dans l'ordre où elles sont décrites dans la section 1.2.

1.7 Les requêtes administrateur

L'administrateur lance le client d'administration à chaque fois qu'il veut effectuer une requête (la requête est fournie en argument). L'administrateur peut envoyer plusieurs requêtes simultanément, c'est à dire exécuter plusieurs instances du client d'administration simultanément. Les requêtes à disposition de l'administrateur sont les suivantes :

aide :: obtenir la liste des requêtes possibles ;
score :: indique si un jeu est en cours ou si un jeu est terminé, liste les joueurs avec leur état (en lice, éliminé ou à défaut connecté) ;
mode {blanc|noir} :: préciser le mode du joueur ;
connecter <pseudo>:[<port>@]<nom machine> :: se connecter à un serveur distant, lancer le processus de gestion de costume si la connexion est correctement établie ;
deconnecter :: déconnecter le gestionnaire de costume du serveur de jeu, arrêter le processus léger ;
demarrer :: lancer un jeu avec les joueurs connectés ;
arreter :: arrêter le jeu en cours ;
suivre :: suivre les événements du jeu, c'est à dire que l'administrateur attend et affiche les événements suivants envoyés par le serveur de jeu ; démarrage du jeu, signalement de pré-étape, signalement de fin d'étape, liste des positions des joueurs, liste des joueurs éliminés, liste des joueurs toujours en lice, fin du jeu ;
stopper :: arrêter l'application.

Tout dialogue entre le serveur de jeu et le client d'administration est réalisé par des communications IPC (envoi et réception de messages). Pour permettre l'exécution simultanée de plusieurs clients d'administration, il faut créer une file de messages de réponse par client et envoyer le descripteur de cette file dans les requêtes. Pour implanter la commande suivre, il est recommandé de définir, au niveau du serveur de jeu, un tableau des clients d'administration en attente d'événements. Ainsi à chaque nouveau événement à leur transmettre, il suffit de parcourir ce tableau et de les contacter sur leur file de messages de réponse.