Paysages

Dans ce jeu inspiré librement de Dorfromantik, le joueur doit assembler des tuiles hexagonales pour former un paysage harmonieux.

exemple de paysage

Vous produirez un programme écrit en Java, sans emprunt extérieur (sauf l'API officielle), et accompagné d'un rapport. Le travail sera fait en binôme ou trinôme, et devra être terminé avant le dimanche 15 décembre 2024 à 23h59.

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.

Tuiles

Les tuiles sont des pièces hexagonales qui servent à délimiter cinq terrains différents : mer, champ, pré, forêt et montagne.

les cinq terrains

Une tuile peut contenir un ou deux terrains. Lorsque deux terrains cohabitent sur une tuile, ils se partagent les côtés : 1+5, 2+4 ou 3+3.

les formes de tuiles

Parties

Une partie se déroule de la façon suivante. La première tuile est posée automatiquement. À chaque tour, une tuile est révélée au joueur, et celui-ci choisit la position et l'orientation dans laquelle poser cette tuile. La seule contrainte est que la nouvelle tuile doit être adjacente à une tuile déjà posée. La partie se termine lorsque 50 tuiles ont été posées.

Tout au long de la partie, on affiche le score courant, qui est calculé en additionnant les points obtenus pour chaque poche de terrain. Si deux tuiles sont connectées par des côtés qui montrent le même terrain, ces tuiles appartiennent à la même poche. Le nombre de tuiles dans une poche, élévé au carré, donne le nombre de points accordés.

2²+2²+2²+2²+1² = 17 points

Notez qu'un paysage peut contenir plusieurs poches isolées du même terrain. Une tuile qui contient deux terrains compte obligatoirement pour deux poches différentes.

Serveur

Un serveur de base de données sert à retenir les séries disponibles et les scores des joueurs (de façon anonyme).

Pour que deux scores puissent être comparés, il faut qu'ils correspondent à des parties qui ont utilisé la même série de tuiles.

Le serveur se souvient donc d'un certain nombre de séries sur lesquelles les joueurs peuvent baser leur partie. Il n'est pas demandé de coder la possibilité d'ajouter une série, mais pour pouvoir tester le programme, plusieurs séries devront être déjà présentes sur le serveur.

Lorsqu'un joueur débute une partie, il doit choisir parmi les séries disponibles (sans voir leur contenu). À la fin de la partie, le programme utilise les scores connus du serveur pour cette série afin de montrer au joueur la qualité de son score.

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 SAE31_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. 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é).

Vous devrez respecter l'organisation du code vue au début de l'année. Toutes vos classes appartiendront à un package. Un fichier Makefile devra permettre la compilation de votre projet et la création d'une archive jar. Transcrivez bien toutes les dépendances entre vos fichiers dans les règles.

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,
• 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 simplifié à l'appui,
• une analyse de l'algorithme qui identifie les poches, avec un diagramme d'activité,
• une explication, pour chaque écran, des améliorations ergonomiques que vous avez mises en œuvre,
• une exposition de la façon dont la qualité d'un score est évaluée à travers la comparaison avec les scores des autres joueurs,
• 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 et d'objets seront réalisés à l'aide de StarUML.