Les jeux natifs du navigateur gagnent en maturité : ce que révèlent les projets de combat open source

J’ai commencé cette recherche en pensant trouver une poignée d’expériences intéressantes de combat dans le navigateur. À la place, j’ai découvert un écosystème bien plus vaste : de véritables prototypes d’action à la troisième personne avec verrouillage de cible, arborescences de combos, parades parfaites, invulnérabilité pendant l’esquive, systèmes de posture, attaques aériennes, signaux annonçant les attaques des boss, motion warping, hit-stop, chocs physiques entre armes, prise en charge des manettes, commandes tactiles et simulation déterministe.

C’est le résultat important. Il ne s’agit plus seulement de petits jeux qui se trouvent être rendus dans une page web. Certains résolvent les mêmes problèmes d’ingénierie que les jeux d’action traditionnels, mais ils sont distribués sous la forme d’une URL et peuvent être joués immédiatement.

Pour moi, en tant que développeur web, c’est la partie fascinante. L’ancien modèle mental du jeu était dominé par les installateurs, les gros téléchargements, les outils de mise à jour, les lanceurs et le délai entre la découverte d’un jeu et le moment où l’on pouvait réellement y jouer. Le navigateur raccourcit radicalement ce parcours : ouvrir un lien, charger les ressources et commencer à jouer.

Cette recherche s’est concentrée sur des projets disposant d’une version jouable dans le navigateur et d’un code source public. Les exports Unity WebGL ont été volontairement exclus, car je voulais étudier des jeux construits autour des technologies web plutôt que des jeux simplement exportés vers le web.

Les projets les plus solides que j’ai trouvés

Les découvertes les plus utiles n’étaient pas toutes fortes pour la même raison. Certaines avaient les systèmes de combos les plus poussés. D’autres proposaient une meilleure architecture à la troisième personne, une simulation de combat plus propre ou des impacts physiques plus convaincants.

Pourquoi les résultats m’ont surpris

La surprise ne venait pas simplement de la qualité des graphismes. Rendre une scène soignée n’est qu’une partie du développement d’un jeu. Les projets qui se démarquaient implémentaient des systèmes difficiles à simuler de manière convaincante : mise en mémoire tampon des entrées, transitions d’état du combat, sélection de cible, déplacement pendant les attaques, timing des animations, détection des coups, réactions des ennemis, fenêtres défensives, comportement de la caméra et retour d’impact.

Cela fait apparaître une distinction utile :

• le timing de l’animation n’est pas le timing du combat ;
• la fréquence de rendu n’est pas la fréquence de simulation ;
• une collision n’est pas automatiquement un coup valide ;
• l’animation ne fait pas nécessairement autorité sur le mouvement ;
• le contact visuel n’est pas la même chose que l’impact perçu.

Ces distinctions revenaient régulièrement dans les projets les plus solides, et elles comptent davantage que le logo du moteur de rendu dans le README.

Voxel Musou : le combat dans le navigateur peut avoir une véritable grammaire de mouvements

Voxel Musou est l’un des exemples les plus clairs montrant que le combat dans le navigateur ne se résume plus à une animation d’attaque associée à un bouton. Son code source est disponible sur mike007jd/voxel-musou.

Le projet utilise de longues chaînes d’attaques normales et des embranchements sur attaques chargées plutôt qu’un combo purement linéaire. C’est important sur le plan architectural, car le système peut être modélisé ainsi :

current move + buffered input + combat state -> next move

C’est une base bien meilleure pour un jeu d’action centré sur le personnage qu’une collection toujours plus grande de conditions particulières. Le projet montre aussi des attaques aériennes, des séquences spéciales, plusieurs kits de personnages, des comportements de boss, du hit-stop et des combats contre de grands groupes d’ennemis.

La leçon d’ingénierie plus générale est que les mouvements doivent devenir des données et les transitions doivent devenir explicites. Une fois ce principe appliqué, ajouter un autre personnage ne nécessite plus de réécrire tout le contrôleur de combat.

Long Wind : ce qui se rapproche le plus d’un jeu d’action moderne dans le navigateur

Long Wind est l’une des références les plus complètes, car il combine déplacement à la troisième personne, attaques légères et lourdes, verrouillage de cible, garde, parade parfaite, invulnérabilité pendant l’esquive, pression sur la posture, exécutions, réactions de projection et de mise au sol, projectiles, boss et plusieurs archétypes d’ennemis. Le code source est disponible sur jbang2004/long-wind.

Sa valeur ne tient pas au fait que chaque fonctionnalité prise séparément serait sans précédent, mais au fait qu’elles coexistent dans un même prototype d’action natif du navigateur. Cela en fait une référence utile pour suivre toute la chaîne, depuis l’entrée utilisateur jusqu’à la sélection de cible, l’état d’attaque, l’animation, le contact, la réaction, le hit-stop et le retour de la caméra.

Le motion warping résout un problème que les démos web ignorent souvent

Samurai Third-Person Template ThreeJS est particulièrement intéressant parce qu’il s’attaque à un problème classique du combat rapproché à la troisième personne. Son code source est disponible sur achrefelouafi/SamuraiThirdPersonTemplateThreeJS.

