Projet

Compte GitLab

Le projet se déroulera sur GitLab, vous aurez donc besoin de créer un compte dessus.

Binômes

Ce projet est à faire par binôme. Une fois que vous avez choisi votre binôme, renseignez le sur le document Excel présent dans l'équipe Teams, pour me communiquer votre binôme, votre nom d'utilisateur GitLab ainsi que celui de votre binôme.

Forker le projet

Le projet est fourni sous forme de template dans ce dépôt GitLab, vous devez forker ce projet pour créer votre propre dépôt sur lequel vous allez travailler.

N'oubliez pas de créer votre projet en privé !

Ajouter le prof & votre binôme

Ajoutez-moi ensuite sur votre projet (mon nom d'utilisateur est Ombrelin) avec le rôle "Maintainer".

Cloner le projet

Avec de cloner (avec la commande git clone) le projet n'oubliez pas de configurer votre compte git en local, en utilisant comme username votre username Gitlab, comme décrit la section du cours à ce sujet, via la command git config.

Vous pouvez ensuite ouvrir le dossier du dépôt que vous venez de clôner avec IntelliJ.

Description du dossier du projet

Le projet est un projet Gradle voir la section du cours à ce sujet. Il contient un module appelé core qui va contenir du code que je fournis :

1. Des tests d'intégration, qui vérifient de façon automatique que votre code implémente bien les spécifications requises.

2. Des abstractions (interfaces) qui permettent à mes tests de s'intégrer avec votre code

Créer votre module

Avant de commencer, créer et positionnez vous sur une nouvelle branche.

Pour commencer à travailler sur le projet il vous faut créer votre module, qui contiendra votre code de simulation :

1. Créer un nouveau module Gradle nommé simulation avec l'aide d'IntelliJ. En tant que "GroupId", saisissez fr.<votre nom><nom binome>.efrei.monopoly:

2. Mettre à jour la configuration Gradle de votre module (le module simulation, vous ne devez jamais modifier le module core par vous même) :

3. Créer votre paquet racine dans votre projet. Suggestion de nommage (dans main/java et test/java) : fr.<votre nom><nom binome>.efrei.monopoly.simulation.

4. Créer un paquet fr.<votre nom><nom binome>.efrei.monopoly.simulation.integration dans votre dossier de test (simulation/src/test/java), et créer une classe MonopolyTests qui étend ma classe de test BaseMonopolyTests. Ainsi, vous pourrez pour le 1er livrable implémenter la méthode createMonopoly pour fournir votre propre implémentation de Monopoly afin de pouvoir exécuter mes tests avec.

5. Vous avez terminé le setup pour le projet. Vous pouvez pousser votre branche pour que votre binôme puisse la récupérer de son côté.

Note sur l'exécution des tests d'intégration fournis dans le projet

La technique utilisée pour permettre de vous fournir des tests que vous pourrez plugger directement à votre code cause un petit souci avec le système d'intégration des tests Gradle d'IntelliJ. Heureusement, il y a une solution de contournement simple.

Le problème est le suivant : si vous exécutez vos tests d'intégration en passant par l'icône dans la marge de la classe et que vous exécutez tous les tests, ou bien que vous exécutez la commande gradle test tout va bien, les tests s'exécutent :

Cependant, si vous exécutez un test individuellement via la vue de test (par exemple parce que vous voulez débugger un test spécifique), une erreur apparait :

C'est parce que le système utilise le mauvais nom de classe et de module pour exécuter le test, il les prend de la classe de tests abstraite. Pour résoudre le problème :

1. Ouvrez la configuration d'exécution qui a été créée par l'essai que vous venez de faire :

2. Remplacez dans la commande du test :

   • Le nom du module (core par simulation)

   • Le nom (complet) de la classe fr.arsenelapostolet.efrei.monopoly.BaseMonopolyTests par le nom (complet) de votre classe : fr.<votre nom><nom binome>.efrei.monopoly.simulation.integration.MonopolyTest. Pour être sûr d'avoir le bon, vous pouvez le copier-coller de la commande de la config de la classe entière. Faîtes bien attention à laisser le nom de la méthode de test à la fin de la commande.

3. Le test devrait d'exécuter sans problème avec cette configuration, vous pouvez même la lancer en mode debug pour faire du pas à pas.

Livrable 1 : Jets de dés, plateau, déplacement

Les joueurs peuvent se déplacer sur le plateau. Pour l'instant les joueurs ne peuvent rien faire, le jeu progresse quand ils donnent l'ordre IDLE (ne rien faire), ce qui passe le tour, et déclenche le jeté les dés et le déplacement pour le joueur suivant. Les ordres incohérents avec la situation courante du jeu sont ignorés. Un ordre invalide peut être un ordre d'un joueur pour qui ce n'est pas le tour de jouer, ou alors un ordre qui n'est pas cohérent avec la situation courante du tour.

La composition du plateau est la suivante, elle est décrite dans le fichier de ressources monopoly.csv (sous core/main/resources dans le projet). Ce fichier est à parser pour créer une représentation en mémoire du plateau.

Voici les règles concernant les dés : on simule le jet de deux dés à six face, le score de déplacement est la somme des deux dés ; il faut donc faire deux générations aléatoires pour un lancer de dés. Les dés ne sont pas testés par mes tests, ils sont remplacés par une pseudo entité, mais je corrigerai la validité de votre implémentation ainsi que comment vous l'avez testée.

En résumé, 3 tâches à faire pour ce livrable :

1. Parser le plateau depuis le fichier CSV et en faire une modélisation

2. Implémenter les dés

3. Combiner la modélisation du plateau dans votre simulation de Monopoly afin d'avoir la fonctionnalité de déplacement spécifiée par les tests fournis.

Livrable 2 : Argent, Achat, Loyers terrain nu

Dans ce livrable, on va implémenter :

• Un système de gestion de l'argent des joueurs, et des transactions. Chaque joueur commence avec une somme de départ de 1500€.

• Possibilité pour les joueurs d'acheter des propriétés, gares et companies, en donnant un ordre de type BUY à son tour lorsqu'on est sur une localisation de ce type

• Les joueurs doivent régler un loyer lorsqu'ils arrivent sur une propriété, gare ou compagnie, déjà possédée par un autre joueur

• Les joueurs ne peuvent pas acheter une propriété, gare ou compagnie qui appartient déjà à quelqu'un d'autre

Les loyers terrain nu sont les suivants :

• Pour l'instant le loyer des gares est un prix fixe de 25.

• Le loyer des compagnies se calcule selon la logique suivante :

  • Si le propriétaire de la compagnie possède une seule des deux compagnies, alors le prix est le score du joueur locataire multiplié par quatre

  • Si le propriétaire de la compagnie possède les deux compagnies, alors le prix est le score du joueur locataire multiplié par dix

Si un joueur est confronté à un loyer qu'il ne peut pas payer, il est déclaré en banqueroute, il perd, et est supprimé des joueurs de la partie. Le joueur propriétaire percevant le loyer qui déclenche la banqueroute perçoit l'argent du joueur en banqueroute comme loyer, pas plus. Si la partie contient moins de 2 joueurs, elle s'arrête, c'est-à-dire que tout appel ultérieur à submitOrder jette une exception de type GameFinishedException.

Livrable 3 : Prison, case départ, gares

Livrable 4 : Construction, loyers adéquats et taxes

Les joueurs peuvent construire des maisons pour leurs propriétés en émettant un ordre BUILD à leur tour. Cet ordre a un paramètre propertyName: le nom de la propriété sur laquelle construire.

Pour construire, un joueur de posséder toutes les propriétés d'un groupe de couleur.

Une propriété a cinq niveaux de construction. Voici la spécification des loyer et prix de construction en fonction des propriétés :

Les classes de taxes doivent débiter les joueurs qui tombent dessus du montant correspondant, qui peut être retrouvé dans la colonne price pour les location de type tax dans monopoly.csv.

Livrable 5 : Jeu en réseau en mode client-serveur

Nous voulons maintenant utiliser notre simulation de Monopoly afin de jouer en réseau. Nous allons donc devoir créer deux nouveaux modules dans l'application, selon le modèle client-serveur :

• client: application en ligne de commande permettant aux joueurs de jouer au jeu en leur permettant d'envoyer leurs ordres à la simulation, mais aussi de lire des informations sur la situation courante du jeu.

• server: application qui fait tourner la simulation en mémoire, et intéragit via le réseau avec les clients pour le permettre de jouer ensemble.

Le client et le serveur devront implémenter un main qui permettra de jouer en condition réelles, via une interface en ligne de commandes.

Livrable 6 (Bonus) : Interface graphique pour le client

Ce livrable est beaucoup plus libre, l'idée est que le client offre une interface graphique qui montre :

• L'état de la partie en temps réel

• Des boutons permettant au joueur d'envoyer ses ordres

Je testerai manuellement cette interface graphique et validerai ou non le bonus en fonction de l'aboutissement du livrable.

Livrable 6-bis (Bonus) : Créer son propre conteneur d'injection de dépendance

Ce livrable est beaucoup plus libre, l'idée est de développer un conteneur d'injection de dépendances et de l'utiliser dans les applications du livrable 5.

Créer un nouveau module Gradle de type "library" dans le projet qui implémente ce conteneur d'injection de dépendances.

L'interface du conteneur sera la suivante :