nc0fr/conception-application

Projet de "Conception et Développement d’une Application SLA4IF03", UFR ST Orléans

conception-application's Issues

Implémenter la stratégie optimisée pour le Puissance 4

Voir le sujet dans //docs/sujets/iteration4.pdf.

Implémenter la stratégie "Stratégie aléatoire" pour le jeu de Nim

Voir le sujet dans //docs/sujets/iteration4.pdf.

Remplacer le choix des stratégie

Remplacer le choix des stratégies par ihm par un choix selon les conditions du jeu

Inverser le sens des rotations

Le sens de rotation attendue par la professeur est l'exact opposé de celui encodé dans le jeu (ils partent du haut de la grille). Il suffit alors de changer le mapping "gauche" -> Rotation.HORAIRE et "droite" -> Rotation.ANTI_HORAIRE en "gauche" -> Rotation.ANTI_HORAIRE et "droite" -> Rotation.HORAIRE dans la méthode demanderRotation() de ControleurPuissance4 !

Erreur parsing CI

          L'erreur provient de notre utilisation d'un Java moderne qui n'est pas supporté par le parser de `google-java-format`.

Originally posted by @nc0fr in #8 (comment)

normaliser les nom des strategie (ia nim)

Simplifier et unifier l'IHM

Simplifier la logique de l'IHM pour accepter des I/O communes entre les jeux et donc ne pas devoir les séparer.

Ajouter des états de parties plus précis pour Nim

En étant plus précis sur les états de parties de Nim, nous pourrions plus facilement déterminer le vainqueur et le perdant de la partie.

Ainsi les états pourraient être similaires à ceux du puissance 4 :

public enum EtatPartieNim {
    EN_COURS,
    VICTOIRE_JOUEUR_1,
    VICTOIRE_JOUEUR_2
}

En adoptant cette méthode, nous pourrions aussi très facilement partager ce bout de code avec le Puissance 4, et n'importe quel autre jeu à deux joueurs à ajouter (tel que demandé dans l'itération trois).

Reorganisation du jeu puissance 4

Erreur customisée pour les actions de Puissance4

Pour forcer le compilateur de la JVM de rapporter le manque d'erreur handling dans nos méthodes du modèle Puissance4, il serait préférable de modifier l'utilisation des erreurs IllegalArgumentException et IllegalStateException au profit d'erreurs uniques au système, comme PartieTermineeException.

Simplifier la logique du contrôleur de Nim

En simplifiant la logique du contrôleur de Nim, nous pourrons trouver des moyens de mettre en relation la classe ControleurJeuNim avec ControleurPuissance4, et donc espérer mettre en place une architecture des contrôleurs abstraites : Template method (en français, patron de méthode).

Rapport de développement Itération 3

• Design pattern Patron de méthode

• Fusion et unification

• Principe de responsabilité unique pour simplifier la fusion

• Usage de l'AI intégrée (Copilot, via OpenAI GPT 3.5) pour écrire de la documentation

• Erreurs customisées, comme fait remarqué par professeur Khalem

• Faire les diagrammes de modélisation, &c.

Gérer l'affichage des coups des ia

Changer l'affichages des coups pour le rendre plus acceptable quand une ia joue

Unifier les IHM

Avec la fusion des deux jeux en une seule codebase, il faudrait unifier les classes Ihm (respectivement IhmNim et IhmPuissance4) en une seule, puisqu'une bonne partie de la logique est similaire.

Implementer ia Bonus puissance 4

Reorganisation package jeu ? (à voir si on le fait)

Script pour créer lez rendu.zip

Faire un petit script Python qui va automatiquement prendre le code et nos documentations et créer le dossier .zip à rendre sur Célène lors des TPs.

Implémenter la première stratégie pour le Puissance 4

Voir le sujet dans //docs/sujets/iteration4.pdf.

On verra pour le "BONUS" plus tard.

Baisser le délais dans les sleep des print de l'IHM

Trop lent

Utiliser des caractères ASCII avec des couleurs ANSI dans l'affichage de Nim

Les codes couleurs ANSI avec des caractères ASCII sont plus sûrs à utiliser que des émojis dans l'affichage (en effet, les émojis ont une taille variable qui peut casser l'affichage). Cette technique fonctionne déjà dans le puissance 4, avec un rond ASCII.

Unifier plus les contrôleurs

Pour avoir un contrôleur bien plus unifié, nous pourrions mettre en commun plus de logique de code dans le ControleurTemplate.

Par exemple dans nos deux jouer(), nous avons la même logique pour la partie "Post-game" : déterminer le vainqueur à partir de EtatPartie, afficher le score, demander à rejouer, et afficher la fin de la partie si on ne rejoue pas.
Tout ce code en commun peut exister au sein d'une fonction postGame(joueur1, joueur2) du ControleurTemplate, et cette fonction peut être appelée dans nos jouer() respectif.

De même, la création et enregistrement des joueurs, qui se fait habituellement lors de la création des parties (dans les constructeurs de Nim et Puissance4), pourrait se faire plus tôt au sein d'une fonction enregistrerJoueurs() de ControleurTemplate.

Les rotations ne tiennent pas compte des éléments existants

Lorsqu'un joueur effectue une rotation, la grille ne tourne pas dans le bon sens, et la gravité réécrit les cases remplies, faisant disparaître des données.

Créer un Template Design Pattern pour les contrôleurs

https://refactoring.guru/design-patterns/template-method

Erreur customisée

Au lieu d'utiliser des erreurs comme IllegalArgumentException, il est préférable d'avoir des erreurs customisées (e.g. CoupInvalideException) pour qu'elles soient vues par le compilateur Java.

Match nul quand une rotation amène à deux victoires