Une animation d’attaque conçue à l’avance suppose que la cible se trouvera à une distance précise lorsque le coup atteindra sa frame de contact. Dans un vrai jeu, la cible n’est presque jamais positionnée parfaitement. Si le personnage joue simplement l’animation sur place, l’épée peut visiblement rater la cible alors que le jeu applique tout de même des dégâts. Si le personnage se téléporte à la bonne position, l’attaque paraît artificielle.

Le motion warping apporte une meilleure réponse : ajuster la rotation et la translation pendant l’attaque afin que le personnage atteigne la position de contact attendue au bon moment.

La distinction importante est la suivante :

animation intent != movement authority

Un personnage peut conserver l’intention visuelle d’une animation conçue à l’avance tandis que le contrôleur de gameplay reste l’autorité qui décide de l’endroit où le personnage se déplace réellement.

La détection des collisions et la validation des coups sont deux problèmes différents

Stick & Steel explore un modèle de combat très différent. Son code source est disponible sur Rabneba/stick-steel.

Au lieu de traiter l’épée principalement comme une animation accompagnée d’un volume de dégâts, le projet donne aux armes une présence physique. La vitesse au contact, l’orientation de l’arme, la zone du corps touchée, les gardes, les chocs entre armes, les mises au sol et les désarmements ont tous leur importance.

La leçon la plus transférable n’est pas que chaque jeu d’action devrait utiliser des armes entièrement physiques. C’est plutôt ceci :

Une collision vous indique que deux éléments se sont touchés. Elle ne vous dit pas si un coup significatif a réellement eu lieu.

Un système de combat convaincant a souvent besoin d’une deuxième couche qui décide si le contact avait une vitesse suffisante, la bonne direction, la bonne zone de l’arme, le bon timing et un état de cible valide pour être comptabilisé comme un dégât.

Une résolution centralisée du combat rend les défenses complexes plus faciles à raisonner

Hollowmere, dont le code source se trouve sur euuuuuuan/hollowmere-public, se distingue moins par le spectacle visuel que par son architecture logicielle.

Sa simulation de combat est séparée du rendu, et la résolution défensive est centralisée. Cela évite un mode de défaillance courant dans les jeux d’action, où le système d’esquive, le système de parade, le système de réaction aux coups et la couche d’animation peuvent décider indépendamment de manière contradictoire si une même attaque a touché sa cible.

Un modèle mental plus propre est :

incoming attack -> evade | parry | hit

Le moteur de rendu doit afficher le résultat, pas inventer une deuxième version de la vérité du combat.

Cette distinction devient de plus en plus importante à mesure que le système de combat s’enrichit. La simulation déterministe et les transitions d’état explicites ne sont pas des fonctionnalités spectaculaires, mais elles facilitent les tests, le débogage et l’extension d’un système de combat complexe.

Les sensations de jeu relèvent de l’ingénierie, pas de la décoration

Fabled Revolutions, dont le code source se trouve sur ericrius1/FabledRevolutions, est utile précisément parce qu’il isole les effets qui donnent du poids aux coups.

Un système de combat logiquement correct peut malgré tout sembler faible. La collision peut être précise, les dégâts peuvent être appliqués à la bonne frame, et le résultat peut tout de même donner l’impression que deux modèles se traversent.

L’impact perçu provient souvent d’un empilement d’effets de courte durée :

• hit-stop ;
• secousse ou à-coup de caméra ;
• traînées des armes ;
• particules d’impact ;
• flash visuel de dégâts ;
• recul ;
• réaction d’animation ;
• son bien synchronisé.

Cela suggère une autre distinction utile : la correction du combat n’est pas son ressenti. Un jeu dans le navigateur a besoin des deux.

Le moteur de rendu n’était pas le principal prédicteur de la qualité du combat

L’un des schémas les plus intéressants de cette recherche est que la qualité du meilleur combat ne dépendait pas du fait qu’un projet utilise ou non la toute dernière API de rendu.

Three.js revenait souvent. Certains projets utilisaient des technologies de rendu liées à WebGPU, d’autres des stacks classiques basées sur WebGL. Moteurs physiques, TypeScript, JavaScript, Vite, WebAssembly et différentes approches de rendu étaient tous représentés dans les projets étudiés.

En revanche, la sophistication du combat dépendait plus régulièrement de l’architecture : simulation à pas fixe, états explicites, ciblage fiable, gestion cohérente de l’autorité des animations, mouvements pilotés par les données, résolution centralisée des dégâts et bon retour d’impact.

C’est encourageant pour les développeurs web. Il n’est pas nécessaire d’attendre que chaque utilisateur dispose de la stack graphique la plus récente pour commencer à expérimenter sérieusement le design de combat.

Pourquoi la distribution par navigateur change la donne

Le navigateur possède un avantage qui a peu à voir avec les graphismes : une friction de distribution extrêmement faible.

Les jeux traditionnels placent souvent plusieurs étapes entre la découverte et l’interaction : trouver la page du magasin, télécharger un gros paquet, l’installer, le lancer, attendre les mises à jour et parfois créer un compte avant d’accéder à une expérience de jeu significative.

