Available nodes

 Carcassonne

Le jeu Carcassonne est un jeu de société dans lequel les joueurs marquent des points en construisant des édifices (routes, châteaux, monastères ...), l'objectf étant d'optimiser ses possibilités en fonction des cartes que l'on reçoit, de terminer ses propres constructions voire même de chiper celles de ses voisins. Ce projet propose de modéliser les règles du jeu Carcassonne et de mettre en place l'architecture nécessaire pour visualiser le plateau de jeu, analyser les coups possibles, évaluer les scores et à terme jouer contre un adversaire humain ou possiblement informatique.

(image tirée du site www.theboardgamefamily.com)

Les règles du jeu sont disponibles en anglais et en français. Il existe un document qui détaille toutes les règles du jeu, et contient la liste des cartes du jeu de base.

Les règles du jeu sont déterministes. Elles définissent l'ensemble des coups valides jouables par un client, et elles assurent que le client a toujours au moins un coup valide à jouer. Quand le serveur fournit une carte à jouer à un client, ledit serveur doit s'assurer que cette carte est jouable.

 Description 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 Carcassonne. Le code sera décomposé en deux parties distinctes :
  • un ensemble de clients implémentant tous une interface commune, gérant leur propre plateau de jeu 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. La boucle de jeu devra suivre le pseudo-algorithme suivant :
moves = empty_list()    
For each player p 
   p->initialize(p_id, num_players)
While (the drawing pile is not empty)
   c = draw_card()
   p = compute_next_player()
   m = p->play(c, last_n(moves))
   enqueue(m, moves)
For each player p 
   p->finalize()

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.
  • 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.
Pour les besoins du projet, les fichiers devront être organisés de la manière suivante dans le dépôt :
    /               -- Base directory 
     Makefile       -- Global Makefile
    /src            -- Source files
    /install        -- Install directory (should be empty on the repository)
Le fichier Makefile devra fournir :
  • une règle build qui compilera l'ensemble du code,
  • une règle test qui exécutera les tests,
  • une règle install qui copiera les exécutables à l'intérieur du répertoire désigné, et
  • une règle clean qui supprimera les fichiers compilés et installés.
Le serveur devra charger l'ensemble de ses clients de manière dynamique en utilisant la syntaxe suivante :
./install/server [-g] ./install/*.so
Par défaut, l'exécutable doit afficher uniquement du texte sur la sortie standard. L'option -g peut être utilisée pour un affichage graphique (cf. partie "Remarques").
Tout exécutable ou autre fichier non indispensable à la compilation stocké à l'intérieur du dépôt SVN verra la personne ayant initié le premier commit se voir infliger un blâme. De la même manière, après avoir exécuté la règle make install, le répertoire install doit contenir exactement un exécutable nommé server, et des clients sous la forme de bibliothèques partagées (fichiers .so).

 Déroulement du projet

Le projet se déroulant sur 6 à 8 semaines va se décomposer en un ensemble de jalons à réaliser. Ces jalons sont fixés à des dates précises, et représentent des objectifs minimaux à atteindre.
  1. 1er jalon (vendredi 30/03 à minuit) :
    • Écriture d'un serveur minimal chargeant un ensemble de clients, et appelant successivement une seule et unique fois chaque fonction de l'interface pour chaque client.
    • Écriture d'un client minimal renvoyant des valeurs constantes pour chacune des fonctions de l'interface.
  2. 2nd jalon (vendredi 13/04 à minuit) :
    • Écriture d'un ensemble de structures de données et d'algorithmes permettant de représenter les cartes en jeu, et de calculer les points lors du comptage final. Le rendu de ce jalon sera fait sous forme de document PDF, les structures de données et interfaces doivent être des fichiers C valides (inclus dans le PDF et versés dans le dépôt), le code des algorithmes peut rester du pseudo-code.
  3. 3ème jalon (vendredi 04/05 à minuit) :
    • Écriture d'un serveur vérifiant la validité des coups du client.
    • Écriture d'un client renvoyant des coups valides pour le serveur, sans nécessairement poser de meeples.
La validation ou non de chacun des jalons fera partie des éléments permettant de construire la note finale.

 Remarques

Il n'est pas demandé de faire un affichage particulier du jeu pour le serveur. Aucune bibliothèque externe n'est autorisée pour l'affichage en mode texte. De manière totalement optionnelle, il est envisageable de réaliser une version graphique de l'application, et dans ce cas, seule la bibliothèque SDL-2.0 est autorisée (et cela sans aucune extension extravagante).