SAÉ S1 · Java CLI
Outil pédagogique pour comprendre la logique de jeu.
Jeu éducatif où deux joueurs avancent leurs pions en répondant à des questions de difficulté croissante.
C'est l'un de mes premiers projets en groupe. J'ai appris à découper le travail pour que plusieurs personnes puissent coder en parallèle sans se bloquer mutuellement — définir qui fait quoi, et s'assurer que les parties s'assemblent correctement à la fin.
iJava interdit la POO : pas de classes, pas d'objets. J'ai dû adapter ma façon de penser pour modéliser un jeu avec des tableaux et des fonctions là où un langage objet aurait été naturel. Cette contrainte m'a forcé à comprendre les fondements avant les abstractions.
Sans structures objet, le code devient vite illisible si on ne se fixe pas des conventions. J'ai proposé des préfixes de nommage pour les variables liées à chaque entité du jeu (joueur, question, partie), ce qui a aidé l'équipe à s'y retrouver dans un code sans hiérarchie de classes.
C'est l'un de mes premiers projets en Java. J'ai appris à décomposer une mécanique de jeu (tour par tour, progression des joueurs, questions à difficulté croissante) en fonctions simples et testables. Cela m'a donné le réflexe de penser « petits morceaux » avant de coder.
iJava impose de travailler sans POO ni structures avancées, ce qui rend la gestion de l'état du jeu rapidement lourde avec des tableaux et des variables globales. Coordonner le travail d'équipe sur un même fichier sans système de branches clair a également généré des conflits.
Avec le recul, j'utiliserais du Java standard avec des classes et de l'encapsulation pour modéliser les entités (joueur, question, partie). Je mettrais aussi en place Git avec des branches dès le premier jour pour éviter les conflits sur le code partagé.