Logo MazeIo

MAZEIO

Jeu de Labyrinthe Modulaire & Extensible.
Architecture professionnelle MVC, SOLID & Algorithmes avancés.

Java 17 JavaFX MVC SOLID DFS / BFS JUnit GitLab

🚀 Résumé du Projet

Développé en équipe sur une charge de 2 × 10 jours intensifs. L'objectif était de concevoir un jeu complet, performant et extensible, reposant sur une architecture testée et claire.

MazeIo propose une génération procédurale (parfaits / imparfaits), un système de sauvegarde modulaire et une interface UI inspirée de la PS4.

🏗️ Architecture & MVC

Une structure robuste respectant les standards industriels :

  • Model : Logique pure (Maze, Player, Generators)
  • View : JavaFX découplé (MazeCanvas, Animations)
  • Controller : Gestion via Observer & Events
  • Patterns : Strategy, Builder, Singleton, Observer

🧠 Algorithmes Avancés

Implémentation manuelle de structures de données :

  • Génération : DFS avec Piles (Stack) & Carving
  • Validation : BFS avec Files (Queue)
  • Heatmap : Calcul de distances optimales
  • Performance : Optimisation pour grands labyrinthes

💎 Principes SOLID

Exemple rare de conformité stricte en projet étudiant :

  • S : Responsabilité unique par classe
  • O : Extension des modes de jeu sans modifier le cœur
  • L : Substituabilité des variantes de Game
  • I/D : Injection de dépendances via Interfaces

🧪 Qualité & Tests

Stratégie de validation complète (voir PDF p.14) :

  • Tests Unitaires (JUnit 5)
  • Tests d'Intégration & Fonctionnels
  • Tests de Performance (Génération)
  • Intégration Continue (GitLab)

🎮 Contenu & Gameplay

Grâce à l'architecture modulaire, de nouveaux modes sont ajoutés par simple héritage :

Progression Memory Parent (Asymétrique) Endless Libre

Contexte

Cadre & objectifs du projet

Cadre

SAÉ BUT Informatique · IUT de Lille. Projet évalué, développé sur 2 × 10 jours intensifs en équipe.

Équipe

Projet de groupe avec gestion via GitLab — branches par développeur, merge requests, intégration continue.

Objectif

Concevoir un jeu de labyrinthe complet, performant et extensible, reposant sur une architecture MVC testée et respectant les principes SOLID.

Résultat

Application JavaFX fonctionnelle avec 5 modes de jeu, génération procédurale, sauvegardes et tests unitaires, intégration continue GitLab.

Contribution personnelle

Mon rôle dans le projet

Ce que j'ai implémenté et livré

  • Participation à la conception de l'architecture MVC et à la définition des interfaces
  • Implémentation de composants JavaFX (vues, canvas, animations)
  • Contribution aux algorithmes de génération et de validation (DFS/BFS)
  • Écriture de tests unitaires JUnit pour les modules dont j'avais la responsabilité
  • Gestion des branches GitLab et résolution de conflits lors des merges

Compétences techniques

Hard skills — illustrés par des situations concrètes

Architecture MVC

Séparation stricte des responsabilités

Le modèle (logique du labyrinthe, joueur, générateurs) n'a aucune dépendance vers JavaFX. Cela m'a permis de tester la logique métier indépendamment de l'interface — une séparation que j'applique depuis dans tous mes projets.

Algorithmes DFS / BFS

Génération et validation procédurales

J'ai implémenté les algorithmes de génération (DFS avec pile) et de validation (BFS avec file) en manipulant directement les structures de données — pas de bibliothèques. Cela m'a forcé à comprendre les fondements de ces algorithmes plutôt qu'à les utiliser en boîte noire.

Patterns de conception

Strategy, Builder, Observer en pratique

Les modes de jeu sont ajoutés par simple héritage grâce au pattern Strategy. Le pattern Observer découple la vue du modèle. Appliquer ces patterns sur un vrai projet m'a fait comprendre pourquoi ils existent — pas juste leur définition académique.

Tests JUnit & CI GitLab

Qualité vérifiable en continu

Chaque push sur GitLab déclenchait la pipeline CI. J'ai appris à écrire des tests qui échouent d'abord pour la bonne raison, et à faire confiance à la CI plutôt qu'aux tests manuels — ce qui économise du temps et évite les régressions silencieuses.

Compétences transversales

Soft skills — illustrés par des situations concrètes

Travail en équipe

Architecture décidée collectivement

Avant de coder, l'équipe a défini ensemble l'architecture MVC et les interfaces entre couches. J'ai appris que 30 minutes d'accord en amont évitent des heures de merge conflicts et de refactoring. Cette habitude de fixer les contrats avant d'implémenter est restée dans ma façon de travailler.

Organisation

2 × 10 jours avec livraisons régulières

Le format intensif imposait de prioriser : qu'est-ce qui doit fonctionner avant la fin de la semaine ? J'ai appris à découper les fonctionnalités en incréments livrables plutôt que de chercher la perfection dès la première itération.

Rigueur & qualité

SOLID comme standard d'équipe

Respecter les principes SOLID en équipe demande plus de discipline que seul : il faut signaler quand une classe grossit trop, ou quand une dépendance directe devrait être une interface. J'ai appris à donner et à recevoir des retours de code constructifs.

Analyse réflexive

Ce que ce projet m'a apporté

Ce que j'ai appris

L'architecture, ça se décide avant de coder

Sur Mazeio, on a passé du temps à définir les interfaces avant d'écrire la première ligne de logique. Résultat : chaque module était développable indépendamment. J'ai compris que le temps investi en conception est récupéré en intégration — et au-delà.

Ce que j'ai appris

JavaFX et le découplage vue/modèle

JavaFX est puissant mais ses bindings peuvent vite coupler la vue au modèle si on n'y prend pas garde. J'ai appris à garder le modèle ignorant de JavaFX, ce qui a rendu les tests unitaires possibles sans démarrer l'interface graphique.

Difficultés rencontrées

Coordonner 5 modes de jeu en parallèle

Chaque mode de jeu hérite d'une base commune, mais certains ajoutent des états spécifiques. Coordonner les développements parallèles sans casser les modes existants a demandé des merges attentifs et des tests de régression après chaque intégration.

Ce que je ferais différemment

Tests d'intégration dès le début

On avait de bons tests unitaires par module, mais les tests d'intégration (ex : générer un labyrinthe puis le résoudre) sont arrivés tard. Je les écrirais en parallèle du développement pour détecter les incompatibilités entre modules dès qu'elles apparaissent.