Relier les points

Relier les points (Flow Free ou Dot link dans sa langue maternelle) est un puzzle qui propose une grille carrée où sont placées des paires de points.

Le but est de relier les points identiques en traversant les cases de la grille par des mouvements horizontaux ou verticaux. Toutes les cases de la grille devront appartenir à exactement un tel chemin.

Vous pouvez vous faire une meilleure idée du fonctionnement du jeu en le testant à cette adresse.

Objectif

Vous produirez une application Android écrite en Java utilisant uniquement des classes originales et les classes vues en cours. Un rapport d'activité y sera joint. Le travail sera fait en binôme ou trinôme, et devra être terminé avant le dimanche 30 mars 2025 à 23h59.

Lorsque le jeu démarre, il affiche un menu qui propose de choisir un puzzle (voir section suivante) et d'accéder aux options (de la façon standard vue en cours).

La résolution du puzzle sera une autre activité. Le joueur pourra ajouter un chemin en posant son doigt sur un des points puis en se déplacant de case en case jusqu'au second point de la paire. Si le doigt rentre dans une case déjà occupée, sort de la grille, ou se lève prématurément, le chemin est annulé. Il sera possible de remplacer un chemin en repartant de l'une de ses extrémités.

Le jeu détecte automatiquement si le puzzle est résolu et l'indique au joueur. Après cela, le résultat reste visible mais le joueur ne peut plus modifier les chemins.

En cas de retour en arrière, l'activité de jeu mène au menu. Dans le cas du menu, un retour arrière termine l'application. Une partie en cours ne doit pas être perdue si l'application est mise en pause.

Une activité de configuration accessible seulement depuis le menu principal devra permettre l'activation d'un mode achromate. Dans ce mode, les couleurs qui sont utilisées pour distinguer les paires de points sont remplacées par des tons de gris.

Stockage des puzzles

Chaque puzzle prendra la forme d'un fichier XML placé dans un répertoire dédié dont le chemin sera app/src/main/assets/puzzles en partant du répertoire racine du projet.

Le menu de l'application devra permettre de sélectionner n'importe quel puzzle de ce répertoire (y compris des puzzles ajoutés par le correcteur). Il est possible de découvrir ces fichiers en passant par la méthode getAssets de la classe Context. Le parcours d'un de ces fichiers doit se faire à travers l'interface XmlResourceParser.

La forme d'un fichier décrivant un puzzle sera la suivante : une balise racine puzzle ayant des attributs taille et nom et contenant des balises paire. Chaque balise paire contient exactement deux balises point ayant des attributs ligne et colonne. Par exemple, le puzzle illustré plus haut correpond au fichier exemple.xml :

<puzzle size="5" nom="Exemple simple">
  <paire> <!-- marron -->
    <point colonne="0" ligne="0" />
    <point colonne="3" ligne="3" />
  </paire>
  <paire> <!-- rose -->
    <point colonne="2" ligne="0" />
    <point colonne="2" ligne="2" />
  </paire>
  <paire> <!-- vert -->
    <point colonne="0" ligne="1" />
    <point colonne="1" ligne="3" />
  </paire>
  <paire> <!-- bleu -->
    <point colonne="0" ligne="3" />
    <point colonne="1" ligne="4" />
  </paire>
</puzzle>

Le nom d'un puzzle, tel qu'il est défini dans son fichier, doit apparaître dans le menu et dans l'activité de résolution. Si l'attribut nom n'est pas présent, le nom du fichier (sans son extension) est utilisé à la place.

La taille d'un puzzle est nécessairement comprise entre 5 et 14. Elle correspond à la fois au nombre de lignes et au nombre de colonnes. Cet attribut est obligatoire.

Les attributs ligne et colonne de la balise point sont également obligatoires. Les valeurs acceptables sont comprises entre 0 (inclus) et la taille du puzzle (exclus).

En cas d'erreur dans la syntaxe, le puzzle doit quand même apparaître dans le menu, mais sous une forme désactivée afin que le joueur ne puisse pas le sélectionner.

Sources

Les sources de votre projet (mais pas le répertoire build) devront être disponibles à tout moment sur le serveur Gitea du département. Votre dépôt sera privé, nommé obligatoirement SAE41_2024 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.

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 groupe,
• une introduction contenant une brève description du sujet (avec vos propres mots),
• la description des fonctionnalités de votre programme, aidée de captures d'écran,
• une présentation de la structure du programme, avec un diagramme de classes pour chaque activité,
• une explication de l'algorithme qui décide si le puzzle est résolu,
• 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). Les diagrammes de classe seront réalisés à l'aide de StarUML.