1°/ Objectifs du projet
Le projet "développement IHM" a pour but de construire une application de type jeu de plateau en utilisant le langage Java et la bibliothèque graphique JavaFx. D'un point de vue pédagogique, ce projet permet de mettre en pratique les connaissances abordées pendant les cours, avec notamment le paradigme d'architecture MVC (Modèle - Vue - Contrôleur), la programmation objet, le test unitaire, mathématiques ... Ce projet étant transversal à la formation, les attendus mettent également en jeu des matières telles que l'expression, l'anglais et l'économie-droit.
Afin de garantir que les objectifs et délivrables attendus soient respectés, le sujet n'est pas libre. Les jeux possibles sont décrits dans la section suivante. Leur implémentation se fera obligatoirement en utilisant des frameworks de développement de jeux, fournis par le département, qui se déclinent en deux versions : une pour des jeux en mode texte, et une autre pour des jeux en mode graphique utilisant JavaFX. Ce framework permet de respecter une architecture MVC stricte, et facilite la mise en place des tests unitaires. De plus, il fournit l'essentiel de la "mécanique" nécessaire pour créer un jeu de plateau, ce qui permet au développeur de se concentrer sur le codage des règles du jeu choisi, sa représentation visuelle et les algorithmes de décisions pour permettre à l'ordinateur de jouer.
A ce sujet, chaque projet devra permettre de jouer soit à 2 joueurs humains ou ordinateurs, soit avec 1 humain et 1 ordinateur. De plus, quand un joueur est l'ordinateur, il devra pouvoir appliquer au minimum 2 stratégies différentes pour prendre ses décisions de jeu. Plus de détails sont indiqués dans la section cahier des charges.
2°/ Sujets possibles
Les groupes de projets doivent obligatoirement choisir 1 jeu parmi les 5 suivants. Les liens mènent vers un article précisant les règles utilisées pour chaque jeu dans le cadre de la SAÉ :
Ces jeux sont plus ou moins classés par difficulté de réalisation croissante, dont une partie vient de la complexité à gérer les règles et côté graphique du jeu, et l'autre sur les stratégies de jeu. Il va de soi que cette complexité impactera l'évaluation.
3°/ Cahier des charges synthétique
|
Les points ci-dessous concernent tout ce qui est commun entre les deux versions. Pour les fonctionnalités spécifiques à chaque version, consultez les articles dédiés : |
3.1°/ contraintes techniques
- Le jeu doit être développé en deux versions :
- v1 : pour jouer en mode texte, en utilisant le framework boardifier-console, ce qui nécessite uniquement les classes des base de Java.
- v2 : pour jouer en mode graphique, en utilisant le framework boardifier, ce qui nécessite d'utiliser la bibliothèque graphique JavaFX.
Remarque : les deux frameworks ayant une majorité de parties communes, une grande partie du code de la version 1 pourra être réutilisé pour produire la version 2.
- La langage utilisé est Java. La version conseillée de Java est l'openjdk 17 (voire la 11), avec également la v17 (ou v11) de JavaFX. Si vous utilisez une autre version, il est possible que cela pose des problèmes avec les framework boardifier.
- L'environnement de développement doit être Intellij IDEA.
- les sources doivent être déposées sur le gitlab du département. Attention : la trace des commits servira pour évaluer la contribution de chacun des membres du projet. Évitez-donc d'envoyer votre code à un camarade "centralisateur", et faîtes remonter votre code sur gitlab vous-même.
3.2°/ contraintes fonctionnelles
3.2.1°/ les règles
- Les règles sur le placement/déplacement des éléments de jeu décrites dans les articles consacrés à chaque jeu, doivent être respectées. Si ce n'est pas le cas, l'évaluation en tiendra compte proportionnellement au nombre et à l'importance des points de règle manquants.
- Cependant, si vous voulez implémenter des variantes en plus des règles de base, c'est possible, à partir du moment que l'interface permette aux joueurs de choisir quelle variante ils veulent prendre pour une partie. L'existence de ces variante sera bien entendu compté comme bonus dans l'évaluation.
- Les règles sur la terminaison de partie et la détermination du vainqueur "normales" (cf.exceptions ci-dessous) doivent être respectées. Si ce n'est pas le cas, l'évaluation en tiendra compte proportionnellement au nombre et à l'importance des points de règle manquants.
- Dans le cas du "Latroncules", il est possible que la partie puisse ne pas se terminer, notamment s'il n'y a pas assez de pions sur le plateau. Comme il est relativement complexe de détecter ce genre de situation, il n'est pas demandé de le faire. La partie continue donc "à l'infini", à moins que l'un des joueurs n'utilise l'ordre de jeu "stop", auquel cas, la partie est déclarée nulle, sans vainqueur.
3.2.2°/ ordinateur joueur
- A chaque tour de jeu de l'ordinateur, celui-ci va devoir effectuer une seule action, dont le type est fonction du jeu.
- Pour déterminer les actions à jouer tout au long de la partie, il est obligatoire d'implémenter au moins 2 types de stratégies différentes.
- Le choix de la stratégie à appliquer est fait au début de la partie.
- La stratégie la plus basique est de choisir une action au hasard, mais c'est la plupart du temps complètement stupide (donc nul). Ce type de stratégie sera bien évidemment considéré comme quasi nul au niveau de l'évaluation.
- Dans tous les cas, le calcul d'une action de jeu (= déplacement d'un unique pion) ne doit pas prendre plus d'une minute.
3.2.3°/ l'aspect graphique
- Tous les aspects du jeu (code, textes affichés, ...) doivent être en anglais.
- Pendant une partie, l'affichage du jeu doit être entièrement réalisé à partir d'éléments créés grâce à boardfier-console.
- Pendant une partie, le nom/pseudo du joueur courant doit être affiché.
3.2.4°/ Tests unitaires
- Pour chaque classe de la partie modèle (en excluant celles fournies par boardifier), des jeux de tests unitaires doivent être implémentés afin de tester les méthodes de ces classes.
- Pour la partie contrôle, certaines méthodes doivent être également testées, notamment toutes celles qui participent à la prise de décision des IAs.
- Pour la partie vue, normalement aucune méthode n'est à tester via des tests unitaires.
4°/ Organisation
4.1°/ planning
lundi 29 janvier : présentation générale
- Elle reprend l'essentiel des points abordés dans ce document. A l'issue de cette réunion, les étudiants devront constituer des groupes de 5 (sauf exception), choisir un sujet et envoyer ces informations au responsable de la SAÉ (sdomas@univ-fcomte.fr) ou celui la matière IHM (jean-claude charr)
- Les groupes doivent être constitués pour le 16 février.
jeudi 14 mars : présentation de l'organisation du développement de la version en mode texte
- Cette présentation reprend une partie des informations données dans le tutoriel Tutoriel 1 : créer un jeu de plateau en mode texte avec boardifier-console
- L'objectif est de fixer une méthodologie de travail pour que le développement de la version mode texte soit la plus aboutie possible.
- La présentation donne également des indications sur les points problématiques liés à chaque jeu.
du 14 mars au 24 mai : développement de la version mode texte + travail sur un question du droit du logiciel.
- Des plages horaires hebdomadaires dédiées au projet sont affichées sur ADE, pour un total de 27h.
- ATTENTION : selon les compétences du groupe et le jeu choisi, ce volume n'est pas forcément suffisant pour une équipe de 5.
- A noter que les journées du lundi 6 mai et mardi 7 mai ne sont pas entièrement dédiées à la SAÉ puisque vous devrez assister à quelques soutenances de stage des S6 (selon le planning qui vous sera fourni).
- le vendredi 24 mai, vous devrez rendre les délivrables du jalon 1 (cf. section 4.2°)
- cette même semaine ou la suivante, vous serez évalués sur la question de droit.
du 27 mai au 15 juin : développement de la version graphique.
- Des plages horaires hebdomadaires dédiées au projet sont affichées sur ADE, pour un total de 35h.
- A noter que la semaine du 10 juin est presque entièrement dédiée à la SAÉ.
4.2°/ délivrables
4.2.1°/ Jalon 1 - 24 mai
Les délivrables du premier jalon sont :
- code source compilable (incluant les test unitaires) de la première version (mode texte)
- les fichiers d'entrée afin de tester le déroulement du jeu,
- rapport technique en anglais,
- vidéo de démonstration du jeu en mode texte.
Les détails sur les deux derniers points sont donnés dans l'article dédié : Jalon 1 : délivrables rédactionnels (rapport + vidéo)
IMPORTANT : pour ce jalon, le jeu doit être jouable dans tous les modes (2 humains, 2 ordis, 1 humain+1ordi), quand bien même toutes les règles ne sont pas forcément appliquées.
4.2.2°/ Jalon 2 - fin mai
Une évaluation sur un sujet dans le domaine du droit du logiciel sera faite par B. Viezzi. Au mois d'avril, il affectera à chaque groupe un sujet particulier à traiter. La forme de cette évaluation devrait être une soutenance mais c'est susceptible de changer. A voir avec M. Viezzi.
4.2.3°/ Jalon 3 - 17/18 juin
Les délivrables du dernier jalon sont :
- le code final du jeu en mode graphique, ainsi que les tests unitaires qui vont avec.
- une soutenance de 15-20 minutes, dont la partie essentielle sera une démonstration de la version graphique du jeu (en direct, non filmée à l'avance).
Les détails sur ces différents points sont donnés dans l'article dédié : Deuxième version : attendus & méthodologie (2)