École & gamedev

Jeu Unity développé en équipe pendant le Bachelor jeu vidéo (Gaming Campus, 3e année).

Contexte

Projet d'équipe sur un dépôt partagé très actif, avec des branches d'intégration par domaine (outils, gameplay) et des revues de pull request entre coéquipiers.

Ce que j'y ai fait

Surtout de l'outillage et des systèmes : un outil de LOD, l'importeur et l'éditeur de graphe des dialogues, un puzzle de gameplay, et la remise en ordre du dépôt (arborescence, fusion des scènes, intégration continue).

Liens

Dépôt privé (école).

Architecture du projet

Démarrage par une scène _Bootstrap qui initialise les services (ServiceLocator) : sauvegarde JSON, audio, localisation multilingue. Les scripts communiquent par EventChannels (ScriptableObjects) sans se connaître.

Mes contributions

• LOD Manager : outil d'éditeur (6 scripts) qui génère et règle les niveaux de détail des modèles.
• Système de dialogue : importeur CSV qui retrouve chaque ligne par identifiant où qu'elle soit rangée, et éditeur de graphe (GraphView) récupéré d'une ancienne version du dépôt puis corrigé : liaisons qui sautaient à l'édition d'un choix, champ texte qui perdait le focus à chaque lettre, nœuds créés dans le graphe sans données.
• Puzzle de la luciole : le joueur l'approche, elle le suit, entre dans une lanterne cassée et la répare.
• Organisation du dépôt : réorganisation en 7 pull requests (440 fichiers déplacés sans casser une référence), script d'installation Git qui configure la fusion des scènes Unity, intégration continue.

Jeu en équipe développé pour les Gaming Campus Awards 25-26. Rôle dev sur l'engine custom C++/Vulkan.

Contexte

Grand Projet Commun Bachelor 3A. 17 personnes réparties sur cinq pôles (Tech, Art, Business, TV, Sound). Production sur cinq mois de janvier à fin avril 2026.

Concept

Hybride management + action/exploration. On gère un village de Perséphins en vue isométrique drag & drop, et on part en expéditions vue isométrique fixe ZQSD pour récolter des ressources, combattre la corruption et avancer dans l'histoire de Cali.

Cinq biomes jouables (un par peuple), 5 classes de héros, système de tiers T1-T5 sur tout (ressources, équipement, traits), reroll par gemmes colorées, puzzles intégrés (Piano, Plaque, Caisse, Tangram, Memory), mode endless après la zone 16.

Stack & engine

C++20, Vulkan 1.3, CMake + vcpkg. Engine custom : 5 libs (Framework, Render, Audio, Assets, Engine ECS) + scenes. Pipeline graphique avec shaders GLSL/SPIR-V, compute pour les particules GPU. Génération procédurale tile-based des maps d'expédition.

Liens

Repo privé (école). Pas de démo publique avant le rendu final du 29/04/2026.

Pitch

Cali, créature humanoïde du peuple Primoris, s'écrase sur la planète Hestia suite à un problème moteur. Elle se réveille sans mémoire, recueillie par les Perséphins. Avec l'aide d'Iris, un jeune Perséphin courageux, elle découvre que la planète est ravagée par la corruption Harmathys - un mécanisme de défense activé par l'arrivée des Primoris, qui transforme les habitants pacifiques en créatures agressives.

Genre & boucle de gameplay

Hybride gestion de village + expéditions action/exploration. Le joueur alterne entre deux phases :

┌──────────────────┐         ┌──────────────────┐
│  PHASE VILLAGE   │ ◄─────► │ PHASE EXPÉDITION │
│  (gestion iso.)  │ cycles  │  (action ZQSD)   │
├──────────────────┤         ├──────────────────┤
│ • Drag & drop    │         │ • Combat         │
│ • Bâtiments      │         │ • Puzzles        │
│ • Population     │         │ • Récolte        │
│ • Héros          │         │ • Boss           │
└──────────────────┘         └──────────────────┘

Chaque expédition consomme un cycle village (1 ration/villageois). Le village s'étend de 3×3 → 10×10 parcelles de 7×7 cases via les fragments de carte ramenés des expéditions.

Univers - 6 peuples

Peuple	Zone	Caractéristiques
Perséphins	Plaines centrales	Marchands nomades, sociaux
Yōtl	Dunes de sable	Guerriers, code d'honneur
Arynes	Forêts écarlates	Artistes, festifs
Kaprass	Montagnes	Astrologues, isolés
Khétus	Côtes	Navigateurs, pêcheurs
Primoris	Espace	Colons, technologie avancée

