Available nodes

 Principe du jeu

Un groupe de mineurs à l'accent fortement prononcé se fixe comme objectif de percer des galeries à partir de l'entrée de leur mine. Munis de leurs systèmes de navigations perfectionnés, ils connaissent parfaitement leur propre position, et savent exactement à quels endroits ils doivent creuser pour trouver les "pépètes" (leur malheureux problème d'accent les empêche de parler de pépites).

Malheureusement pour eux, ces mineurs ne souffrent pas seulement de problèmes d'élocution, mais aussi d'un syndrôme psychologique les empêchant de créer des galeries systématiquement toutes droites (les plus anciens d'entre eux affirment que c'est la pierre elle-même qui impose sa forme à la galerie, ce qu'aucune analyse géologique n'a jamais réussi à démontrer contrairement à ce que l'on a pu établir avec des tests de dépistages aux drogues connues). Résultat, leurs galeries sont labyrinthesques et pleines de circonvolutions, chaque embranchement étant le résultat d'une prise de décision obscure.

Pire, la découverte de chacune de ces pépètes induit des tracasseries et discussions sans fin pour décider comment répartir correctement les gains des journées de labeur. Cela mène certains groupes de mineurs à faire de l'obstruction en fin de journée, et donc à jouer la montre pour empêcher de trouver les pépètes, et rentrer plus tôt à la maison pour manger leur sacro-saint potage (reconnaissable au cri de joie qu'ils poussent dans leur langue si colorée). De tels énergumènes sont alors traités de sapoteurs.


Le but de ce projet consiste à implémenter ce jeu de société, dont les règles1 complètes sont disponibles à ici. Il est aussi possible d'avoir accès à la liste des cartes dans le jeu.

 Fichier de configuration

Le fichier suivant décrit le forme du fichier de configuration utilisé pour définir le plateau de jeu et les cartes utilisées pendant une partie.
Pour la première séance de projet (semaine 10, mardi ou vendredi selon l'encadrant), il est demandé de :
  • pouvoir analyser ce type de fichier à l'aide d'un programme écrit en C, de pouvoir extraire les informations qu'il contient et de les retranscrire sous la forme suivante :
    Configuration : 5x9
    Card types    : 16
    Nb of cards   : 61
    Objectives    : 2 (4,4) (6,2) 
    Holes         : 2 (5,3) (2,1) 
    Allow boulder : yes
    Allow breaks  : yes
    Repair=Break  : yes
    
    Les positions des objectifs et des trous sont donnés dans le système de coordonnées du jeu. Les lignes "Allow boulder" (resp. "Allow breaks") devront répondre "yes" ou "no" selon que la carte BOULDER (resp. l'une des cartes B_* ou R_*) est autorisée dans la partie. La ligne "Repair=Break" devra répondre "yes" ou "no" selon qu'il y ait autant de cartes de réparation que de casse.
  • produire un exemple de configuration différent de celui proposé dans le sujet, à des fins de tests.
Le parseur en question, ainsi que les fichiers d'exemple feront partie de l'évaluation finale du projet.
L'écriture de ce parseur peut être simplifiée en adoptant une démarche en une définition plus deux étapes :
  1. une décomposition du fichier en éléments appelés tokens, correspondant à des unités d'information contenues dans le fichier (nombre, caractère "$", nom d'une carte, espaces ...);
  2. une fonction qui, à partir d'un point dans le fichier, lit et renvoie le prochain token;
  3. une fonction qui récupère les tokens et les traduit en données du programme.
Une telle démarche est décrite dans le chapitre 7 du cours d'Automates de Mr Herbreteau, chapitre qui n'a pas d'autres prérequis que le chapitre 1. Elle est intéressante dans la mesure où les deux fonctions évoquées peuvent être écrites indépendamment l'une de l'autre.
L'archive suivante contient un ensemble de fichiers de test, ainsi qu'un Makefile à partir desquels les parseurs seront évalués. Elle contient aussi un fichier de départ pour écrire le parseur, fichier dont la structure peut être modifiée 2.

 Objectifs du projet

L'objectif du projet consiste à implémenter un ensemble de fonctions permettant de faire jouer un nombre quelconque de joueurs à une partie de Sapotache !. Le code sera décomposé en deux parties distinctes :
  • un ensemble de clients implémentant tous une interface commune, gérant leur propre ensemble de cartes et jouant chacun selon leur objectif propre;
  • et un serveur de jeu organisant une partie, faisant jouer chaque client à son tour en lui envoyant la liste des coups joués précédemment, enregistrant le coup du client à son tour et notifiant les clients de la fin de la partie.
Pour les besoins du jeu, le fichier suivant décrit l'interface à utiliser pour communiquer entre client et serveur.
Il est demandé de respecter les principes suivants :
  • Les différents clients doivent être interopérables entre équipes de projets. A cet effet, il est demandé que chaque client soit compilé sous la forme d'une bibliothèque partagée (option -shared de gcc) et chargeable de manière dynamique, en utilisant les fonctions de la famille dlopen, définies dans dlfcn.h. Il sera possible de s'inspirer des instructions données ici.
  • Il est demandé d'implémenter au moins deux clients différents en terme de stratégie utilisée (et ce sans tenir compte de la différence sapoteur / normal, jouer uniquement DISCARD ne constitue pas une stratégie).
  • Il est demandé de faire attention à éviter la duplication du code (en particulier pour les données du plateau de jeu). Remarquer que l'interface interdit toute communication dudit plateau entre client et serveur.

 Recommandations


1. Potaches, s'il était nécessaire de le rappeler.
2. L'utilisation de bibliothèques autres que la libc est bien entendue proscrite, sauf si le résultat d'une discussion argumentée avec l'auteur du sujet, et bien sûr agrémentée d'une offrande suffisante de pépètes.