📖 Le Contexte : "Le jeu dans le jeu"
Dans le développement de serveurs GTA V, les interfaces (NUI) sont souvent limitées à du simple DOM (HTML/CSS). Pour PakeTekos, je voulais aller plus loin : intégrer des mini-jeux fluides, réactifs et visuellement riches (vol de cuivre, crochetage, gestion de drogues).
Plutôt que de coder chaque mini-jeu de manière isolée et désorganisée, j'ai développé tk-engine. C'est un moteur de jeu complet qui implémente le pattern ECS (Entity-Component-System) sur une couche de rendu WebGL (PixiJS v8). Il permet de transformer une simple page web en un moteur de rendu capable de gérer des centaines d'objets animés avec une physique réaliste.
🧰 Le Cas Pratique : tk-coppertheft
Pour valider la puissance du moteur, j'ai développé tk-coppertheft, un mini-jeu de vol de câbles de cuivre. Grâce au système de ressorts (SpringSystem) et de secousses (ShakeSystem) du moteur, l'interaction devient tactile et stressante, offrant une immersion bien supérieure à un simple bouton de "clic".
🎯 Mon Rôle : Architecte Moteur
J'ai conçu l'intégralité de la structure TypeScript du moteur, en me concentrant sur la Developer Experience (DX) pour que l'ajout d'un nouveau mini-jeu ne prenne que quelques heures au lieu de plusieurs jours.
1. Architecture ECS "Pure"
J'ai imposé une séparation stricte entre les données (Components) et la logique (Systems). Les entités sont de simples conteneurs d'ID, permettant des recherches en $O(1)$ par type de composant. Cette structure garantit une scalabilité totale et évite les bugs de mutation complexes rencontrés dans les architectures orientées objet classiques.
2. Gestion Différée (Deferred Updates)
Pour éviter les crashs lors de la modification du monde en plein milieu d'une boucle de calcul, j'ai implémenté un système d'ajout/suppression différé : les entités sont mises en file d'attente et traitées uniquement au début de la frame suivante.
🧠 Sous le capot : Physique & Précision
L'un des plus grands défis d'un moteur de jeu web est la gestion de la fluidité, quel que soit le framerate du joueur.
⚙️ Physique indépendante du Framerate
La plupart des développeurs débutants multiplient la vitesse par un facteur fixe (ex: velocity *= 0.98). Sur un écran 144Hz, l'objet ralentit alors beaucoup plus vite que sur un écran 60Hz.
Pour tk-engine, j'ai implémenté une friction basée sur une décroissance exponentielle :
$$frictionFactor = (1 - friction)^{\Delta}$$
Cela garantit que le comportement physique reste identique, que le joueur tourne à 30 ou 165 FPS.
🛠️ Les Systèmes Intégrés
Le moteur embarque nativement des logiques avancées :
| Système | Physique appliquée |
|---|---|
| SpringSystem | Utilise la loi de Hooke ($torque = -k \times (\theta - \theta_)$) pour simuler des aiguilles de compteurs ou des câbles élastiques. |
| ShakeSystem | Gère des secousses cohérentes par groupe d'entités pour simuler des explosions ou des vibrations d'outils. |
| RenderSystem | Synchronise les coordonnées logiques de l'ECS avec le moteur de rendu WebGL de PixiJS. |
🔭 La Vision et la Suite
tk-engine n'est pas une ressource FiveM autonome, c'est une bibliothèque TypeScript consommée par mon système de build tk-ui.
La suite du développement prévoit :
- L'ajout d'un système de particules natif pour les effets visuels (étincelles, fumée).
- Un système de Pathfinding 2D simplifié pour des mini-jeux de stratégie.
- L'optimisation du Spatial Audio pour lier les sons des mini-jeux à la position des entités à l'écran.
Expertise technique : TypeScript, ECS Architecture, PixiJS v8, WebGL, Mathématiques de la physique (Intégration d'Euler, Loi de Hooke).