Cinq peuples = cinq biomes jouables avec ressources, ennemis et ambiance propres. Les Primoris sont la cause involontaire de la corruption.

Mécaniques village

Cinq bâtiments clés :

• Arbre de vie - Bâtiment central, plafonne le niveau des autres bâtiments
• Habitation - Augmente la capacité de villageois
• Hôpital - Purifie les villageois corrompus + soigne les héros
• Forge - Craft d'équipement (T1-T4) + reroll de stats via gemmes
• Caserne - Lance les excursions (1-3 héros en autonomie)

Mécaniques expédition

• 5 biomes × 4 zones + mode Endless débloqué après zone 16
• 5 classes de héros : DPS, Tank, Healer, Récolteur, Chercheur de trésor
• Tiers T1-T5 sur ressources, équipement et traits
• 6 couleurs de gemmes pour reroll (incolore = matériau, colorées = bloquent un trait)
• 5 types de puzzles : Piano, Plaque, Caisse-Plaque, Tangram, Memory
• Stats riches : armure, force, vitesse, fortune, chance, critique, combo, enchaînement, portée…

Stack technique

Tech	Version	Rôle
C++	20	Langage core
Vulkan	1.3	Pipeline graphique
CMake	3.20+	Build system
vcpkg	latest	Dépendances
GLFW	3.x	Windowing
GLM	latest	Math 3D
RtAudio	5.x	Audio
stb_image	latest	Textures

Engine custom organisé en 5 librairies GPC : Framework (clock, transform, state machine), Render (Vulkan, textures, shaders), Audio, Assets (loader, macros), Engine (pattern Entity-Component-System complet).

Génération procédurale tile-based pour les maps d'expédition : choix de forme de zone → liaison départ/arrivée → fermeture des murs → représentation en arbre pour les puzzles → collapsing des salles.

Équipe & contexte

17 personnes réparties sur 5 pôles : Tech, Art, Business, TV/Multimédia, Sound. 154+ commits côté code.

Projet Gaming Campus Awards 2025-2026 - validation Bachelor 3A.

Date	Rendu	Status
03/02/2026	Pitch	✅
25/02/2026	MAAV (compositeurs)	✅
27/02/2026	Préproduction	✅
29/04/2026	Final	⏳

Une semaine de multithreading en C++ avec l'API Win32 en GTech 3 : des exercices quotidiens, puis une arène où quatre threads se partagent la carte.

Contexte

Semaine du 17 au 24 novembre 2025. Les notes de cours (théorie, threads Win32, thread safety) sont rangées dans Semaine Exo/Doc/. Travail individuel.

Ce que j'y ai fait

Les quatre exercices de la semaine, puis deux versions de l'arène SFML : TestMessage (des boules qui changent de thread en changeant de zone) et TestComplet (joueurs, bonus, combats et fin de partie). Les dégâts d'une collision distante, les transitions de zone et les récompenses partent en message dans la SafeQueue du thread qui possède l'entité visée.

Liens

• 5---Multithreading (code sur la branche Kiki)

Exercices de la semaine (Semaine Exo/)

Jour	Exercice	Contenu
J1	WhackAThread	Jeu de taupe en console : chaque taupe est un thread (CreateThread), un thread lance les taupes, les événements passent par une file de messages
J2-3	SafeQueue	File bornée en tampon circulaire : CRITICAL_SECTION et deux CONDITION_VARIABLE (pas pleine, pas vide), push bloquant, tryPush / tryPop, test producteurs-consommateurs
J3	CollisionDetector	Collisions entre 50 000 sphères : version mono-thread, puis 2 et 4 threads, thread de suivi de la progression (Interlocked*)
J3-4	SafeCollision	Même détection en producteurs-consommateurs à travers la SafeQueue, cinq configurations comparées, dont une avec accumulation locale des résultats

Arène finale (Final/TestComplet)

Thread principal : rendu SFML (800 x 600), fin de partie, statistiques
ThreadManager
  └── 4 WorkerThreads, chacun avec ses entités et une SafeQueue<Message*>
        boucle de 16 ms : messages -> mise à jour -> collisions -> transitions
Carte : grille de 4 x 3 cellules de 200 px, cellule -> thread (index modulo 4)

• 12 joueurs, 8 bonus (PV, vitesse, bouclier, dégâts). Le dernier joueur en vie gagne.
• Collision locale (deux joueurs du même thread) : dégâts et rebond calculés sur place.
• Collision distante : le thread d'indice le plus bas l'applique à son joueur et envoie un CollisionMessage à l'autre thread, plus un KillRewardMessage si son joueur meurt.
• Transition : un joueur qui change de cellule est sérialisé dans un TransitionMessage, retiré de son thread et recréé dans le thread cible. La couleur du joueur indique son thread.

