Bonjour à tous,

l’objectif de cette SAE est de compléter le code donné en TP.  Vous devrez :

1. blinder le code donné lors de TPs liés à cette SAE (prog 10, prog 13, prog 14);
   1. i.e. pas de boulette :
      1. on ne peut pas jouer à la place du 2ème joueur;
      2. pas de débordement dans les indices – sauf si règles particulières;
      3.  …
2. générer la documentation de votre projet à l’aide de doxygen
3. fournir des améliorations
   1. utilisation de MinGL;

   2. utilisation de la struct termios (pour ceux qui souhaite garder le terminal)

   3. ajout de fonctionnalités (liste non exhaustive) :
      1. lecture de fichiers de config (ie finir les TP 13 & 14);
      2. des niveaux de jeux;
      3. des points particuliers (téléportation, mur, …);
      4. un high score;
      5. …

Avertissement : je suis team 3.3 (ajout de fonctionnalités).

Pour cette sae, vous devrez :

• constituer des groupes de 4 ou 5 étudiants.

Le rendu votre SAE sera le suivant :

• rendu avant le vendredi 10 janvier (12h30) sur la plateforme ametice ;
• votre travail (une archive au format “zip” et ne contenant aucun binaire / exécutable – ni .o) devra contenir  :
  • un pdf expliquant ce que vous avez fait;
  • un répertoire contenant la documentation que vous avez générée ;
    • N’oubliez pas de générer les graphes des fonctions appelées et des fonctions appelantes …
  • un fichier texte expliquant comment on joue à votre jeux et les règles de jeux.
  • tips : pour pouvez lire ce fichier et le faire afficher dans votre programme. En revanche faites bien attention à son chemin / son emplacement …
• Votre archive devra suivre la nomenclature suivante GX_nom1_nom2_nom3.zip
  • où X sera remplacé par votre numéro de groupe;
  • nom1, nom2, … seront remplacés par les noms de votre groupe de projet. Ces noms devront être ordonnés par ordre alphabétique croissant.
• Prévoir une présentation de ~~ 10 minutes lors de la semaine du 13 janvier
• Notation (comment on va vous noter) – le barème est sur 20 pts :
  • Rapport (2 pts);
  • Présentation (3 pts);
  • documentation  (2 pts)
  • Des points à vous répartir entre vous selon le principe suivant (3 pts):
    • Chaque étudiant de chaque groupe de projet à 3 pts qu’il peut répartir comme il le souhaite;
    • En conséquence, si vous êtes une équipe de 4 étudiants, vous disposez de 12 points à vous répartir, si vous êtes 5 étudiants, vous avez 15 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 > 20.
  • votre code (10 pts) :
    • au choix (2 pts) : MinGL /  struct termios ;
    • nouvelles fonctionnalités (8 pts) – voir paragraphe 3.3;
    • bonus fun / lore (2 pts).
• 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 / 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).