Les tests ne sont pas forcément des tests unitaires rejouables mais il faut garder une trace.
Seconde chose à faire.
Une fonction qui joue le même rôle que la fonction du premier point ci-dessus mais qui met en oeuvre "la méthode du cahier", i.e. l'approche qui stocke les états en mettant à jour si ils sont gagnants ou perdants.
(temps estimé : 30 minutes à 120 minutes).
Troisième chose à faire.
* Reprendre le code pour le clarifier si nécessaire.
* Le documenter (javadoc si java).
* Ajout d'un readme expliquant le rôle de chaque fichier.
* idée 0 : dans la boucle dans exploremax, si je trouve un coup après lequel je gagne (exploremin m'indique que je gagne) alors ce n'est pas la peine de chercher un autre coup gagnant, je peux arrêter de chercher.
* idée 0bis : même chose pour une défaite dans exploremin.
Indication. changez votre code pour fabriquer une version optimisée tenant compte de cette idée.
Comparaison avec la version précédente. changez votre code pour compter le nombre d'état du jeu visité (il faut un compteur qui s'incrémente de 1 à chaque appel de exploremax ou exploremin).
* idée 1 : il peut arriver qu'on descende récursivement dans l'arbre de jeu, alors que au coup suivant je peux gagner.
Indication. changez votre code pour fabriquer une version optimisée qui commence par tester si je peux gagner tout de suite au prochain coup.
Si je peux, ceci évite de descendre dans l'arbre.
Si je ne peux pas, je descends dans l'arbre.
* idée 2 : on se rend compte que l'ordre des coups à une influence importante.
On pourrait énumérer les coups dans un ordre différent (par exemple au hasard) et étudier si ceci peut avoir un impact.
Indication. changez votre code pour permettre que la boucle qui teste les coups le fasse dans un ordre aléatoire. Testez si ceci améliore l'efficacité du code.
Il faut grosso modo incrémenter ce compteur quand vous faites un appel de exploreMax (de même pour exploreMin).
### affichage pour Minimax
Vous êtes nombreux à avoir du mal à réconcilier le résultat de votre algorithme avec vos calculs éventuels sur papier.
Il est judicieux de se bricoler un petit affichage d'arbre de jeu pour débuger.
Indication.
* Passez en paramètre de exploreMax et exploreMin un entier profondeur (initialement 0).
* codez une méthode prettyPrint(int profondeur, int etat, int eval) qui va afficher profondeur espaces puis le nombre d'allumettes (état) puis l'évaluation (-1 ou +1).
* insérer l'appel prettyPrint juste avant de faire un return dans exploreMax ou exploreMin
### Améliorer MiniMax beaucoup
Nous avons entrevue l'idée de alpha beta (voir transparents cours an dernier).
On souhaite pouvoir faire évoluer ce code pour permettre d'en réutiliser un maximum pour d'autres jeux pas trop compliqués à coder (le but étant de travailler sur le bot plutôt que sur les règles du jeux).
Les autres jeux candidats.
* tic tac toe
* puissance 4
* morpion
Si vous avez des jeux dont les règles sont potentiellement simples à coder et qui sont comme ceux ci-dessus
(tour par tour, à 2 joueurs, déterministe et à information complète) alors n'hésitez pas.
### Diagramme de classe (45 minutes environ).
Proposez un diagramme de classe le plus abstrait possible pour permettre de coder n'importe quel jeu ci-dessus (on codera seulement Nim dans l'immédiat).
Proposez un squelette de code avec pour chaque méthode une documentation javadoc.
Pensez à faire plusieurs itération et à vérifier que votre code Minimax peut utiliser ces méthodes.
NB. staruml permet de générer du code à partir d'un diagramme de classe.
Indications. Pour ceux qui ont du mal à démarrer, il faut lire votre code de minimax pour le jeu de Nim, et réfléchir à des fonctionalités que vous souhaiter avoir de la paret du jeu. Par exemple, la partie est terminée, si c'est terminé, quel est le résultat de la partie etc. Commencez par lister ce qui va devenir une méthode en décrivant par une ligne en français chaque fonctionalité.
Ensuite réfléchissez à ce dont vous avez besoin comme données en entrée et en sortie. Finalement cherchez à organiser les entrées et sorties en ajoutant des types adaptés (des classes).