Stack

Tech	Rôle
C++	Langage
API Win32	CreateThread, CRITICAL_SECTION, CONDITION_VARIABLE, Interlocked*
SFML 2.6.1	Rendu de l'arène
Visual Studio	Build

Les travaux de maths et de physique de la 3e année (Gaming Campus, 2025-2026), tous rendus en console.

Contexte

Le cours de maths moteur portait sur les rotations et les projections 3D vers 2D, avec un donut ASCII comme fil rouge. Le partiel, en groupe, demandait de faire flotter et tourner ce donut. Le module de physique avancée a commencé par une semaine d'exercices d'intégration.

Ce que j'y ai fait

Le moteur de rendu ASCII du cours (maillages, projection, réglages), l'animation d'orbite du donut au partiel, et les exercices d'intégration d'Euler.

Liens

• Le Donut Flottant (fork public du dépôt de groupe)
• Math-GTech3 (cours de maths moteur et TD)
• 9---Physique-Avancee-DirectX (exercices de physique avancée)

Maths moteur (novembre 2025)

Programme console DonutMath : génération de maillages (cercle, demi-cercle, rectangle, carré), projection à l'écran et affichage en caractères ASCII. Taille de l'écran, résolution du maillage, caractères de fond et de projection, positions de l'écran et de l'observateur réglables en arguments de ligne de commande.

Partiel « Le Donut Flottant » (janvier 2026, groupe de 3)

Tore généré, tourné et éclairé en ASCII, qui flotte en orbite. Mes ajouts : la structure Vector3, le mouvement d'orbite dans l'animation, et ses réglages dans Settings.

Physique avancée (janvier 2026)

Exercices d'intégration numérique en C++ : Euler explicite, Euler semi-implicite, accélération variable et ressort simple.

Un parser de modèles 3D au format Wavefront OBJ et un tokenizer générique, écrits pendant le module « Parser » de GTech 3.

Contexte

Semaine théorique du 3 au 7 novembre 2025 : parser texte, parser binaire, parser .obj, puis une introduction au SDK FBX et à OpenGL. Le dépôt garde le nom du module (« Parser FBX ») ; le code écrit porte sur le tokenizer et le parser OBJ. Les supports de cours et les projets fournis (basicgl, bmp, parser) sont rangés dans Doc/.

Ce que j'y ai fait

Le tokenizer et son programme de test, puis le parser OBJ : structures de données, lecture ligne par ligne, prise en charge des quatre formats de face, conversion des indices, fichiers de test, CMake et README. Travail individuel.

Liens

• 4---Parser-FBX (code dans Semaine Exo/, branche Kiki)

Parser OBJ

Lignes reconnues :

Commande	Contenu
v x y z [w]	Sommet (w = 1.0 par défaut)
vt u v [w]	Coordonnée de texture (w = 0.0 par défaut)
vn x y z	Normale
f ...	Face : v, v/vt, v//vn ou v/vt/vn, triangles, quads et polygones
o nom	Nom de l'objet
#	Commentaire

Les indices du fichier (base 1) sont convertis en base 0 ; un indice absent vaut -1. Les lignes vp, s, g, usemtl et mtllib sont ignorées. Une erreur renvoie false et un message avec le numéro de ligne (getLastError()).

ObjData
  ├── vertices   : std::vector<Vertex>
  ├── texCoords  : std::vector<TexCoord>
  ├── normals    : std::vector<Normal>
  ├── faces      : std::vector<Face>  (FaceVertex : vIndex, vtIndex, vnIndex)
  └── objectName

Tokenizer

