Aller au contenu
/tous les projets

Arcade

Plateforme de jeu en C++ : sélection du jeu et de la bibliothèque graphique au lancement, changement à chaud entre plusieurs moteurs de rendu sans recompiler.

Rôle
Développement — architecture modulaire à chargement dynamique (équipe)
Année
2026
Réalisé avec
C++, SFML, SDL2, ncurses
Illustration d'une manette de jeu et d'un personnage

Contexte

Projet de 2ᵉ année à Epitech (module G-OOP-400), en équipe : une plateforme d'arcade qui charge dynamiquement sa bibliothèque graphique et ses jeux sous forme de modules.

Problème

Permettre de changer de bibliothèque graphique (ncurses, SDL2, SFML) et de jeu (Snake, Démineur) sans recompiler, en gardant une seule base de code pour le cœur du programme.

Contraintes

  • Chargement dynamique de bibliothèques (.so) au runtime, derrière une interface commune (IDisplayModule / IGameModule)
  • Trois bibliothèques graphiques aux API très différentes : texte (ncurses), SDL2, SFML
  • Un seul binaire principal, aucune recompilation pour changer de jeu ou de bibliothèque

Approche

  1. 01

    Interfaces communes

    Définition de IDisplayModule et IGameModule pour découpler le cœur du programme des bibliothèques et des jeux.

  2. 02

    Chargement dynamique

    Chargement des .so au runtime et bascule entre bibliothèques sans recompiler.

  3. 03

    Jeux

    Implémentation de Snake et du Démineur sur cette architecture commune.

  4. 04

    Documentation

    Notice « comment ajouter une bibliothèque » pour qu'un nouveau moteur graphique s'intègre sans toucher au cœur.

Architecture

Cœur
IDisplayModule · IGameModule · Chargement dynamique (.so)
Bibliothèques graphiques
ncurses · SDL2 · SFML
Jeux
Snake · Démineur

Décisions

Interfaces communes plutôt qu'un code par bibliothèque

IDisplayModule et IGameModule imposent un même contrat à toutes les bibliothèques et à tous les jeux : le cœur du programme n'a jamais besoin de savoir s'il parle à ncurses, SDL2 ou SFML.

Modules chargés au runtime

Chaque bibliothèque graphique est un .so séparé, chargé au lancement selon l'argument passé en ligne de commande — changer de bibliothèque ne demande aucune recompilation du cœur.

Résultat

Une plateforme qui lance indifféremment Snake ou le Démineur avec ncurses, SDL2 ou SFML, sans recompilation, avec un système de score par bibliothèque.

Concevoir les interfaces avant d'écrire les bibliothèques concrètes force à vraiment séparer ce qui est stable (le contrat) de ce qui change (l'implémentation) — un réflexe qui sert bien au-delà d'un projet d'école.