TD07 : Extension du Jeu (V2)

De nouvelles règles

Nous allons maintenant considérer une nouvelle version du jeu (version 2), qui est caractérisée par les changements suivants :

  • La grille peut maintenant être rectangulaire et avoir un nombre de lignes et de colonnes arbitraires. On se limitera pour game_text à 10 lignes max et 10 colonnes max pour simplifier l'affichage.
  • La grille du jeu a la possibilité d'avoir une topologie "torique" (option wrapping) : la colonne la plus à droite est adjacente à la colonne plus à gauche et la ligne la plus haute est adjacente à la ligne la plus basse. Afin de bien prendre en compte cette option, il convient d'adapter le code de la fonction game_get_next_square() et de s'appuyer dessus pour implémenter les autres fonctions... Si vous comprenez cela, tout devient facile !
  • Par ailleurs, nous ajoutons l'option neighborhood, qui modifie la taille du voisinage à considérer autour d'une case pour satisfaire la constraint, selon les schémas suivants (a) FULL, (b) ORTHO, (c) FULL_EXCLUDE, (d) ORTHO_EXCLUDE.
   XXX      OXO      XXX      OXO
   XXX      XXX      XOX      XOX
   XXX      OXO      XXX      OXO

   (a)      (b)      (c)      (d)
  • De plus, nous mettons en place la gestion d'un historique des coups joués avec game_play_move(), afin de pouvoir annuler les derniers coups joués (fonction game_undo()), et de possiblement rejouer les derniers coups annulés (fonction game_redo()). Notons qu'il est possible de rejouer autant de coups que l'on a annulé successivement. En revanche, il n'est plus possible de rejouer un ancien coup, lorsque l'on a joué un nouveau coup. La fonction game_restart() efface l'ensemble de l'historique. Les autres fonctions ne sont pas concernés par la gestion de l'historique.

Le fichier game_ext.h contient la description de ces nouvelles fonctionnalités. Notez que la version 2 du jeu est une extension, qui garde la compatibilité avec la version 1.

La nouvelle documentation du jeu dans sa version 2 est disponible sur la page https://pt2.gitlabpages.inria.fr/support/doc/v2/html/ et plus particulièrement dans la documentation de game_ext.h.

Avertissement : Vous ne devez en aucun cas modifier les fichiers d'en-têtes (ou headers) qui vous sount fournis et qui sont contractuels : game.h, game_aux.h et game_ext.h.

Travail demandé

Avant toute chose, commencez par créer dans votre dépôt Git une branche v1 et publiez cette branche. Cela permet d’étiqueter dans Git la version stable du code dans cette version, et de la retrouver facilement par la suite. Attention, on continuera le développement de la version 2 sur la branche main.

git branch v1                     # création d'une branche locale v1 identique à main
git switch v1                     # on passe sur la branche v1
git push -u origin v1             # on publie la branche v1
git switch main                   # on revient sur la branche main

Voici un plan d'attaque pour passer de la version 1 à la version 2 :

  • Récupérez le fichier game_ext.h et ajoutez-le à votre dépôt.
  • Ajoutez dans GitLab un nouveau jalon V2 et de nouveaux tickets pour chaque nouvelle fonction à implémenter.
  • Ajoutez une implémentation "vide" des fonctions de la version 2 dans votre bibliothèque game et modifiez le fichier CMakeLists.txt en conséquence.
  • En principe, tout doit compiler et s'exécuter normalement, y compris les tests de la version 1. Faites un commit.
  • Identifiez la liste des modifications à apporter à la bibliothèque game, et en particulier à la structure game_s.
  • Identifiez également la liste des nouveaux tests à implémenter spécifiquement pour la version 2. Rajouter des nouveaux tickets pour ces tests !
  • Répartissez-vous les tâches à effectuer et ajoutez de nouveau tickets si nécessaires dans GitLab...
  • Implémentez la version 2, sans négliger l'implémentation des tests qui vont avec...
  • Modifiez également le programme game_text afin qu'ils gèrent les commandes undo ('z') et redo ('y').
  • Effectuez votre rendu en équipe sur Moodle.

Un peu d'aide

  • Il est recommandé d'implémenter les nouvelles fonctions de game_ext.h dans un fichier source game_ext.c. Pour ce faire, il vous faudrait déplacer la définition de la structure game_s dans une nouveau fichier game_struct.h, qu'il vous faudra alors inclure dans les fichiers game.c, game_aux.c et game_ext.c, afin que la définition de cette structure soit connue : #include "game_struct.h".
  • Pour réaliser simplement un historique des coups joués du type undo & redo, il est recommandé d'utiliser deux piles. La première pile sert à mémoriser les coups joués afin de pouvoir les annuler (undo) dans l'ordre inverse. La deuxième pile sert à mémoriser la dernière séquence de coups annulés, afin de pouvoir les rejouer si besoin (redo). Pour ce faire, nous mettons à votre disposition le code d'une double-ended queue, une structure de données qui sert à la fois de pile et de file. N'oubliez pas d'intégrer ce code à votre bibliothèque si vous le souhaitez.
  • Concernant game_text, il doit continuer defonctionner normalement avec le jeu par défaut... Nous verrons plus tard comment le faire jouer à d'autres jeux via des fichiers.
  • Concernant la fonction game_copy(), il n'est pas demandé de recopier l'historique. Ce point précis ne sera pas évalué.
  • Voici une proposition de plan d'attaque... 1) coquille vide avec game_ext.h game_ext.c -> commit 2) modifier la structure et relancer les tests jusqu'à ce que ça passe sans erreur ni problème de mémoire -> commit 3) virer tous les 5 et DEFAULT_SIZE partout dans le code (sauf dans game_default, game_new, game_new_empty) et relancer les tests -> commit 4) implémenter game_new_ext et game_new_ext_empty (éventuellement faire du refactoring pour éviter la duplication de code) -> commit 5) compléter les tests des anciennes fonctions pour que cela fonctionne également avec des grilles rectangulaires -> commit 6) implémenter des tests pour les cas wrapping ortho... -> commit 7) à l'aide des tests rectifiez les fonctions existantes jusqu'à ce que les tests passent -> commit 8) implémenter undo/redo + les tests undo_redo -> commit 9) corriger votre implémentation jusqu'à avoir les tests OK -> commit