Previous Contents Next

2   Description des composants du projet

2.1   Architecture générale

Les accessoires permettent d'informer les joueurs des différentes phases de jeu et de remonter l'accéleration des bracelets vers un système distribué de processus Unix permettant de gérer le jeu.

La transmission des données se fait par communication sans fil XBee entre les accessoires et un processus Unix tournant sur le PC associé aux accessoires puis par TCP/IP entre les différents processus Unix.

Chaque processus Unix gère le score indépendamment des autres processus à l'aide des informations remontés des accessoires et diffusés en UDP par les autres processus. Un processus doit aussi gérer des connexions TCP pour permettre aux utilisateurs d'avoir des informations sur le déroulement du jeu (comme l'état des joueurs par exemple).

2.2   Conception de l'application UDP distribuée

Le principe est d'avoir une architecture distribuée pour implanter la gestion du jeu. Aucun processus Unix n'aura de rôle prédominant et chacun doit pouvoir tenir à jour l'état de son joueur en fonction des messages échangés par diffusion UDP.

Vous commencerez par attribuer un numéro unique à chaque processus par échange de messages. Le processus tire un numéro au hasard, envoi un message pour vérifier qu'il est libre et recommence s'il ne l'est pas.

Chaque processus s'annonce réguliérement à l'aide de son numéro unique et signale ainsi sa présence aux autres processus qui peuvent établir un tableau des joueurs.

Une partie débute lorsqu'un et un seul animateur est présent et qu'il indique son intention de lancer le jeu. A partir de ce moment les processus qui se sont déjà signalés savent qu'ils participent au jeu et arrêtent de se signaler. Les processus se signalant après ne peuvent plus participer à ce jeu. Pour gérer le cas des participants tardifs, c'est à dire se signalant en même temps que le lancement du jeu, les joueurs se signalant en cours de première manche sont pris en compte.

Durant un jeu, l'animateur prévient qu'il va effectuer un geste et effectue ce geste. Les deux événements sont diffusés par UDP. Lors de la réception de l'avertissement les autres processus se mettent à leur tour en attente du geste de leur joueur. Le geste est diffusé dès sa réception. Si un processus s'aperçoit qu'il est le dernier, il peut annuler son attente et diffuse un message de geste trop tardif. Cette procédure permet à chaque joueur de savoir s'il est éliminé ou non.

Le processus de l'animateur laisse son joueur relancer une manche après un temps court faisant suite à la réception du premier geste correct (ou du dernier geste si aucun n'est correct). Les joueurs éliminés restent inactifs jusqu'à la fin de la partie. Une partie se termine quand au plus un joueur reste en lice.

Le format des messages UDP est laissé à votre bon soin. Il est évident qu'un format unique doit être adopté par la promotion.

2.3   Les requêtes des clients TCP

Un utilisateur peut se connecter sur le port TCP d'écoute d'un quelconque processus Unix. Un processus Unix doit pouvoir gérer plusieurs processus Unix simultanément. La connexion TCP se fait avec un utilitaire comme nc. Les ordres que l'utilisateur a à sa disposition sont :
aide :
obtenir la liste des ordres possibles ;
joueurs :
donner la liste des joueurs (identifiant et nom de machine hôte) s'étant signalés ou en compétition, le type de chaque joueur (animateur ou compétiteur) doit être précisé ;
score :
si un jeu est en cours, donner l'état des joueurs, c'est à dire s'ils sont encore en lice ou à quelle manche ils ont été éliminés ;
suivre :
suivre les événements du jeu, ces événements sont affichés, au fur et à mesure, sur le terminal de l'utilisateur, parmis les événements on trouve le début d'une partie (comprenant l'identifiant de l'animateur), la fin d'une partie (comprenant l'identifiant de l'éventuel gagnant), le lancement d'une manche (comprenant son numéro), le geste effectué par l'animateur et enfin les gestes effectués par les joueurs ;
stopper :
arrêter le processus Unix.
Pour implanter la commande suivre, il est recommandé de définir, au niveau du processus, un tableau des clients TCP en attente d'événements. Ainsi à chaque nouveau événement à leur transmettre, il suffit de parcourir ce tableau et de les contacter sur leur connexion TCP.

2.4   Les accessoires

Chaque binôme reçoit deux accessoires vestimentaires, une ceinture et un bracelet en tissu, qui serviront de support aux composants. Ces composants sont 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 interrupteur, un bouton, un accéléromètre, une led RVB, un vibreur et un buzzer. L'ensemble des composants sont fixés sur la ceinture mis à part l'accéléromètre qui se trouve sur le bracelet. La fixation des composants sur le tissu se fait à l'aide de fermoirs à pin's. Les connexions entre les composants se font par des pinces crocodiles ou des fils enroulés.

La programmation du micro-contrôleur se fait en utilisant le compilateur avr-gcc. L'algorithme à implanter sur le 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.

Les actions devant être réalisées par les accessoires sont décrit dans le tableau ci-dessous.

Evénement Actions
Test de présence du contrôleur retour de l'état de l'interrupteur, LED bleue
Indication de présence de plusieurs animateurs LED clignote rouge et mélodie à deux tons
Indication d'unicité de l'animateur LED clignote vert
Indication de signalisation de présence Bip sonore
Attente de lancement de partie Longue vibration répétée jusqu'à pression sur le bouton
Attente de lancement de manche Attente de 5 secondes, courte vibration répétée jusqu'à pression sur le bouton
Partie demarrée LED verte
Attente de geste LED verte à intensité variable, scrutation de l'accéléromètre limité à 15 secondes, retour du type de geste
Joueur éliminé LED rouge et mélodie "game over" de mario
Joueur gagnant Mélodie joyeuse, LED clignotante alternativement verte et bleu


Previous Contents Next