Démineur

Dans ce solitaire, un certain nombre de mines sont dissimulées dans une grille et le but est de révéler toutes les cases qui ne sont pas minées. Le joueur peut cliquer sur une case pour la révéler, mais il perd immédiatement la partie si cette case contient une mine. Dans le cas contraire, la case révélée affiche un chiffre qui indique combien de mines sont situées dans les cases adjacentes.

exemple de plateau de jeu

Vous produirez un programme écrit en Java, sans emprunt extérieur (sauf l'API officielle), et accompagné d'un rapport. Le travail sera fait seul ou en binôme, et devra être terminé avant le mercredi 25 mai 2022 à 18h00.

La partie logicielle sera développée dès le départ à l'aide du serveur Gitea du département. Le rapport prendra la forme d'un fichier au format PDF joint aux sources.

Principes généraux

Le nombre de lignes et le nombre de colonnes sont compris entre 4 et 30, mais la grille n'est pas nécessairement carrée. Chaque case peut être révélée ou cachée. Les cases cachées peuvent être minées ou pas. Initialement, toutes les cases de la grille sont cachées.

Une case révélée contient un numéro qui indique combien de cases (parmi les 8 cases voisines) sont minées. Si ce nombre est nul, le chiffre n'est pas affiché. Une case cachée peut être affublée d'un marqueur : pour indiquer que le joueur est certain qu'elle est minée, ou ? pour un simple soupçon.

Le joueur ne peut pas interagir avec les cases révélées. Il peut par contre cliquer sur une case cachée. En cas de clic droit, il change le marqueur de la case : de vide à , de à ?, ou de ? à vide. Ces marqueurs ne sont que des aides à la réflexion et ne fonctionnent pas différemment que la case soit réellement minée ou pas.

En cas de clic gauche sur une case cachée avec un marqueur, rien ne se passe (par sécurité). En cas de clic gauche sur une case cachée sans marqueur, si la case est minée, le joueur perd la partie. Sinon la case devient révélée. Si cette case n'est adjacente à aucune mine, on révèle automatiquement toutes ses cases voisines (ce qui peut provoquer une réaction en chaîne).

Le joueur gagne la partie quand il a révélé toutes les cases non minées.

Fonctionnalités demandées

Au démarrage de l'application, un écran de menu proposera le choix entre commencer une nouvelle partie, reprendre la partie précédente, ou quitter. Si aucune partie n'est en attente, la deuxième option sera inactive.

Lorsqu'il démarre une nouvelle partie, le joueur peut choisir les dimensions de la grille et le nombre total de mines (limité par le nombre de cases). Les mines sont ensuite réparties au hasard dans la grille (sans le montrer au joueur, bien sûr).

Durant une partie, en plus de la grille le programme affichera le nombre total de mines moins le nombre de marqueurs afin de montrer la progression du joueur. Un bouton «Sauver et Quitter» (et aussi le bouton habituel de la barre de titre) permettra de quitter l'application tout en mémorisant l'état de la partie.

En fin de partie, on indiquera la victoire ou l'échec, puis on laissera le temps au joueur de contempler la grille avant de le faire revenir au menu. Lorsqu'une partie est perdue, on affichera clairement les cases minées non marquées, les cases marquées non minées, et la case dont la mine a «sauté».

Sources

Les sources de votre projet (et pas les fichiers .class) devront être disponibles à tout moment sur le serveur Gitea du département. Votre dépôt sera privé, nommé obligatoirement SAE21_2021 et incluera Luc Hernandez (login : hernand) dans la liste des collaborateurs. Le nombre de soumissions, leur date et l'équilibre entre leurs auteurs influeront sur la note finale.

Pour chaque classe, vous prévoierez un fichier source. Suivez les consignes habituelles scrupuleusement. La définition de chaque classe et de chaque membre de classe sera précédée d'un commentaire formaté pour permettre la génération de documentation technique par l'outil javadoc (ceci est un exemple de fichier source bien commenté).

Un fichier Makefile devra permettre la compilation de votre projet (par la commande make) ainsi que son exécution (par la commande make run). Transcrivez bien toutes les dépendances entre vos fichiers dans les règles. La commande javac fait déjà (très mal) un travail similaire à make, ce qui peut créer des interférences. Pour éviter cela, pensez à lui passer l'option -implicit:none. Ceci est un exemple très basique.

Rapport

Le rapport d'avancement prendra la forme d'un fichier PDF disponible avec les sources sur le serveur Gitea. Vous y inclurez en particulier :

  • le nom des membres du binôme,
  • une introduction contenant une brève description du sujet,
  • la description des fonctionnalités de votre programme, aidée de captures d'écran,
  • une présentation de la structure du programme, avec diagramme de classes à l'appui,
  • une explication du mécanisme de sauvegarde d'une partie, sans extrait de code,
  • une exposition de l'algorithme qui permet de révéler plusieurs cases,
  • une conclusion personnelle pour chaque auteur.

Soignez la présentation ! L'orthographe, la grammaire, les pages de garde, la table des matières, les en-tête et pieds de page ne sont pas en option...

Notez bien que le rapport ne doit pas contenir d'extrait du code source du projet, étant donné que le correcteur peut aller le consulter directement s'il en éprouve le besoin. N'hésitez pas en revanche à illustrer vos propos par des schémas. Ceux-ci peuvent être construits directement dans le logiciel de traitement de texte s'il le permet, ou dans un logiciel dédié, tel que Inkscape ou Draw (tous deux gratuits). Le diagramme de classe sera réalisé à l'aide de StarUML.

retour à la page d'accueil

retour au sommet