IA Garantie

Implemented

Guaranteed AI

• If player gets 1 specific science point: whenever he again has the choice between science points, he should go for the same science point as before .
• If a player has the chance to build marketplace card he should do it .
• The player builds military cards if he has less military points than his neighbors and of course if he can afford them .
• Analyze neighbor's strategies & try to block them:
  • Build cards that would give them a disadvantage or dump it in order to get coins .
  • Focus on same colored cards
• Prioritize color of cards: depending on age
  • Age 1: green -> grey -> blue
  • Age 2: green -> brown -> grey -> blue
  • Age 3: green -> blue

LIVRAISON FINALE

Bilan Livraison 7 :

• Nettoyage du code (refactoring , code smells ...)
• Résolution de quelques bugs
• Ajout de quelques tests
• Le serveur reçoit les stats , les traite et les sauvegarde dans un fichier
  pour qu'elles soient exploitables par la suite

---

LIVRAISON 6

Bilan Livraison 6 :

• Migration du traitement des statistiques vers le serveur
• Ajout et amélioration de quelques tests avec l'utilisation de Mock
• Résolution de quelques bug et code smell à l'aide de SonarQube

---

À améliorer pour la dernière livraison :

• finaliser les tests existants et faire les tests non fait pour avoir plus de coverage sur SonarQube
• javadoc , nettoyage du code , code smell etc
• faire marcher le test cucumber executeAction qui ne marche pas pour le moment

Livraison 5

Bilan Livraison 5 :

• Implementation du Design Pattern Strategy :
  La structure du jeu nous laisse pressentir la création d'une classe Joueur, représentant un individu acteur de la partie, affrontant d'autres joueurs.
  Dans le cadre du sujet, il nous est demandé d'implémenter des "Bots", c'est à dire des joueurs ayant une sorte d'Intelligence Artificielle très basique.
  Comment ces Bots sont censés jouer au jeu ? On peut par exemple penser à un joueur jouant des coups de manière aléatoire, ou bien un joueur priorisant les cartes militaires ou scientifiques par exemple.
  L'implémentation du Joueur, et de ces multiples façons de jouer, pose un problème de conception. Plusieurs Design Patterns s'offrent à nous pour résoudre ce problème :
• Le Design Pattern Template, implémenté par une classe abstraite Player n'ayant que les méthodes permettant de décider du coup à jouer qui seraient abstraites, dont hériteraient par exemple DumbPlayer, MilitaryPlayer, ou bien encore SciencePlayer.
• Le Design Pattern Strategy, implémenté par un attribut de type Strategy, classe abstraite définissant le coup à jouer en fonction des informations que possède le joueur, dont hériteraient alors DumbStrategy, MilitaryStrategy, ou ScienceStrategy.
  Strategy nous propose plusieurs avantages par rapport à Template : Il serait possible de changer de stratégie en cours de jeu, le code serait plus simple à lire (et donc mieux maintenable), et l'instanciation d'un joueur ne diffèrerait pas en fonction de la stratégie qu'il devrait appliquer.
  Ainsi, nous choisissons d'utiliser le Design Pattern Strategy pour implémenter l'IA primitive de nos joueurs dans notre soumission du projet, dans le package player.
• Le client se connecte au serveur et lui envoi les statistiques .
• Création de plusieurs modules
• Configuration SonarQube pour un projet multi-modules
• Ajout de tout les merveilles
• Ajout de quelques effets des étapes de merveilles

---

Quelques tests ont éte fait/corriger

---

À améliorer :

• le client va envoyer au serveur les données brut et c'est le serveur qui traitera ces données
• faire plus de tests

---

LIVRAISON 4

Bilan Livraison 4 :

• Première implémentation des inteligences artificielles
• Configuration du Sonar
• Mode statistique
• Serveur fonctionnel
• Ajout des derniers effets de carte

---

• Test des intelligences artificielles
• Test des classes d'effets de carte

---

LIVRAISON 4

Bilan Livraison 4 :

• Ajout de nouvelles cartes(jaune et violet)
• Ajout des effets spéciaux de certaines cartes jaune et violet
• Une merveille au hasard est attribuée à chaque joueur
• Un joueur peut acheter des resources à ses voisins
• Debugage de la méthode d'échange de cartes entre les joueurs (swapHands() )

---

• Niveau tests, certaines fonctionnalités et classes ont été testées.
• Cucumber test
  Il reste des tests à faire/finir

---

LIVRAISON 2

Bilan Livraison 2 :

• Amélioration de l'output
• Ajout de nouvelles cartes
• Guerre entre les joueurs voisins à la fin de chaque tour
• Récuperer les ressources donner par une carte(et éventuellement acheter une carte avec les ressources si le joueur en a assez)
• Points de victoire
• Organisation du code en plusieurs package

---

• Niveau tests, certaines fonctionnalités et classes ont été testées.
  Il reste des tests à faire/finir

---

LIVRAISON 2

Bilan Livraison 2 :

• Amélioration de l'output
• Ajout de nouvelles cartes
• Guerre entre les joueurs voisins à la fin de chaque tour
• Récuperer les ressources donner par une carte(et éventuellement acheter une carte avec les ressources si le joueur en a assez)
• Points de victoire
• Organisation du code en plusieurs package

---

• Niveau tests, certaines fonctionnalités et classes ont été testées.
  Il reste des tests à faire/finir

---

LIVRAISON 1

Bilan Livraison 1 :

• Le jeu est actuellement dans une version rudimentaire simple. Il peut se jouer à deux joueurs qui sont des IA "idiotes" qui font des coups aléatoires. Des cartes sont distribuées aux IA à chaque changement d'Age (quand il reste que deux cartes dans la main). A chaque tour les IA s'échangent leur main et font donc une action aléatoire. Quand le jeu se termine, un vainqueur est décidé en fonction du nombre de points de chaque joueur.

---

• Certaines fonctionnalités et classes ont été testées. Il reste des tests à compléter, notamment sur la classe Game.

---

LIVRAISON 0

Bilan Livraison 0 :

• Milestones

---

• commit initial avec pom / un helloword et test unitaire trivial

---

• sprint 1 en user stories