Battle City 3D : Défense de chars sans fin

1. Objectif du projet Créer Battle City 3D, un jeu de défense de chars jouable dans le navigateur, inspiré du classique Famicom de 1985. Le joueur pilote un char, détruit une vague de 20 ennemis, récupère des ravitaillements et protège le quartier général de l’aigle. Reproduire la version actuelle en 3D avec perspective présentée dans les médias de référence, notamment une campagne à génération procédurale basée sur une seed et 35 niveaux classiques sélectionnables. Préserver les règles d’arcade lisibles tout en donnant une véritable profondeur aux chars, aux murs et au décor. 2. Style visuel Utiliser une PerspectiveCamera Three.js avec un champ de vision de 60 degrés. Par défaut, la vue du champ de bataille se place derrière et au-dessus du joueur, à environ 13 unités du monde et à une élévation de 0,43 radian. Suivre fluidement la position et un point situé devant le char ; ne jamais faire pivoter automatiquement la caméra lorsque le char tourne. Proposer une vue tactique plus élevée, une orbite manuelle par glissement et un zoom à la molette. Utiliser les quatre axes cardinaux de la carte pour les déplacements et les tirs. Après une orbite, associer les touches directionnelles au point cardinal le plus proche par rapport à la caméra ; ne jamais transformer les commandes au clavier en déplacements diagonaux. Orienter immédiatement le châssis dans la direction du tir et ajuster la hauteur des projectiles et des effets de bouche au canon réel de chaque modèle. Utiliser des chars chenillés ancrés au sol, des tourelles métalliques, des briques en terre cuite, des blocs d’acier sombre, de l’eau bleue, une végétation basse et de la glace réfléchissante. Prolonger le sol au-delà de la zone jouable avec des arbres, des bâtiments en ruine et de la brume. Utiliser une lumière directionnelle chaude, des ombres douces, un éclairage ambiant, le tone mapping ACES et des effets de bouche, du recul, des étincelles et des débris rebondissants, le tout avec retenue. La neige modifie la palette du sol et des arbres ; les niveaux industriels privilégient l’acier et les bâtiments en ruine. Encadrer le jeu par une interface de commandement vert olive sombre, avec une action principale jaune chaude, le score, les vies partagées, les icônes des ennemis restants, le nom du niveau et un radar. Placer le grand sélecteur de modèle Tripo 3D / Three.js au-dessus du champ de bataille, en affichant le mode sélectionné et un aperçu rotatif du char. Utiliser un guide de ravitaillement illustré et localisé, ainsi que des indicateurs d’effets temporaires. Garder le terrain de jeu et les commandes tactiles essentielles visibles sur les écrans étroits. 3. Monde et scènes Représenter le champ de bataille par une grille de 26 × 26 cases, avec une demi-largeur de collision du char de 0,72. Placer l’aigle en (13,25), entouré d’une défense en briques destructible en forme de U. Les points d’apparition des joueurs sont (9,25) et (17,25) ; les portes ennemies sont (1,1), (13,1) et (25,1). Proposer deux campagnes : les 35 niveaux classiques avec leurs tableaux de vagues de 20 ennemis, et un générateur infini basé sur une seed, alternant les biomes de prairie, de neige et industriels. Générer des couloirs connectés assez larges pour le châssis complet, avec des passages praticables entre les points d’apparition des joueurs, les portes ennemies et les emplacements des bonus. Ajouter une couverture centrale en acier disposée en quinconce pour empêcher une ligne de tir directe entre les apparitions et l’aigle, tout en conservant l’accès transversal aux rues. Permettre de choisir le biome de départ ou le niveau classique, ainsi que de relancer la génération d’une carte aléatoire. Transmettre à l’étape suivante la seed de la partie, le score, les vies et les améliorations des joueurs encore en vie. Les briques sont destructibles ; les blocs d’acier arrêtent les obus ordinaires et les chars ; l’eau bloque les chars mais laisse passer les obus ; la végétation dissimule les modèles ennemis ; la glace réduit l’adhérence. Garder l’environnement lointain décoratif, séparé des collisions de jeu. 4. Inventaire des assets Utiliser ces emplacements de modèles 3D stables et remplaçables indépendamment. Donner la priorité au joueur, à l’ennemi, au char lourd et à l’aigle, puis aux dix modèles de ravitaillement. Poser chaque asset sur son point le plus bas et normaliser son orientation, son centre et son échelle. Réutiliser des templates au lieu de charger un modèle par ennemi. - player : un char chenillé jaune moutarde, doté d’une tourelle lisible et d’un canon orienté vers l’avant ; utilisé par les chars des joueurs, avec une couleur d’anneau distincte pour le deuxième joueur. - enemy : un char ennemi chenillé compact, réutilisé avec des teintes distinctes pour les variantes basique, rapide et puissante. - heavy : un char blindé visiblement plus lourd, utilisant un maillage distinct de celui de l’ennemi standard, avec quatre segments de blindage visibles au-dessus de celui-ci. - eagle : une statue d’aigle doré métallique sur le piédestal du quartier général. - pickup-star : une étoile dorée d’amélioration à cinq branches. - pickup-helmet : un casque militaire protecteur pour un bouclier temporaire. - pickup-clock : une horloge lisible pour immobiliser les ennemis. - pickup-shovel : une pelle pour renforcer le quartier général. - pickup-life : un char miniature représentant une vie supplémentaire. - pickup-grenade : une grenade à main pour détruire les ennemis actifs. - pickup-ammo : une caisse de munitions pour le tir rapide. - pickup-repair : une boîte à outils de réparation pour restaurer le blindage. - pickup-magnet : un aimant en fer à cheval pour récupérer les bonus à distance. - pickup-boost : une batterie d’énergie pour accélérer temporairement. - environment-building : un immeuble d’habitation en ruine, patiné par les intempéries, Tripo P2.0, budget demandé de 1 800 triangles. - environment-tree : un pin irrégulier au tronc visible, Tripo P2.0, budget demandé de 1 100 triangles. - environment-bush : un arbuste feuillu bas accompagné de touffes d’herbe, Tripo P2.0, budget demandé de 650 triangles. Afficher les ravitaillements sous forme de modèles récupérables en rotation et en suspension, avec des anneaux colorés et des vignettes de guide correspondantes. Générer les bâtiments, les arbres et les buissons répétés à partir d’instances partagées de géométrie et de matériaux. Poser les racines des bâtiments et des arbres sur le sol ; enfouir légèrement la base des arbustes pour les fondre dans le terrain. Ajouter de la neige sur les surfaces orientées vers le haut dans les niveaux enneigés. Garder les murs des cases, l’eau, la glace, les maillages de projectiles, l’interface, les lumières, les particules et les proxies de collision procéduraux. Animer l’eau avec des vagues fluides en espace monde, des normales changeantes et un léger déplacement de surface, continus entre les cases adjacentes. La version Tripo utilise 17 modèles générés ; la version comparative remplace les chars et l’environnement par une géométrie construite par le code, avec les mêmes règles et collisions. Les deux versions sont rendues avec Three.js. 5. Gameplay et feedback Prendre en charge le mode solo et le mode coopératif local à deux joueurs, avec un pool partagé de trois vies. En solo, utiliser WASD ou les touches fléchées et Espace/J pour tirer. En coop, le joueur un utilise WASD et Espace/J ; le joueur deux utilise les flèches et Entrée/0 du pavé numérique. P/Échap met le jeu en pause ; C change de caméra ; 1/2 sélectionne le mode de modèle. Sur les écrans tactiles, permettre de maintenir simultanément un pavé directionnel et un bouton de tir, relâcher les commandes en cas d’annulation du pointeur et rendre accessibles les actions pause, reprendre, étape suivante et réessayer sans défilement. La vitesse du joueur est de 4,2 unités par seconde, ou 6,3 avec le boost. Les ennemis comprennent les types basique, rapide, puissant et lourd ; les chars lourds ont quatre points de vie et survivent aux trois premiers impacts sans bouclier. Détruire un ennemi rapporte respectivement 100, 200, 300 ou 400 points ; récupérer n’importe quel ravitaillement rapporte 500 points. Terminer un niveau après 20 ennemis détruits. Perdre lorsque l’aigle est détruit ou lorsque les vies partagées sont épuisées et qu’aucun joueur ne survit. Proposer une nouvelle tentative immédiate, une progression explicite vers l’étape suivante et un meilleur score enregistré localement. Implémenter les dix ravitaillements : l’étoile améliore le tir sur trois niveaux (obus plus rapides, deux obus simultanés, puis obus capables de détruire l’acier) ; le casque protège pendant 12 secondes ; l’horloge immobilise les ennemis pendant 9 secondes ; la pelle renforce la base pendant 16 secondes ; le mini-char ajoute une vie ; la grenade détruit les ennemis actifs ; les munitions accordent 14 secondes de tir rapide avec jusqu’à quatre obus actifs ; la réparation ajoute deux points de vie, dans la limite de trois ; l’aimant récupère les ravitaillements visibles dans un rayon de cinq unités pendant 20 secondes ; le boost dure 12 secondes. Les modèles de ravitaillement restent 25 secondes et apparaissent à des emplacements accessibles, avec un paquet mélangé pour varier les types. La collecte par aimant doit respecter les obstacles solides. Utiliser des échantillons de style NES collectés pour l’introduction de niveau de 4,333 secondes, les tirs, les déplacements et le ralenti, les impacts sur les briques et l’acier, les explosions des ennemis et des joueurs, l’apparition et la collecte des ravitaillements, la vie supplémentaire, l’impact sur le blindage, la glace, la pause et le game over. Le projet actuel utilise 15 pistes OGG de JustoSenka/BattleCity, commit 3a07004ba8e53baea74ff70d2ecc22b017eb9b20. Préserver leur attribution et la mention de licence du dépôt ; les décrire comme des sons de remake collectés, sans prétendre qu’il s’agit d’une capture matérielle bit à bit. Déverrouiller l’audio après une interaction de l’utilisateur, étalonner le volume des échantillons, proposer un réglage du volume et la sourdine, et synchroniser les sons avec les événements. Ne pas ajouter de musique de combat continue sans rapport. 6. Implémentation technique Utiliser TypeScript, Three.js 0.180.0 et Vite 7, avec un package.json et un fichier de verrouillage isolés. Garder la simulation indépendante du rendu, avec une exécution à 120 Hz. Utiliser des AABB solides pour les châssis, des déplacements séparés par axe, la gestion des limites et la séparation des chars, ainsi que des balayages continus vers le contact le plus proche pour les obus, y compris les collisions dues au mouvement relatif entre obus opposés. Les obus partent du châssis et balaient l’espace vers l’avant afin d’éviter de traverser les murs à bout portant. Ajouter l’accélération et la décélération sur la glace, ainsi que la gravité avec des rebonds amortis pour les débris. Il s’agit d’une physique d’arcade au sol, pas d’un simulateur de suspension. Charger les assets GLB de même origine avec GLTFLoader. Garder les proxies de collision indépendants de la géométrie des assets. Le runtime actuel utilise des attributs quantifiés et des textures WebP (1 024 px pour les véhicules et la base ; 512 px pour les ravitaillements et l’environnement), sans simplification de géométrie ni décodeur WASM. Limiter le chargement à quatre workers, utiliser des URL versionnées par hash et des plages de 256 KiB avec un délai d’expiration de 20 secondes et jusqu’à trois tentatives par plage. Déverrouiller le jeu lorsque les quatre modèles principaux et l’audio sont prêts ; charger les assets de ravitaillement et d’environnement en arrière-plan et ne faire apparaître que les types de ravitaillement dont les modèles sont prêts. Le changement de mode de modèle doit préserver l’état du jeu. Proposer une interface en anglais, chinois simplifié, japonais et coréen. Choisir une langue par défaut à partir de la langue de l’appareil, sauf pour zh-TW, zh-HK, zh-MO et zh-Hant, qui doivent utiliser l’anglais par défaut ; conserver les choix de langue explicites. Prendre en charge le clavier, le pointeur sur ordinateur et le multitouch, et mettre le jeu en pause lorsque la fenêtre perd le focus. Conserver tous les assets, crédits et scripts reproductibles en local dans le projet source, et livrer un répertoire dist statique sans identifiants privés ni dépendance à un backend au runtime. 7. Critères de finalisation Livrer le code source éditable, la provenance des assets et les mentions de licence, un workflow npm de développement et de build, ainsi qu’un aperçu statique jouable. Vérifier la scène Tripo par défaut, la comparaison des modèles, tous les biomes, un char lourd encaissant quatre impacts, chaque effet de ravitaillement, la pause et la reprise, la défaite et la nouvelle tentative, ainsi que la progression des niveaux. Tester 1 000 cartes générées avec une seed pour la connectivité adaptée à la largeur du châssis et la sécurité des apparitions, ainsi que toutes les cartes classiques, le passage à travers les murs, les tirs diagonaux, la séparation des chars, l’inertie sur la glace, les commandes relatives à la caméra selon plusieurs angles de lacet et les changements de mode préservant l’état. Valider l’interface localisée et les commandes tactiles à deux doigts sur écran étroit, sans prétendre à des tests sur appareil physique lorsque seule une émulation a été utilisée. Comparer les images et vidéos de référence avec les images réelles du démarrage et des combats ; confirmer le chargement des 17 modèles et des 15 pistes audio. Publier via le workflow Web Page du CMS existant et vérifier la page publique finale, plutôt que de considérer un enregistrement CMS sauvegardé comme un déploiement terminé.