Faire tourner le véritable moteur de jeu dans le navigateur

Mise à jour, 3 octobre 2026 : la démo décrite ici n’existe plus, et la raison vaut mieux que l’article. Tout ce qui suit est un récit véridique d’un vrai travail d’ingénierie — le module de règles de ZUPI avait bien été intégré sans modification, son empreinte était bien vérifiée à chaque compilation, et le plateau était bien le niveau 1 tel que l’application le génère. Puis l’application a changé. ZUPI: Pulse Shield est sorti le 30 septembre 2026 et c’est un autre jeu : le module célébré ici est devenu celui du jeu précédent. Le contrôle qui gardait cette affirmation ne pouvait prouver que la correspondance entre la copie et le dépôt, jamais que le dépôt était encore ce que les gens téléchargent. /try/zupi est aujourd’hui une reconstitution honnête. L’argument ci-dessous tient toujours pour Glow Garden et Veyra ; ce qui lui manquait, c’est qu’une copie intégrée demande que sa source soit ré-identifiée, et pas seulement ré-empreintée.

Tout site de studio de produit affronte le même problème : une capture d’écran ne peut pas vous montrer la sensation que procure quelque chose, et la sensation est l’essentiel de ce qu’est un jeu. La réponse habituelle est une reconstitution — une version navigateur simplifiée qui approche le produit d’assez près pour être indicative. Nous pensons que c’est la plus mauvaise option disponible. Elle coûte un vrai travail d’ingénierie, elle dérive de l’application dès que l’une ou l’autre change, et ce que joue un visiteur n’est, par construction, pas la chose elle-même.

ZUPI nous a permis d’éviter ce choix entièrement, pour des raisons qui n’avaient rien à voir avec le marketing.

La frontière était déjà là

Les règles de ZUPI vivent dans un unique module autonome, sans dépendance d’exécution tierce. Il possède la physique, la gestion des collisions, la génération de niveaux, la courbe de difficulté, le score et la règle des trois secondes d’immobilité. Il ne sait pas ce qu’est un canvas. Il expose une classe que l’on construit avec un numéro de niveau et que l’on fait avancer avec un delta de temps, et il vous dit où se trouve tout.

Cette frontière n’a pas été tracée pour le web. Elle a été tracée pour que le jeu puisse être testé sans moteur de rendu et pour que les mêmes règles puissent soutenir une version Android et une version iOS sans être écrites deux fois. Il se trouve simplement qu’un module pilotable par un harnais de test est aussi pilotable par un navigateur.

Ce que nous avons réellement fait

• Intégré le module de règles sans modification, avec sa provenance consignée à côté. Ni portage, ni réécriture — le même fichier.
• Écrit un moteur de rendu pour le web dans le langage visuel propre à NOVEMADE, plutôt que de copier l’interface de l’application.
• Piloté le tout depuis une boucle à pas de temps fixe, afin que la simulation avance de façon identique quelle que soit la fréquence de rafraîchissement de l’écran.
• Laissé la génération de niveaux complètement tranquille, de sorte que le plateau est le niveau 1 tel que l’application le génère.

Le dernier point est celui qui compte. Les niveaux dérivent d’une graine déterministe par niveau : ce n’est donc pas un plateau qui ressemble au niveau 1 — c’est le niveau 1. Le terminer ici signifie la même chose que le terminer dans l’application.

L’honnêteté comme problème d’interface

Parce que « le véritable moteur » et « une reconstitution » sont des affirmations réellement différentes, notre catalogue de démos porte une déclaration de fidélité sur chaque entrée, et c’est un champ obligatoire du modèle de contenu, non un agrément. Les démos qui n’existent pas encore disent ce qu’elles seront quand elles existeront — y compris que celle de Didi devra être une reconstitution, parce que sa logique est liée à sa couche d’interface native et qu’il n’y a pas de frontière de moteur à exposer.

Ce qu’il faut en retenir

La leçon réutilisable ne porte pas sur les démos web. Elle porte sur le fait que « quelqu’un d’autre pourrait-il piloter ceci sans notre interface ? » est une question qui mérite d’être posée pendant qu’un produit se construit, et non après. Quand la réponse est oui, on obtient la testabilité, la portabilité et — il se trouve — une démo qu’on n’a pas eu à construire deux fois.