Le sujet est disponible ici.
Nous n'avons pas réellement eu de problème pour cette partie là du projet. Nous avons juste eu à séparer en plusieurs packages/classes ce fichier de Monsieur Balabonski.
Les problèmes de développement venaient principalement de l'interface graphique, de son utilisation etc. car c'est quelque chose de nouveau pour nous. Nous allons détailler ici plusieurs problèmes rencontrés lors du développement.
Nous avons pensé à 2 moyens pour déplacer un joueur:
- Via des boutons
- Via la souris en cliquant sur la grille
Nous avons choisi la deuxième méthode et avons alors été confronté à ce problème: Comment enlever la possibilité de se déplacer une fois qu'un joueur ait fait 3 actions?
Le but est alors de vérifier autant de fois que c'est possible si la limite d'action a été atteinte dans la grille et lorsque c'est le cas d'enlever dans la grille les MouseListener.
Au final, notre solution a été de faire les vérifications et éventuels suppressions dans la méthode paint de Grille qui est énormément appelé dans le programme.
Une autre solution serait peut-être d'utiliser EventQueue mais n'ayant ni la maîtrise ni la certitude que cela pouvait être une solution, nous ne sommes pas penché dessus.
Nous avons eu ici un problème qui était le suivant: Lorsqu'on voulait déplacer un personnage, on déplaçait tout les personnages qui pouvaient se déplacer vers la zone sélectionnée en accord avec les règles de déplacement. Ceci était dû au fait que pour un tour, nous faisons une boucle sur les Joueurs (voir ici - classe DéplacementJoueur) alors que ce que l'on veut c'est un tour = un joueur.
On avait détecté ce problème assez tôt du fait qu'on avait à ce stade, initialisé les joueurs près les uns des autres, il aurait été plus difficile de trouver ce bug et de le résoudre si on avait directement initialisé la position des joueurs de manière aléatoire.
Avec un peu de remaniement, nous avons pu résoudre ce problème.
- Nous avons déjà créer une classe abstraite ActionJoueur qui est implémentée par toutes les actions que nous allons implémenter. Par ailleurs, cette classe prend un Joueur en constructeur et pas une île comme précédement.
- Ensuite, nous avons créer une classe ActionsJoueurs (notons le s en plus) qui a en attribut toutes les actions pour un Joueur, cela permet de vérifier plus facilement si le quota d'action est atteint.
- Enfin, nous avons créer une classe DéroulementPartie qui gère la partie, le joueur actuel et ses actions. Cette classe est d'ailleurs énormément liée aux différentes vues.