Soit le plateau suivant :

⚪ ⚪ ⚪ ⚪ ⚪ ⚪ ⚪ 
⚪ ⚪ ⚪ ⚪ ⚪ ⚪ ⚪ 
⚪ ⚪ ⚪ ⚪ ⚪ ⚪ ⚪ 
⚪ ⚪ ⚪ ⚪ ⚪ ⚪ ⚪ 
⚪ ⚪ ⚪ ⚪ ⚪ ⚪ ⚪ 
🟡 ⚪ 🟡 ⚪ 🟡 🟡 ⚪ 
🔴 ⚪ 🔴 ⚪ 🔴 🔴 ⚪ 

En effectuant une rotation (peu importe le sens), nous obtenons une situation de double victoire :

(rotation à droite)

⚪ ⚪ ⚪ ⚪ ⚪ ⚪ ⚪ 
⚪ ⚪ ⚪ ⚪ ⚪ ⚪ ⚪ 
⚪ ⚪ ⚪ ⚪ ⚪ ⚪ ⚪ 
🔴 🟡 ⚪ ⚪ ⚪ ⚪ ⚪ 
🔴 🟡 ⚪ ⚪ ⚪ ⚪ ⚪ 
🔴 🟡 ⚪ ⚪ ⚪ ⚪ ⚪ 
🔴 🟡 ⚪ ⚪ ⚪ ⚪ ⚪ 

ou

(rotation à gauche)

⚪ ⚪ ⚪ ⚪ ⚪ ⚪ ⚪ 
⚪ ⚪ ⚪ ⚪ ⚪ ⚪ ⚪ 
⚪ ⚪ ⚪ ⚪ ⚪ ⚪ ⚪ 
⚪ ⚪ ⚪ ⚪ ⚪ 🟡 🔴
⚪ ⚪ ⚪ ⚪ ⚪ 🟡 🔴
⚪ ⚪ ⚪ ⚪ ⚪ 🟡 🔴 
⚪ ⚪ ⚪ ⚪ ⚪ 🟡 🔴  

Il nous faut donc décider d'un vainqueur.
Pour le moment, le vainqueur est celui ayant le paterne gagnant le plus à la gauche (puisque nous itérons de (0, 0) à (n, m).

Il serait plus juste ici de déclarer une égalité, pour rajouter un aspect stratégique au jeu.

Créer un unique Main

Maintenant que les deux jeux sont ensembles, nous devons programmer un seul point d'entré Main de l'application dans lequel les joueurs choisiront le jeu à jouer.

Faire des erreurs customisées

Utiliser des erreurs customisées dans nos modèles au lieu d'utiliser les runtimes Exceptions permet d'assurer que le compilateur Java détectera les problèmes d'error handling au compile time.

Il s'agit aussi d'une demande de professeur Khalem.

Créer un meilleur type pour le int[], choix du jeu Nim

Actuellement, le jeu de Nim prend pour choix un int[] formé de la façon suivante :

[tas, nombre]

avec tas étant le numéro du tas dans lequel choisir les allumettes, et nombre le nombre d'allumettes à retirer dans le tas fourni. Cependant, cela reste un type assez générique (une liste non fixée).

Ainsi je propose de créer un meilleur type pour cela, ce qui serait aussi pratique pour la définition des stratégies du jeu de Nim :

-public class StrategieConcrete implements Strategic<ListeTas, int[]> {
+public class StrategieConcrete implements Strategic<ListeTas, ChoixNim> {

Faire une structure spécifique pour les tas de Nim

En faisant une structure de donnée spécifique pour les tas dans le jeu de Nim, nous pouvons contrôler leur comportement, et notamment ajouter une méthode toString() qui s'occupera d'afficher le tas sous la forme d'un string joli pour l'affichage dans l'IHM.

Créer le corps du paterne de stratégie pour les joueurs

Il faut créer l'interface requise et le corps du paterne stratégie sur Joueur et Strategie (des classes du package fr.nc0.cda.modele.joueur). Cela permettra de développer les algorithmes demandés et de pouvoir les tester directement.

Implémenter la stratégie "Stratégie gagnante" pour le jeu de Nim

Voir le sujet dans //docs/sujets/iteration4.pdf.

Ré-organiser les documentations à rendre

Les fichiers à rendre (rapports, compte-rendus, &c.) sont mal triés. Je dois m'occuper de les ranger proprement pour simplifier la navigation dans le codebase.

Fix la problème de rotation gauche

Ça vient de la formule dans la rotation Rotation.ANTI_HORAIRE, j'étudierais demain.
Ce bug est critique car il s'agit d'une régression par rapport au code précédent, mais ce comportement est logique puisqu'il intervient sur le fix du système de rotation et simplification de l'algorithme, faisant passer la logique du Puissance4 de 400LOC à 160LOC

Déplacer la modification d'état de la partie de Nim dans le modèle

La vérification du plateau de Nim et de l'état de la partie est de la responsabilité de Nim. De ce fait, la fonction Nim.checkEtatPartie() doit rester private et se faire appeler automatiquement dans Nim lui-même.

Organiser les modèles de jeu dans des subpackages

Pour le moment, l'ensemble des modèles de l'application des deux jeux existent dans un même package fr.nc0.cda.modele. Cependant, il serait préférable de réorganiser certains modèles dans des subpackages afin de simplifier la maintenance de l'application.

Ainsi, je propose la création des packages fr.nc0.cda.modele.nim et fr.nc0.cda.modele.puissance4 afin de ranger à l'intérieur les modèles respectifs à ces jeux.

Faire une structure spécifique pour la grille du puissance 4

Similaire à #19 mais pour la grille du Puissance 4