Chuzzle

Chuzzle est un puzzle qui propose une grille de 6 lignes par 6 colonnes. Les cases se voient attribuer au hasard un type parmi 7 possibles (représentés ici par des couleurs). Au départ, aucun type ne peut se répéter plus de deux fois horizontalement ou verticalement.

Le joueur peut choisir une ligne ou une colonne et la faire glisser pour lui appliquer une permutation circulaire. Les éléments choisis se décalent tous du même nombre de cases. Ceux qui sortent de la grille réapparaissent du côté opposé.

Un tel mouvement n'est permis que s'il crée une série d'au moins trois éléments de même type qui se suivent en ligne ou en colonne. Toutes les séries ainsi créées sont retirées de la grille. Les éléments situés au dessus des cases libérées tombent pour boucher les trous.

Les cases libérées en haut de chaque colonne sont remplies avec des éléments de type aléatoire.

La grille résultante peut encore contenir des séries ; on recommence donc les étapes précédentes jusqu'à obtenir une grille stable.

Parfois, à la fin de la résolution d'une action, un élément devient verrouillé. Cela signifie qu'il n'est plus possible de glisser la ligne et la colonne qui le contiennent. Le verrou reste jusqu'à ce que l'élément soit retiré (en participant à une série).

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 29 mars 2026 à 23h59.

Lorsque le jeu démarre, il affiche un menu qui propose de démarrer une partie normale, de démarrer une partie destinée et d'accéder aux options (de la façon standard vue en cours).

Dans le cas d'une partie destinée, on passe à une autre activité qui permet à l'utilisateur d'entrer la graine de la partie qu'il désire jouer. Cette graine servira à initialiser le générateur pseudo-aléatoire, de sorte que chaque partie basée sur la même graine commence exactement de la même façon, et évolue de la même façon si le joueur fait les mêmes actions.

Le jeu en lui-même se déroule dans une autre activité. En plus de la grille, le nombre de coups joués et le score courant (voir plus loin) seront affichés en permanence à l'écran. Attention à ne pas rendre le jeu inaccessible pour les daltoniens !

L'apparition des verrous peut être aléatoire ou déterministe, mais elle doit s'accélerer en fonction du nombre de coups (faites des tests pour trouver le bon rythme).

Un coup doit obligatoirement créer une série sinon il est refusé et la grille revient à son état précédent. Si aucun coup n'est possible, la partie est terminée. Le jeu détecte automatiquement cette situation et l'indique au joueur. Après cela, le résultat reste visible mais le joueur ne peut plus interagir avec la grille. On affichera à ce moment-là la graine de la partie (même si c'est une partie normale).

Une activité de configuration accessible seulement depuis le menu principal devra permettre l'activation d'un « hard mode ». À vous de choisir comment cela affecte les règles du jeu. Cette fonctionnalité sera évaluée sur son équilibrage, son originalité et l'effort de développement requis.

En cas de retour en arrière, les activités de jeu, de sélection de la graine et de configuration mènent 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.

Score

Le score est augmenté à la fin de chaque coup. Chaque série retirée rapporte 8, 16, 32 ou 64 points de base en fonction de sa longueur. Le total de tous ces points de base est ensuite modifié par un bonus : +50% par série après la première.

Par exemple, si un coup a retiré deux séries de trois éléments, puis en cascade une autre série de cinq éléments, les points de base cumulés valent 48. La présence de deux séries supplémentaires donne un bonus de 100%, donc le score augmente finalement de 96 points.

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_2025 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 la partie est finie,
• 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 ou autre outil spécialisé en UML. Faites bien attention à ce que tous les diagrammes soient lisibles avec un facteur d'affichage de 100%.