Contexte pédagogique (R1.01)
Dans le cadre de cette SAÉ, vous allez concevoir le cœur algorithmique d’une plateforme d’organisation de tournois. L’objectif est de programmer un système capable d’enregistrer des joueurs, de les faire s’affronter sur un jeu simple, et de déterminer un classement final selon un format de compétition précis.
Pour garantir la fiabilité de votre programme, vous devrez valider votre code grâce à un système de tests automatisés basés sur des fichiers oracles et la redirection de flux sous Linux.
1. L’Algorithme : Mini-jeu et Format de Tournoi
Vous devez concevoir et implémenter deux éléments principaux interdépendants :
- Un mini-jeu : Vous programmerez un jeu simple permettant de départager deux joueurs (par exemple un jeu de “Pile ou Face”, un “Pierre-Feuille-Ciseaux”, un jeu de dés, un pendu, …).
- Un système de tournoi : Vous devrez programmer l’organisation d’une compétition complète en implémentant les méthodes d’appariement suivantes :
- Le Système Suisse
- Le Round Robin (Toutes rondes)
- Le Double Bracket (Arbre à élimination avec Loser Bracket)
Note : Le programme devra faire s’affronter les joueurs inscrits selon le format de tournoi choisi, en faisant appel au mini-jeu pour déterminer le vainqueur de chaque match. Pour que vos tests automatisés fonctionnent, les actions ou résultats aléatoires devront être lus depuis l’entrée standard.
2. Validation par Oracles et Redirection de flux
Votre programme ne doit pas ouvrir ou fermer de fichiers directement dans le code. Il doit lire les informations depuis l’entrée standard (le clavier) et afficher le résultat sur la sortie standard (l’écran).
Pour automatiser les tests avec vos fichiers d’essais, vous utiliserez la redirection de flux sous Linux (< et >).
Si votre exécutable s’appelle moteur_tournoi, vous le testerez ainsi dans le terminal : ./moteur_tournoi < test1.in > resultat1.out
Ensuite, vous vérifierez que votre sortie correspond exactement à l’oracle attendu en utilisant la commande diff : diff resultat1.out test1_oracle.out (Si la commande diff n’affiche rien, c’est que votre programme fonctionne parfaitement !)
Spécification des entrées attendues (Gestion des commentaires)
Votre programme lira la liste des participants, puis les actions nécessaires au déroulement des mini-jeux de tout le tournoi.Attention : les fichiers d’entrée peuvent contenir des lignes de commentaires pour documenter les tests. Ces lignes commencent toujours par le caractère #. Votre programme doit être capable d’ignorer ces lignes lors de la lecture.
Exemple de données lues sur l’entrée standard :
# Liste des participants
Joueur:Alice
Joueur:Bob
Joueur:Charlie
Joueur:David
# Début du tournoi (ex: Pile=0, Face=1 pour les actions des joueurs)
Action:0
Action:1
Action:1
Action:1
Spécification des sorties attendues sur la sortie standard
Votre programme devra afficher exactement le classement final du tournoi, sans aucun texte superflu ni commentaire de débogage :
1:Charlie
2:Alice
3:Bob
4:David
3. Jeux d’essais (Fichiers fournis pour vos tests)
Pour valider votre code, vous devez tester au minimum deux scénarios (oracles) complets de tournois. Assurez-vous que votre programme gère bien les lignes de commentaires présentes dans les fichiers .in.
Oracle 1 : Tournoi classique (4 joueurs)
- Fichier d’entrée (
test1.in) :# Inscription des 4 joueurs Joueur:J1 Joueur:J2 Joueur:J3 Joueur:J4 # Série d'actions pré-définies pour valider la logique de votre format de tournoi Action:0 Action:1 Action:2 Action:0 - Fichier Oracle (
test1_oracle.out) :1:J3 2:J1 3:J4 4:J2
Oracle 2 : Tournoi avec égalités ou repêchages
- Fichier d’entrée (
test2.in) :# Inscription Joueur:A Joueur:B Joueur:C Joueur:D # Actions déclenchant des scénarios particuliers (matchs nuls, loser bracket, etc.) Action:1 Action:1 Action:0 Action:1 Action:2 - Fichier Oracle (
test2_oracle.out) :1:A 2:C 3:B 4:D
4. Travail demandé (Livrables)
Le rendu votre SAE sera le suivant :
- rendu avant le 6 novembre (18h) sur la plateforme ametice ;
- votre travail (une archive au format “zip” et ne contenant aucun binaire / exécutable – ni .o) devra contenir :
- un pdf explicant quels systèmes de classement vous avez codé;
- aux moins 3 projets (sous QT creator) – un projet par système de classement;
- au moins 2 jeux d’essais (par projet) vérifiant vos propositions.
- pour cela on va utiliser des fichiers oracle : https://en.wikipedia.org/wiki/Test_oracle
- Cela implique au moins 2 jeux d’essais et 2 les fichiers oracles relatifs par projet.
- Votre archive devra suivre la nomenclature suivante TD_AA_E_BB_YYYY_ZZZ_BBBB_CCCC.zip
Dans cette normenclature :
- AA représente votre groupe de TD;
- BB représente votre numéro d’équipe;
- YYYY, BBBB, CCCC, … représentent les noms des étudiants, dans votre équipe, triés par odre alphabétique.
- Prévoir une présentation de ~~ 10 minutes lors de la semaine du 16 novembre
- Notation (comment on va vous noter) – le barème est sur 30 pts :
- Rapport (2 pts);
- Présentation / diaporama – sans code (3 pts);
- 5pts par système de classement répartis comme suit :
- 4 pts par système de classement (codage d’un algo);
- 1 pt par fichier oracle pour un même système de vote.
- 2 pts par système de classement corrigé par les pairs;
- Des points à vous répartir entre vous selon le principe suivant :
- Chaque étudiant de chaque groupe de projet à 4 pts qu’il peut répartir comme il le souhaite;
- En conséquence, si vous êtes une équipe de 4 étudiants, vous disposez de 16 points à vous répartir, si vous êtes 5 étudiants, vous avez 20 points à vous répartir.
- L’équipe pédagogique n’interviendra pas dans la répartition de ces points – sauf si un, ou plusieurs, étudiant(s) aurait (auraient) une note > 30.
- Les pénalités seront les suivantes :
- Si plus de 2 faotes d’ortogravhezkjz par page / par slide => -1 pt;
- Si un bug est découvert => – 3 pts pour le premier, – 2pts pour le second, -1pt pour le troisième – on s’arrêtera là : si vous avez, au moins 3, bugs, ça vous donne un malus de -6 pts, ça ne sert à rien de continuer;
- triche :
- Copie sur un autre groupe => 0 + conseil de discipline;
- Intégration du code provenant d’un autre tiers (dev externe /forum/
LLM/ ….) :- vous ne sourcez pas (voir partie copie – 2 lignes plus haut);
- Vous sourcez :
- note /2 si vous êtes capables d’expliquer le code;
- note = 0 (cf copie sinon).
N’oubliez pas de télécharger le code donné en amphi