1. AC11.01 | Implémenter des conceptions simples 2. AC11.02 | Élaborer des conceptions simples **** 3. AC11.03 | Faire des essais et évaluer leurs résultats en regard des spécifications
<aside> 💡 Quelles ont été vos démarches, prises de décisions, degré d'implication et d'autonomie ?
</aside>
Pour cette SAE, on devait développer en binôme un jeu de Reversi (Othello) en Java. Le programme devait permettre de jouer sur un plateau de taille variable (de 4x4 à 16x16, toujours pair), avec un mode solo contre un bot et un mode duo entre deux joueurs humains. On a commencé par bien relire le sujet et les règles du Reversi pour être sûrs de comprendre la mécanique de capture (les alignements dans les 8 directions, le retournement des pions). Ensuite on s'est réparti le travail : l'un s'occupait plutôt de la logique de jeu (calcul des coups valides, retournement des pions) et l'autre de la partie affichage et gestion des tours. Ma première vraie décision technique a été de représenter le plateau par un tableau 2D de char, avec 'o' pour les noirs, 'x' pour les blancs et ' ' pour les cases vides. Pour le calcul des positions valides, j'ai utilisé un tableau de directions (les 8 vecteurs de déplacement) qu'on parcourt depuis chaque pion du joueur courant pour chercher des alignements adverses suivis d'une case vide. C'était la partie la plus complexe du projet et j'ai dû m'y reprendre plusieurs fois avant que ça marche dans tous les cas. On a aussi décidé d'implémenter deux niveaux de bot : un bot aléatoire qui choisit un coup valide au hasard, et un bot "intelligent" qui choisit le coup retournant le plus de pions adverses. C'était pas demandé d'en faire deux mais on voulait aller plus loin. Quand on avait des bugs, on ajoutait des affichages temporaires pour comprendre ce qui se passait dans nos boucles. Par exemple pour la méthode validCases, j'affichais le contenu du tableau de coups possibles à chaque étape pour vérifier qu'on ne comptait pas deux fois la même position. On a travaillé régulièrement sur les créneaux en autonomie et on communiquait entre les séances pour avancer chacun de notre côté.
<aside> 💡 Quelles ressources avez vous choisies et combinées pour réaliser vos tâches et résoudre les problèmes rencontrés dans cette SAé ?
</aside>
La ressource principale qu'on a mobilisée est R1.01 (Initiation au développement). C'est grâce à elle qu'on a pu utiliser les structures de contrôle (boucles while et for, conditions if/else), manipuler des tableaux 2D de char et de int, et découper notre programme en méthodes. La notion de modularité vue en cours nous a poussés à séparer le code en fonctions bien distinctes : boardList pour initialiser le plateau, validCases pour calculer les coups possibles, applyMove pour appliquer un coup et retourner les pions, playerTurn et botTurn pour gérer les tours, etc. On a aussi appliqué les notions de qualité de code : nommage clair des variables et des méthodes, et écriture de Javadoc pour documenter chaque fonction.
La ressource R1.02 (Développement d'interfaces web) a été mobilisée indirectement. Même si notre jeu tourne en console, les réflexions sur l'ergonomie et le maquettage vues dans cette ressource nous ont aidés à penser l'affichage : on a fait en sorte que le plateau reste lisible même en 16x16 (alignement des colonnes à deux chiffres), et on affiche les positions jouables avec un point '.' pour que le joueur repère facilement où il peut jouer.
Pour R1.10 (Anglais), on a écrit toute notre Javadoc en anglais et nommé nos variables et méthodes en anglais (ennemy, validCases, applyMove, countFlips, isGameOver...). Quand on avait des erreurs de compilation ou de logique, on cherchait sur StackOverflow et la documentation Java qui sont en anglais, ce qui nous a obligés à comprendre des explications techniques dans cette langue.
<aside> 💡 En vous appuyant sur vos traces, justifiez la maitrise des apprentissages visés, ainsi que la prise en compte des composantes essentielles pour le développement de vos compétences.
</aside>
Pour AC11.01 (Implémenter des conceptions simples), notre code montre qu'on a su traduire les règles du Reversi en un programme Java fonctionnel. On a implémenté l'initialisation du plateau avec les 4 pions centraux (méthode boardList), le calcul des coups valides dans les 8 directions (validCases), le retournement des pions capturés (applyMove), la gestion des tours avec vérification des saisies invalides (playerTurn), deux niveaux de bot (botTurn et botTurnSmart), et la détection de fin de partie avec affichage du vainqueur (isGameOver, winner). Le programme compile et s'exécute correctement sur des plateaux de 4x4 jusqu'à 16x16.
Pour AC11.02 (Élaborer des conceptions simples), on a réfléchi à notre architecture avant de coder. On a choisi de représenter les directions par un tableau de vecteurs (le tableau move avec les 8 paires dx/dy), ce qui nous a permis de factoriser le parcours dans les 8 directions au lieu d'écrire 8 blocs de code séparés. On a aussi conçu la méthode validCases pour qu'elle retourne un tableau d'entiers avec les coordonnées des coups possibles, ce qui est réutilisé ensuite par playerTurn, botTurn et botTurnSmart. Cette conception modulaire nous a facilité le travail quand on a ajouté le bot intelligent.
Pour AC11.03 (Faire des essais et évaluer les résultats), on a écrit des méthodes de test automatisées pour la fonction boardList, comme demandé dans le cahier des charges. La méthode testBoardList lance plusieurs cas : des plateaux valides de taille 4, 6 et 8, et un plateau invalide où un pion central est mal placé. La méthode testCasBoardList vérifie automatiquement la taille du tableau, la bonne position des 4 pions centraux, et que toutes les autres cases sont vides. Les tests s'exécutent avant le lancement de la partie et affichent "OK" ou un message d'erreur détaillé. Au-delà des tests automatisés, on a aussi testé manuellement le jeu en jouant des parties complètes pour vérifier les cas limites : quand un joueur ne peut pas jouer, quand le plateau est plein, quand on entre une position invalide.
<aside> đź’ˇ
Quelles ressources vous manquent pour atteindre la compétence abordée par cette SAé ? Si c'était à refaire que changeriez-vous ?
</aside>
On a utilisé Git pour travailler en binôme, mais on a pas mal galéré avec au début. On avait du mal avec les conflits de merge quand on modifiait le même fichier en même temps, et on a perdu du temps à comprendre comment les résoudre. On faisait aussi des commits un peu en vrac sans messages clairs, du coup c'était compliqué de s'y retrouver dans l'historique. Si c'était à refaire, je prendrais le temps de mieux apprendre les bases de Git avant de commencer le projet, notamment la gestion des branches pour éviter de travailler directement sur le même fichier. On aurait aussi aimé écrire plus de tests automatisés. On a testé boardList comme demandé, mais on aurait pu tester validCases et applyMove de la même manière, avec des plateaux pré-remplis pour vérifier que les coups valides et les retournements sont bien calculés. Ça nous aurait fait gagner du temps de debug au lieu de tester à la main en jouant des parties entières. Enfin, notre bot "intelligent" reste assez basique : il choisit juste le coup qui retourne le plus de pions, sans réfléchir aux conséquences. Si c'était à refaire, j'aurais aimé implémenter une stratégie qui prend en compte les coins et les bords du plateau, qui sont des positions stratégiquement fortes au Reversi. Mais ça demandait des connaissances en algorithmique qu'on n'avait pas encore à ce stade.
Mes traces significatives associées à cette action en lien avec le niveau de développement d'une ou plusieurs compétences (fichiers, copies d'écran, document spécifique …)