• tokenize : découpe un texte en jetons (:, (, ), {, }, /, \, ", , et chaînes).
• segmentize : regroupe les jetons en segments imbriqués (parenthèses, accolades, guillemets) à l'aide d'une pile.

Tests

• cube.obj : 8 sommets, 4 coordonnées de texture, 6 normales, 12 triangles.
• test-formats.obj : une face de chaque format, plus un quad.
• test.sh compile et lance le parser sur les deux fichiers.

Stack

Tech	Rôle
C++17	Langage
CMake / Visual Studio	Build (deux exécutables : TestObjParser, TestTokenizer)

Éditeur audio desktop pour fichiers WAV avec effets DSP, visualisation waveform et traitement temps réel.

Contexte

Projet école GTech3, 6 semaines. Équipe de 3, rôle : développeur DSP et moteur audio.

Exploration des fondamentaux du traitement de signal numérique via une application d'édition audio pratique.

Cahier des Charges École

• Parser et lire des fichiers WAV
• Affichage waveform
• Implémenter au moins 2 effets DSP
• API audio Windows, latence < 50ms

Notre Implémentation

Au-delà des consignes (2 effets demandés) :

• 4 effets DSP complets : EQ, compression, reverb, delay
• Édition non-destructive : preview avant application
• Outils de sélection avancés : cut/copy/paste sample-accurate
• Support formats étendus : 8/16/24-bit, mono/stereo

Liens

• Dépôt privé (école).

Architecture

Pipeline audio avec effets chaînables :

WAV File → Parser → [Effect Chain] → XAudio2 → Output
                         │
      ┌──────────────────┼──────────────────┐
      │                  │                  │
    EQ            Compressor           Reverb
 (Biquad)           (RMS)          (Convolution)

Stack Détaillé

Tech	Version	Rôle
C++	17	Langage core
XAudio2	Windows API	Moteur audio temps réel
Win32/ImGui	-	Interface utilisateur
Parser WAV	Custom	Lecture fichiers audio

Parser WAV Custom

• Parsing header RIFF
• Formats : 8/16/24-bit, mono/stereo
• Navigation chunks et métadonnées
• Au-delà du 16-bit demandé

Effets DSP Implémentés

• EQ paramétrique : Filtres biquad par bande
• Compresseur : Détection RMS avec attack/release
• Reverb : Bases de convolution
• Delay : Delay lines avec feedback

Spécifications

• Latence : < 50ms (API audio Windows)
• Édition non-destructive avec preview
• Sélection sample-accurate : cut/copy/paste

Trois petits programmes écrits pendant la semaine « Asset Engine » de GTech 3, pour apprendre à lire, valider et transformer des fichiers octet par octet.

Contexte

Un exercice par jour, d'après les sujets fournis (J1 « HexView », J2 « SafeReader ») : lire un fichier binaire quelconque, puis définir un petit format avec en-tête et somme de contrôle et le lire de façon défensive, sans jamais faire confiance au fichier. Travail individuel, du 20 au 23 octobre 2025.

Ce que j'y ai fait

HexView en deux versions (C avec malloc/fread, puis C++ avec std::vector et une classe), SafeReader avec ses outils de génération et de corruption, puis CryptFile. Les trois sont ensuite regroupés dans ExoComplet, un fichier autonome par exercice (menu intégré pour SafeReader et CryptFile), avec un README et un script de compilation.

Liens

• 3---Asset-Engine (code sur la branche Kiki)

Les trois exercices

Jour	Programme	Contenu
J1	HexView	Dump d'un fichier en 16 octets par ligne (offset, hexadécimal, ASCII), sauvegarde du dump en .txt, modification d'un octet à un offset, sauvegarde du fichier modifié
J2	SafeReader	Génération, validation et corruption de fichiers .safe
J3	CryptFile	Chiffrement et déchiffrement d'un fichier avec une clé texte, test de symétrie

Format .safe (J2)

HEADER (16 octets)
  magic    : 4 octets (0x45464153, « SAFE »)
  version  : 4 octets (1)
  dataSize : 4 octets
  checksum : 4 octets (XOR puis rotation à gauche d'un bit, octet par octet)
DATA (taille variable)

Le lecteur vérifie la signature, la version, la taille déclarée contre la taille réelle, puis le checksum. L'outil de corruption casse un champ à la fois pour vérifier que chaque erreur est détectée : magic, version, taille, checksum, un octet de données, ou fichier tronqué.

Chiffrement (J3)

• Chiffrement : rotation de 3 bits à gauche, puis XOR avec l'octet de clé (((b << 3) | (b >> 5)) ^ key).
• Déchiffrement : XOR, puis rotation inverse.
• La clé texte est répétée sur toute la longueur du fichier.
• Le test de symétrie chiffre, déchiffre et compare le résultat au fichier d'origine.

Deux versions de HexView

• C classique : fopen, fread, fwrite, malloc, free, typedef struct.
• C++ : classe HexView, std::vector, std::ifstream / std::ofstream, remplacement d'un bloc d'octets.

Stack

Tech	Rôle
C / C++17	Langage
g++ / Visual Studio	Compilation (compile_all.sh fourni)

Bibliothèque mathématique haute performance utilisant les instructions SIMD pour les opérations vectorielles et matricielles.

Contexte

Projet école GTech3, compétition d'optimisation, 4 semaines. Projet individuel.

Implémentation d'opérations mathématiques avec intrinsics SIMD pour atteindre le débit maximal.

Cahier des Charges École

• Implémenter des opérations vectorielles SIMD
• Benchmarker vs scalaire, speedup minimum 4x
• Intrinsics x86 (pas d'asm inline), SSE4.2 minimum

Mon Implémentation

Au-delà des vecteurs demandés :

• Hiérarchie complète : Vec2, Vec3, Vec4, Mat4, Quaternion
• AVX en plus de SSE : 8 floats vs 4
• Quaternions SIMD : rotations optimisées
• Data layouts optimisés : support SoA
• Runtime dispatch : détection CPU automatique

Liens

Code disponible sur demande.

Architecture SIMD

Hiérarchie de types avec dispatch runtime :

┌─────────────────────────────────────────┐
│         Runtime CPU Detection           │
│    (SSE4.2 / AVX / AVX2 disponible?)    │
└──────────────┬──────────────────────────┘
               │
     ┌─────────┴─────────┐
     ▼                   ▼
┌─────────┐         ┌─────────┐
│  SSE    │         │  AVX    │
│ 128-bit │         │ 256-bit │
│ 4 floats│         │ 8 floats│
└─────────┘         └─────────┘

Stack Détaillé

Tech	Version	Rôle
C++	17	Langage core
SSE4.2	x86 intrinsics	Registres 128-bit
AVX/AVX2	x86 intrinsics	Registres 256-bit
CMake	3.x	Build system

Types Implémentés

• Vec2, Vec3, Vec4 (SIMD)
• Mat4 (SIMD)
• Quaternion (SIMD)
• Support SoA (Structure of Arrays) pour batch

Techniques d'Optimisation

• Alignement mémoire (16/32 bytes)
• Data layout SoA vs AoS
• Patterns cache-friendly
• Élimination de branches
• Runtime dispatch SSE/AVX

Benchmarks

Opération	Scalaire	SIMD	Speedup
Vec4 dot	4 ops	1 op	~4x
Mat4 mul	64 ops	16 ops	~4x
Batch transform	N ops	N/4 ops	~4x

Démo Unity construite autour d'un système de sauvegarde complet, réalisée en octobre 2025 pendant le module « Persistance des données » de la 3e année.

Contexte

Le module portait sur la sauvegarde et le chargement de l'état d'un jeu. La démo sert de terrain d'essai : un joueur à la première personne avec des stats de survie, un inventaire et des objets à ramasser, tout ce qu'il faut sauvegarder.

Ce que j'y ai fait

Le système de sauvegarde (emplacements multiples, métadonnées, sauvegarde automatique), l'interface de sauvegarde et de chargement, le contrôleur joueur et l'inventaire.

Liens

Dépôt privé.

Sauvegarde

• SaveSystem (singleton persistant entre scènes) : sérialisation JsonUtility dans Application.persistentDataPath.
• 6 emplacements configurables + un emplacement automatique, chacun doublé d'un fichier de métadonnées pour afficher la liste des sauvegardes sans tout charger.
• Sauvegarde automatique toutes les 120 s (réglable), avec indicateur à l'écran.
• Données sauvegardées : vie, faim, soif, endurance, expérience, niveau, position, rotation caméra et joueur, inventaire.

Gameplay de démonstration

• Contrôleur à la première personne : course, accroupi, glissade (coût en endurance).
• Objets à ramasser, inventaire (TAB), menu pause (ESC) avec sauvegarde et chargement.
• Touches de debug pour modifier les stats et effacer la sauvegarde.

Outillage

• Workflow GitHub Actions de build Unity (Windows, Android, WebGL).
• Scripts PowerShell de build et de nettoyage du projet.

Jeu console en C# réalisé pour le module « Bases du C# » de la 3e année (Gaming Campus, 2025-2026).

Contexte

Le module demandait un jeu console complet en C# (classes, héritage, interfaces). Une semaine d'exercices sur un système d'inventaire et de stats (avec ses tests) a précédé le rendu.

Ce que j'y ai fait

Un shoot'em up spatial qui alterne combat contre des vagues et phases d'exploration, avec un rendu console maison, un système de quêtes, des types élémentaires combinables, des power-ups et une batterie de tests unitaires.

Liens

Dépôt privé (école).

Architecture

GameManager
    ├── FightScene    → vagues d'ennemis, projectiles, capacités
    ├── ExploreScene  → exploration, coffres, donneurs de quêtes
    ├── Canvas        → rendu console (appels kernel32 via P/Invoke)
    └── QuestManager / Inventory / UIManagerStats

Systèmes

• Types élémentaires en masque de bits : quatre types de base (chaleur, poison, glace, électrique) et six types combinés (viral, magnétique, radiation, corrosif, gaz, explosion), avec multiplicateurs d'efficacité.
• Modes de tir : tir simple, triple, latéral, décrits comme des listes de projectiles.
• Quêtes : huit types d'objectifs (tuer, collecter, parler, explorer, atteindre une vague, survivre, infliger des dégâts, utiliser une capacité).
• Stats et power-ups : modificateurs de statistiques et power-ups appliqués au vaisseau, sélection parmi quatre vaisseaux.

Tests

Projet de tests séparé (TestSpaceSquad) : combat, inventaire, power-ups, projectiles, quêtes, stats, efficacité des types.

Stack

Tech	Rôle
C#	Langage
.NET 8	Runtime, application console

Prototype de RPG stratégique développé pour le projet « Jeu Libre » de Gaming Campus, sur un moteur ECS écrit à la main.

Contexte

Le Game Design Document (mars 2025) décrit un RPG au tour par tour où le joueur, capitaine d'un navire dans un monde semi-futuriste majoritairement maritime, recrute un équipage, explore des îles et combat sur terre (cases hexagonales, jets de dés, initiative) et sur mer. Le moteur a d'abord été monté dans un dépôt « ECS 2D » (SFML 2.5, mars 2025), puis repris sous SFML 3.

Ce que j'y ai fait

Projet mené seul, de bout en bout : le moteur ECS (entités, composants, systèmes, bases de données JSON), les scènes d'exploration navale et des cinq îles, la scène de combat terrestre sur grille hexagonale, et le Game Design Document. Ce moteur a ensuite servi de base au Template ECS.

Liens

• JeuLibre (version SFML 3)
• ECS-2D (premier moteur, SFML 2.5)

Architecture

Solution en deux projets générés par un SolutionGenerator (config/settings.json) :

Engine (bibliothèque statique, SFML 3 en static)
    ├── Entity / EntityManager / EntityFactory
    ├── 37 composants (Transform, Render, Combat, CrewMember, Navire, FogOfWar, TurnOrder…)
    ├── 34 systèmes + SystemManager
    └── Bases de données JSON : actions, effets, objets, butin, stats, tuiles, spawners
Game (exécutable)
    └── 10 scènes : exploration navale, 5 îles, combat terrestre, options…

Points techniques

• Grille hexagonale : directions et voisinage en coordonnées décalées (HexDirection, parité de ligne).
• Ordre des tours : file triée par initiative totale (SystemTurnOrder).
• Cartes : chargement des îles depuis des fichiers JSON (TileMapLoader, nlohmann/json), un fichier de carte et un fichier de spawners par île.
• Données pilotées : actions, effets, objets et tables de butin décrits en JSON et chargés au démarrage.

Stack

Tech	Rôle
C++	Langage
SFML 3.0.0	Rendu, fenêtre, audio
nlohmann/json	Données et cartes
Visual Studio	Build (projets générés)

Les exercices et TP de C++ de l'année 2024-2025 au Gaming Campus, du premier jour d'encapsulation jusqu'à une architecture entité-composant.

Contexte

Une série de petits dépôts, un par exercice ou par TP, sur six mois. Le seul projet de groupe est le casse-brique SFML de novembre 2024.

Ce que j'y ai fait

Les bases de la POO en C++, une machine à états, des scènes sur le moteur LightEngine, des threads, un client et un serveur TCP, une architecture entité-composant, et ma version du casse-brique.

Liens

• Encapsulation-C (bases et encapsulation)
• Exo-Full (exercices de synthèse)
• Exo-C-- (hiérarchie d'entités)
• InventaireExo (inventaire)
• CasseBrique-Final (casse-brique, une branche par membre)
• Tp1-StateWeapon (machine à états)
• Tp2-PvZ (Plants vs Zombies)
• Test-ShootEmUp (shoot'em up)
• ExoThread (threads)
• ExoServClient (client-serveur TCP)
• TestDirectX (architecture entité-composant)

Les travaux

Période	Travail	Contenu
Oct. 2024	Bases et encapsulation	Classes Point, Entity, Player, interface IAlive, héritage
Oct. 2024	Exercices de synthèse	Vector2, Integer, hiérarchie Entity → Mob / Player / BreakableObject, World
Oct. 2024	Inventaire	Inventaire en console avec poids et capacité maximale
Nov. 2024	Casse-brique (groupe de 3)	SFML : briques explosives, bonus et pièges, effets sur la balle et la raquette, niveaux en fichiers, menus, musique
Nov. 2024	TP StateWeapon	Arme pilotée par une machine à états (State : Start / Update / End)
Nov. 2024	TP Plants vs Zombies	Scène PvZ (plantes, zombies) sur le moteur LightEngine (SFML)
Déc. 2024	Shoot'em up	Vaisseau et ennemis sur LightEngine (SFML)
Janv. 2025	Threads	Classe Thread et threads enfants
Janv. 2025	Client-serveur	Serveur et client TCP Winsock (socket, bind, listen, accept), un thread par côté
Févr. 2025	Architecture EC	Entity, Component, Transform, Renderer, puis une passe d'optimisation

Casse-brique

Trois versions (une par membre du groupe) fusionnées dans un même dépôt. La version de ma branche contient trois types de briques spéciales, douze effets de balle (vitesse, taille, perçage, direction aléatoire, invisibilité, multiplication, inversion, téléportation, division…), quatre effets de raquette, un générateur et un gestionnaire de niveaux, un menu principal et un menu pause.

Jeu de plateforme 2D développé en équipe pendant le projet « Mini Studio » de la 1re année (avril 2024).

Contexte

Projet de groupe sur un dépôt partagé, une branche par membre (programmation et art), fusionnées dans la branche principale pour le rendu.

Ce que j'y ai fait

Le déplacement du joueur (saut, plané, course, gravité), la caméra, le fond en parallaxe, les animations du personnage et le ramassage d'objets avec inventaire.

Liens

• JV-Mini_Studio (dépôt de l'équipe)

Structure

carte.py / chapters.py     → menus, carte et choix du niveau
main0.py … main3.py        → les quatre niveaux jouables
editor0.py … editor3.py    → un éditeur de niveau par niveau
level0_data.csv … level3   → niveaux sauvegardés (grille 30 × 150, 21 types de tuiles)
Album0.py … Album4.py      → album photo
Parametre.py               → réglages musique et son

Mes branches

D'après l'historique de mes branches (Kiki_1, Kiki_2) :

• caméra qui suit le joueur et désactivation des objets hors champ ;
• saut, plané, course et gravité, calculés avec le delta time ;
• fond en défilement continu et parallaxe ;
• animations du personnage ;
• ramassage d'objets et stockage en inventaire.

Game Design Document d'un jeu d'aventure-exploration aérienne : dans un monde englouti sous un océan de nuages toxiques, le Voile, l'humanité survit sur des îles flottantes que le joueur parcourt en volant sur un Souffleur.

Contexte

Projet personnel d'avril 2026, au stade de la pré-production : le document de conception est écrit, le pitch deck, le prototype et les visuels sont planifiés. Il fait suite à un premier GDD, « Éolia », écrit le même matin, dont il reprend l'étude de marché.

Ce que j'y ai fait

L'ensemble du GDD (gameplay, monde, level design, direction artistique, son, technique, production), une étude de marché et un dossier sur le cadre légal, et la chaîne de compilation du document.

Liens

• Zephyria
• Éolia (premier GDD)

Le document

GDD v1.0 découpé en 20 parties modulaires (docs/gdd/parts/), compilées en un seul document par un script pandoc :

Partie	Contenu
Design du jeu	Vision et piliers, gameplay central, monde et narration, progression et économie, level design
Production	Interface et UX, direction artistique, design sonore, spécifications techniques, feuille de route
Studio	Modèle économique, analyse de marché, équipe, budget, risques
Cadre	Propriété intellectuelle, conformité réglementaire, annexes

Boucle de gameplay

Micro (30 s – 2 min)   Observer → Choisir une direction → Voler → Découvrir → Interagir
Session (20 – 45 min)  Explorer une zone → Fragments narratifs → Sanctuaire → Nouvelle capacité
Macro (12 – 15 h)      6 régions → Sanctuaires → La vérité → Descendre dans le Voile → Un choix

Fiche

Genre	Aventure-exploration aérienne, 3e personne
Moteur visé	Unreal Engine 5
Direction artistique	Aquarelle cel-shading

Mod Minecraft qui ajoute une couche d'action-RPG complète : classes, compétences, sorts, équipement et donjons.

Contexte

Projet personnel de février 2026, premier mod d'un espace de travail dédié au modding Minecraft (Fabric), avec ses scripts de build.

Ce que j'y ai fait

Le game design du mod puis son implémentation en Java : système de classes et de ressources, arbres de compétences, sorts et effets, équipement, créatures, et génération de donjons avec leur logique de score.

Liens

• GitHub

Classes

Classe	Ressource
Berserker	Rage
Archmage	Mana
Shadow	Combo
Paladin	Holy Power + Mana
Necromancer	Souls
Druid	Essence

Contenu

• Sorts : 109 classes de sorts dans rpg/spell, barre de sorts sur 8 emplacements.
• Arbres de compétences : 3 branches par classe, ultime par branche, parchemin de respécialisation.
• Équipement : armes légendaires liées aux classes, artefacts (anneaux et amulettes), forge dédiée.
• Donjons : générés à partir de modèles de salles, dans une dimension dédiée, avec score, chronomètre et butin selon le rang.
• Créatures : mobs personnalisés et boss avec barre de vie.

Stack

Tech	Version
Minecraft	1.21.4
Fabric Loader	0.18.4
Fabric API	0.119.4
Java	21
Gradle (Loom)	build

Boîte à outils Unity qui regroupe les mécaniques classiques d'un jeu d'horreur à la première personne, prêtes à glisser dans une scène.

Contexte

Projet personnel commencé en novembre 2025.

Ce que j'y ai fait

Une quarantaine de scripts C# rangés par module (déplacement, horreur, caméra, IA, interaction, combat, audio), des générateurs de scènes de démo dans l'éditeur, la documentation et les tutoriels.

Liens

• unity-mechanics-toolkit

Modules

Module	Scripts
Movement	FirstPersonController, Sprint, Crouch, Lean (AZERTY)
Horror	FlashlightSystem (batterie, scintillement), SanitySystem
Camera	CameraShake, HeadBobbing, LookBehind (demi-tour)
AI	AIStateMachine, VisionCone, PatrolBehavior (NavMesh), ChaseBehavior
Interaction	RaycastInteractor, DoorController, ExamineObject, HidingSpot, HighlightSystem
Combat	Health, MeleeWeapon, BlockDodge
Audio	FootstepSystem, HeartbeatAudio
Core	IDamageable, IInteractable, IKillable, IPoolable, GameEvents, extensions, ObjectPool, Singleton

Outils d'éditeur

Cinq générateurs de scènes de démo (Tools > Unity Mechanics Toolkit > Create Demo Scenes) : joueur, ennemi IA, interactions, combat, et une vitrine horreur qui assemble le tout.

Distribution

Package UPM (package.json, assembly definitions), documentation d'architecture et quatre tutoriels (joueur, IA, interaction, combat).

Moteur Entity Component System universel en C++20. Architecture modulaire, réutilisable pour tous types de jeux 2D.

Contexte

Moteur ECS né du Jeu Libre de 2e année (mars à mai 2025), puis extrait et publié comme template réutilisable.

Objectif : créer un moteur réutilisable comme base pour d'autres projets, avec une architecture propre et extensible.

Ce que ça fait

Types de jeux supportés :

• Temps réel : FPS, platformers, action
• Tour par tour : stratégie, tactical RPG
• Grille : roguelikes, puzzles
• Hybride : combinaison des modes

Architecture :

• Entités comme IDs purs
• Components comme données
• Systems pour le comportement
• Découplage total logique/données

Demo : Pirate Space Explorer - jeu complet (30+ Components, 35 Systems) utilisant le moteur, livré dans le repo en exemple.

Liens

• GitHub
• Documentation

Architecture ECS

Architecture pure Entity-Component-System :

Entity (ID)
    │
    ├── Component A (Data)
    ├── Component B (Data)
    └── Component C (Data)
         │
         └── Systems (Behavior)
             ├── Active (continuous)
             ├── Reactive (event-driven)
             └── TurnBased (discrete)

Stack Détaillé

Tech	Version	Rôle
C++	20	Langage core
SFML	2.5+	Rendu 2D
CMake	3.20+	Build system
Patterns	ECS, Factory, Observer	Architecture

Statistiques

• 36 Components modulaires
• 35 Systems découplés
• 8+ Modules : core, transform, graphics, gameplay, inventory, interaction, AI, audio, network

Optimisations Collisions

Spatial hashing O(n) vs O(n²) :

Entités	Brute Force	Spatial Hash	Speedup
125	125,000 checks	1,000 checks	25x
1000	500,000 checks	2,000 checks	250x

Memory Safety

• Smart pointers + RAII
• Memory pooling pour allocations fréquentes
• Thread-safe avec mutexes et atomics