Un jeu dans le navigateur peut réduire tout ce parcours à un simple lien.

Cela change la manière dont les prototypes peuvent être partagés et testés. Un développeur peut publier une version, envoyer une URL, faire entrer immédiatement une autre personne dans exactement la même version, recueillir ses retours et déployer une nouvelle itération sans lui demander d’installer manuellement un nouveau paquet.

Cet avantage devient particulièrement important pour les jeux expérimentaux et le développement indépendant. Le navigateur n’est pas seulement un environnement d’exécution ; c’est aussi un système de distribution.

Là où le navigateur reste en retrait

Cette recherche ne m’a pas convaincu que les navigateurs avaient remplacé les plateformes de jeu natives. Ce n’est pas le cas.

Plusieurs contraintes restent importantes :

• Ressources volumineuses. L’accès instantané cesse de paraître instantané lorsqu’un jeu exige un très gros téléchargement initial.
• Pression mémoire. Les navigateurs doivent coexister avec d’autres onglets et avec le système d’exploitation, et le comportement de la mémoire est moins prévisible que dans un processus natif dédié.
• Limites thermiques sur mobile. Un jeu 3D techniquement fonctionnel peut tout de même voir ses performances fortement réduites au cours d’une session prolongée.
• Différences entre navigateurs. Les graphismes, l’audio, le verrouillage du pointeur, le comportement en plein écran, les manettes et les caractéristiques de performance ne sont pas parfaitement uniformes.
• Préparation des shaders et des ressources. La compilation ou les transferts peuvent encore provoquer des blocages visibles si le pipeline n’est pas conçu avec soin.
• Contraintes hors ligne et de persistance locale. Les applications natives conservent un contrôle plus direct sur les installations locales volumineuses et les fichiers.
• Sécurité en contexte compétitif. Les mesures anti-triche sérieuses et les hypothèses de client hostile deviennent bien plus difficiles à gérer lorsque le client est une application web.

Ces limites sont importantes parce qu’elles définissent les domaines où les jeux dans le navigateur sont aujourd’hui les plus forts : les jeux qui profitent d’un accès immédiat, d’itérations rapides, d’une diffusion multiplateforme et de budgets maîtrisables pour les ressources et l’exécution.

L’IA raccourcit fortement la boucle entre prototype et URL

L’IA est pertinente ici, mais pas parce qu’elle transforme magiquement une phrase en jeu fini de grande qualité. Son avantage le plus réaliste est la vitesse d’itération.

Le développement de jeux moderne comprend de nombreuses petites tâches qui, cumulées, coûtent cher : mettre en place des machines à états, créer des vues de débogage, écrire des tests, expérimenter avec les comportements des ennemis, créer des formats de données pour les mouvements, refactoriser le code d’entrée, prototyper des shaders, examiner des bugs de physique et connecter du contenu temporaire.

L’IA peut raccourcir beaucoup de ces boucles. Combiné à la distribution web, le flux de travail devient inhabituellement direct :

idea -> prototype -> deploy -> open URL -> test -> iterate

Le navigateur rend déjà le déploiement rapide. L’IA peut également accélérer la partie implémentation de cette même boucle.

La réserve importante est que la génération rapide ne remplace ni le jugement ni la validation. Un contrôleur de combat généré peut être structurellement incorrect. Le timing des animations demande toujours un jugement humain. La physique doit toujours être déboguée. Les performances doivent toujours être mesurées. L’IA réduit le coût nécessaire pour essayer des idées ; elle ne supprime pas la nécessité de décider lesquelles sont bonnes.

Ce que cela signifie pour les développeurs web

La frontière entre développement web et développement de jeux devient moins rigide.

Un jeu sérieux dans le navigateur peut désormais utiliser des outils web familiers tout en exigeant des concepts classiques d’ingénierie du jeu :

• pas de simulation fixes ;
• machines à états ;
• mise en mémoire tampon des entrées ;
• graphes d’animation ;
• requêtes spatiales ;
• physique ;
• budgets par frame ;
• gestion des ressources GPU ;
• timing audio ;
• systèmes déterministes.

Dans le même temps, les développeurs de jeux qui ciblent le navigateur bénéficient de domaines dans lesquels le web excelle déjà : URL, déploiement instantané, diffusion via CDN, mises à jour rapides, télémétrie, systèmes de comptes, interfaces adaptatives et partage sans friction.

Cette recherche a changé ma propre façon de voir les choses. Je ne considère plus principalement les jeux dans le navigateur comme des versions simplifiées de jeux natifs. Je vois le navigateur comme une plateforme de jeu de plus en plus capable, avec un ensemble de points forts différent : distribution immédiate, itérations rapides, capacités 3D de plus en plus sérieuses et immense écosystème de développement déjà existant.

Le web ne devient pas seulement meilleur pour afficher des jeux construits ailleurs. Il devient de plus en plus un endroit où des systèmes de jeu sérieux peuvent être conçus, implémentés, testés, distribués et joués directement.