# Geek Mind — choix techniques, version 3

12 octobre 2026

## La bonne base pour ce jeu

Geek Mind présente une capture, recueille une réponse et gère un chronomètre. Le moteur reste en JavaScript natif, en modules indépendants, sans framework d’interface ni moteur 3D. Cette architecture évite un téléchargement et une phase d’initialisation supplémentaires. Les règles de score sont indépendantes du DOM et testables.

Le DOM et CSS conviennent à cette interface composée de texte, boutons, images et quelques animations. Un moteur Canvas/WebGL comme Phaser deviendrait intéressant si l’on ajoutait de nombreuses entités animées, des particules complexes ou une scène interactive. Ce n’est pas nécessaire pour la version actuelle. Passer à React, Unity ou Electron ne corrigerait pas automatiquement ses temps de chargement.

La PWA conserve une installation et un cache hors ligne. Son affichage vise une fenêtre de jeu autonome. Une distribution Android/iOS avec emballage natif pourra être étudiée ensuite ; elle ne constitue pas une optimisation de vitesse en elle-même. Aucun installateur natif n’est livré dans cette version.

## Problèmes observés et changements

- Le MP3 du shuffle dure 2,652 s (mesure ffprobe), contre une animation programmée à 2 s en classique : un décalage structurel de 652 ms. Le nouveau tirage utilise la fin réelle d’un AudioBufferSourceNode. Le même événement termine les images et révèle la capture ; aucune temporisation indépendante ne révèle prématurément le jeu. En arcade et entraînement, le son est accéléré à 1,7× et sa fin reste le déclencheur. Si le son est indisponible ou coupé avant le tirage, une durée de remplacement est utilisée.
- Le shuffle conserve ses miniatures dans des éléments image décodés avant le démarrage du son : aucune source n’est remplacée pendant le tirage. Deux captures sont superposées à chaque transition, avec un fondu de 35 ms et un changement toutes les 90 ms. Seules les miniatures légères servent au défilement. Une réussite reste visible 2,1 secondes, chrono en pause, avant le tirage suivant. L’annulation d’une partie arrête son audio et ses animations ; un ancien événement ne peut pas modifier la partie suivante.
- Les captures sont décodées avec Image.decode() avant leur affichage. Trois images à venir sont préparées, au lieu de seize. Les douze miniatures du shuffle représentent environ 60 Ko au total et ne sont téléchargées qu’au lancement de la première partie.
- Le catalogue utile au jeu passe de 398 882 à 210 795 octets bruts. Les données documentaires complètes et les fiches sont chargées à la demande. Ces chiffres sont des tailles de fichiers, pas des temps de chargement mesurés chez le joueur.
- Les sons ne sont plus tous préchargés sur l’accueil. La bande-son reste optionnelle. Les buffers des effets sont réutilisés une fois décodés.
- Le chrono réutilise son texte, au lieu de reconstruire ses éléments DOM dix fois par seconde. Les images de bibliothèque sont chargées progressivement.
- Les polices sont locales, limitées aux caractères nécessaires aux langues latines ; aucun appel à Google Fonts pendant l’utilisation.
- Le jeu utilise une grille dont la zone d’image peut se réduire, une hauteur dynamique de viewport et des variantes pour mobile et écran bas. La capture reste intégralement visible avec object-fit: contain. Le mode plein écran utilise l’API native, avec un mode immersif de repli si elle est refusée.
- Les préférences de réduction des mouvements désactivent les rebonds et le texte animé, et ralentissent les changements du shuffle.

## Fiches et données personnelles

Chaque capture est reliée à une fiche du jeu ou de l’édition identifiée. Les fiches contiennent leurs liens de sources. Les dates peuvent varier selon la région, la machine et les rééditions ; les champs incertains sont signalés, pas remplacés par une précision inventée. La frise 1972–2026 représente l’horizon du catalogue, et ne promet pas un jeu pour chaque année.

Les corrections sont enregistrées localement dans IndexedDB. Une modification de fiche est appliquée aux captures associées à la même édition, dans une transaction. Renommer le titre exact de la fiche permet de la dissocier. Les exports JSON emportent les fiches personnelles ; les imports valident les champs et les URL. Les scores restent en localStorage et conservent leur classement lorsque seul l’habillage change. Il n’existe pas encore de synchronisation entre appareils ni de classement serveur.

## Vérifications et limites

Tests automatisés des règles, des banques, des imports, du shuffle piloté par l’audio, de son annulation et du contrôleur plein écran. Vérification des fichiers référencés et de la syntaxe JavaScript.

L’environnement de réalisation ne dispose pas du navigateur de test prévu par Sites. Le rendu visuel, l’écoute de la synchronisation et les débordements sur appareils réels n’ont donc pas été validés ici. Aucun score Lighthouse, temps LCP ou taux de rafraîchissement réel n’est revendiqué. Les sorties Bluetooth et certains systèmes audio ajoutent une latence physique : une horloge commune élimine le décalage logiciel programmé, pas toute latence de matériel.

Le prochain contrôle utile est une mesure sur le PC et le téléphone utilisés pour les animations : premier chargement sans cache, seconde partie avec cache, mémoire après 20 minutes, audio filaire/Bluetooth, plein écran en portrait/paysage et clavier tactile ouvert. Un objectif raisonnable est une interface réactive sans attente réseau pendant la révélation. Affirmer que l’application est « au maximum » sans ces mesures serait injustifié.

## Références techniques

- MDN, AudioScheduledSourceNode et événement ended : https://developer.mozilla.org/en-US/docs/Web/API/AudioScheduledSourceNode
- MDN, Image.decode() : https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/decode
- web.dev, optimisation du LCP et des ressources critiques : https://web.dev/articles/optimize-lcp
- MDN, performances des animations : https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/CSS_JavaScript_animation_performance