deathstar

Stellar Abyss est un prototype de combat spatial 3D orienté bureau et exécuté via navigateur, construit avec Babylon.js, TypeScript et Vite. Les vaisseaux, l'environnement, l'univers et l'audio sont décrits comme originaux et procéduraux — le README précise explicitement que le projet n'utilise pas de vaisseaux, personnages, logos, musiques ou effets sonores protégés issus de franchises existantes. **Histoire et mise en place** Le jeu s'inscrit dans un cadre original d'opéra spatial : un navigateur exilé de l'Order of the Threshold suit un signal dans la ceinture de Náris, où une force militaire anonyme garde le passage vers le retour. Au lancement, le joueur choisit entre deux vaisseaux, l'Arthur Comet et le Gael Ray. Un vol de reconnaissance dégénère en batailles contre des escadrons de chasseurs et finalement contre l'Obelisk, un grand vaisseau capital. **Commandes et combat** Le vol est dirigé à la souris, la distance par rapport au centre de l'écran contrôlant l'intensité du virage ; ramener la souris au centre permet de voler en ligne droite et le verrouillage du pointeur n'est pas utilisé. Les touches du clavier gèrent la vitesse de croisière (W/S), le roulis (A/D), le déplacement latéral (Q/E), les impulsions laser doubles (clic gauche), le canon plasma après déblocage (clic droit), la rupture d'énergie après déblocage (R), le boost avec recharge (Maj gauche), une esquive avec invulnérabilité brève et un temps de recharge de trois secondes (Espace), la sélection et le cycle des cibles (F, Tab), la pause (Esc), le mode muet (M) et un basculement de diagnostics (F3). Le plasma inflige des dégâts de zone et la rupture d'énergie est une torpille rapide avec un temps de recharge de huit secondes. La mission se met automatiquement en pause lorsque la fenêtre perd le focus. **Structure de la mission** Six étapes progressent de la reconnaissance et l'interception d'éclaireurs, en passant par des patrouilles plus importantes et des chasseurs d'assaut, jusqu'au déblocage du canon plasma, l'affrontement de chasseurs d'élite et le déblocage de la rupture d'énergie, l'élimination des renforts, et enfin le démantèlement du sous-système par sous-système de l'Obelisk — tourelles de défense, générateurs de boucliers, moteurs ioniques et réacteur — suivi d'une réaction en chaîne et de l'achèvement de la mission. **Règles et retours** Les boucliers se régénèrent cinq secondes après avoir subi des dégâts, tandis que l'intégrité de la coque ne se régénère pas. Détruire un chasseur restaure sept points de bouclier. Les astéroïdes et le vaisseau capital causent des dégâts de collision qui ne sont pas instantanément mortels. Une option Test Flight fait avancer le temps de la mission à une vitesse de 4× tout en conservant inchangés les mouvements, les armes, les dégâts et les temps de recharge. **Interface et localisation** Le jeu démarre en anglais et propose un sélecteur EN / PT-BR dans le menu et l'écran de pause, le choix étant conservé dans le navigateur. Les noms propres liés à l'univers restent non traduits. **Exécution et construction** Le développement local nécessite Node.js 22.12+ ou Node.js 24 ; le flux documenté est `npm install` puis `npm run dev`, servant sur `http://127.0.0.1:5173`. L'ajout de `?renderer=webgl&debug` force WebGL2 et active les diagnostics. Un build de production peut être servi avec `npm run build` et `npm run preview`. Un workflow GitHub Actions dans `.github/workflows/deploy.yml` construit et publie `dist/` sur GitHub Pages lors d'un push sur `main`, et le README note que le workflow ne demande que les permissions de lecture, d'écriture Pages et d'identité de déploiement requises par GitHub Pages. **Architecture** Le code est organisé en modules incluant le cœur (moteur, boucle, entrées, assets), le joueur (vol et santé), les ennemis (IA et formations), les armes (projectiles poolés et collision), le monde (environnement spatial), les effets, l'audio, la progression, le boss et l'interface utilisateur. Les constantes de gameplay se trouvent dans `src/config.ts` ; les tests de combat et de progression sont dans `tests/` et un test de fumée navigateur est dans `scripts/`. `AssetManager.ship()` crée des modèles primitifs temporaires, et `AssetManager.loadModel(url, parent)` charge des fichiers glTF/GLB pour un remplacement visuel futur. Les modèles sont orientés vers le +Z local et aucun modèle externe n'est requis pour jouer. WebGPU est tenté en premier avec un repli automatique vers WebGL2. **Vérification** Les vérifications documentées sont `npm test`, `npm run build`, `npm run dev` et `node scripts/browser-smoke.mjs`. Le test de fumée nécessite un serveur local et Chrome, et couvre le démarrage, l'accélération, le boost, la direction pendant le tir, les éliminations réelles, la pause, la reprise, le redémarrage et les erreurs navigateur, en écrivant des captures d'écran vers des chemins temporaires. Le README indique que six tests de logique réussissent et que la validation Chrome/WebGL2 a confirmé le tir, la direction pendant le tir, trois éliminations avec score, la pause, la reprise, le redémarrage et l'absence d'erreurs d'exécution, avec un build de production réussi ; il note également que WebGPU et un playthrough complet du combat contre le vaisseau capital n'ont pas été validés dans cet environnement. **Statut et limitations** Le prototype possède une mission complète avec des états de victoire, de défaite et de redémarrage. Les vaisseaux et l'audio sont décrits comme des substituts procéduraux fonctionnels. Les textures artistiques, les LODs, les commandes tactiles et les commandes de manette ne sont pas encore implémentées, et le bundle principal pèse environ 6,3 Mo, ou 1,38 Mo en gzip, l'optimisation du chargement étant en attente. L'objectif annoncé est de 60 FPS sur un ordinateur de bureau raisonnable, avec WebGL2 comme chemin de diagnostic de référence et des replis locaux pour Google Fonts. Les diagnostics peuvent afficher les FPS, la position, la vitesse, les ennemis actifs, les projectiles, les maillages actifs et le temps de mission. **Contribution** Les contributions sont acceptées via fork-and-pull-request contre `jeffotoni/deathstar` ; le README demande aux contributeurs de ne pas pousser de branches de fonctionnalités vers le dépôt officiel, d'utiliser les Conventional Commits, d'exclure les refactorisations non liées d'une PR, et d'expliquer le résultat visible pour le joueur ainsi que les commandes de validation et une capture d'écran ou un enregistrement pour les changements visuels ou de gameplay. Il recommande également de protéger la branche `main`, de garder les permissions Actions en lecture seule par défaut, d'éviter les secrets dans le code de forks non approuvés, de ne pas commiter d'identifiants ou de sorties de build générées, et de signaler les vulnérabilités en privé selon `SECURITY.md`.