Contexte de Recherche : Fournaise Rush 974
Fournaise Rush 974 n'est pas un produit commercial finalisé, mais plutôt un bac à sable technique (Sandbox). Développé sur mon temps libre, ce projet R&D a pour objectif principal d'éprouver les limites des moteurs de rendu 2D et 3D au sein de l'écosystème web moderne, en évaluant particulièrement les problématiques de boucle de rendu, de physique, et d'optimisation (draw calls, memory leaks) directement dans le navigateur.
Objectifs Techniques de l'Expérimentation
- Intégration Framework : Évaluer l'interopérabilité des moteurs de jeu avec Next.js et React.
- Performances Mobiles : Maintenir un framerate stable (60 FPS) sur des appareils non-dédiés au gaming avec une utilisation intensive du WebGL.
- Architecture : Construire une logique agnostique séparant le rendu graphique (2D vs 3D) des mécaniques d'état internes.
Jouez à Fournaise Rush 974 (V1 - Prototype 2D)
La Phase 1 a consisté à éprouver un moteur de jeu 2D pur. Phaser 3 s'est imposé par sa maturité et son adaptation au WebGL. L'objectif était de tester la gestion de la physique Arcade en temps réel, couplée à un système d'interface utilisateur (UI/HUD) propulsé par React, tout en veillant à la communication bidirectionnelle entre le state manager React et le cycle update de Phaser.
Ouvrez ce prototype ci-dessous. Même s'il présente encore des comportements imprévus, il illustre les premières itérations sur l'optimisation des sprites et du pooling.
Phase 2 : Le saut architectural vers la 3D (V2)
Insatisfait par les limitations de perspective de la 2D, l'expérimentation a basculé vers un environnement en trois dimensions généré de manière procédurale.
Le socle technique s'est naturellement orienté vers Three.js via le wrapper React Three Fiber (R3F). Contrairement à la V1, R3F offre la possibilité de déclarer la scène 3D sous forme de composants React interactifs, redéfinissant complètement l'architecture du projet :
1. Indépendance de la boucle de physique (Delta Time)
Sur un moteur 3D web, la fréquence de rafraîchissement dépend de l'écran du client (60Hz, 144Hz...). Une gestion naïve de la vitesse rendrait le jeu obsolète sur un écran à haut taux de rafraîchissement. La V2 utilise un calcul de mouvement basé sur le useFrame et le delta time, garantissant des dégradations exponentielles de mouvement isochrones.
2. Gestion mémoire et InstancedMesh
La génération continue d'obstacles dans un couloir infini provoque rapidement des fuites mémoires et des saturations du CPU via le Garbage Collector (GC). L'utilisation des InstancedMesh au détriment de milliers de Mesh unitaires a permis de réduire drastiquement les requêtes de rendu (Draw Calls).
3. Shaders Personnalisés
Pour simuler la lave incandescente sans surcharger le processeur avec de la physique de particules complexe, la R&D s'est tournée vers le langage GLSL. Des Vertex et Fragment Shaders personnalisés à base de Perlin Noise créent cette illusion de mouvement directement sur la carte graphique (GPU).
Testez ci-dessous la V2 (en cours de développement) qui met en évidence l'apport massif du WebGL en contexte React.
Pistes d'Amélioration & Futur de l'Expérimentation
En l'état, de nombreux défis restent ouverts, et c'est tout l'intérêt de la R&D. La gestion avancée des collisions spatiales (AABB) demande des optimisations mathématiques pour ne pas verrouiller le main thread. À l'avenir, le projet pourrait bénéficier de technologies comme WebWorker pour déléguer les calculs physiques brutaux, ou l'intégration de WebAssembly (WASM) pour réécrire les parties critiques en Rust ou C++.