RetourOrévia
A0-16La télémétrie
Jouer
ACTE 0 · CHAPITRE 16

La télémétrie

Ce jeu se joue au clavier ou à la manette, sur un ordinateur

P pour la pause · O pour charger un scénario

Le jeu ne se charge pas ? Ouvrir le build seul

Ce qui est nouveau

Le jeu raconte ce qui s'y passe : un joueur a démarré, il a mis en pause, il a chargé tel scénario. Sans savoir qui. Et les chiffres seront publiés avec chaque version. Ce chapitre termine l'acte 0 : seize soirées, pas un héros à l'écran, et tout ce qui vient se posera là-dessus.

Ce qui a été fait

Ce qui cloche encore

Le texte qui dit ce qui est mesuré et comment le refuser n'est pas encore sur le site. Il arrive avec la page du site, à l'acte 6. En attendant, cette page le dit.

Comment c'est fait, et pourquoi

Pourquoi mesurer

Un jeu sur le web, on ne voit pas les gens y jouer. Est-ce qu'ils arrivent au bout ? Est-ce qu'ils ferment au bout de dix secondes ? Je ne sais pas. La télémétrie, c'est le jeu qui raconte ce qui s'est passé. La version 0 a été jouée par une poignée de gens, et personne ne sait combien sont allés au-delà du premier pont.

Ce qu'on ne fait pas

Pas de cookie. Pas d'adresse conservée. Pas d'identité. Un numéro au hasard par session, oublié à la fermeture. Je ne saurai jamais que c'est vous. Je saurai qu'un joueur est resté trois minutes. Et ce que je mesure est écrit ici, noir sur blanc.

Le composant et le pont

Deux morceaux. Un composant dans le jeu, qui dit « événement untel ». Et un petit pont vers la page web, qui le transmet. Dans l'éditeur, rien ne part : sinon les chiffres seraient faux dès le premier soir de réglages.

PROMPT
Pose un système Telemetrie.

Où on en est : le build web est produit par construire-web.ps1 et servi par le Docker
du site. Systemes porte Horloge, Sauvegarde, Pupitre. Les scénarios s'appliquent par
l'amorceur et le pupitre. Le projet n'envoie rien nulle part. Une clé de projet PostHog
existe, hébergement européen.

Ce que je veux : un ScriptableObject ReglagesTelemetrie dans Jeu/Reglages avec la clé
de projet, l'adresse de l'hôte européen, et un bool Active. Un composant Telemetrie
sur Systemes dans Demarrage, avec une méthode statique Evenement(nom, propriétés
optionnelles sous forme de paires clé valeur), qui dans un build WebGL appelle un pont
JavaScript, et partout ailleurs écrit l'événement dans la console sans rien envoyer.
Le pont : un fichier .jslib dans Jeu/Plugins/WebGL qui appelle posthog.capture, et un
modèle de page WebGL dans Jeu/WebGLTemplates/Orevia, copie du modèle par défaut, qui
charge le script PostHog avec la clé et l'hôte, sans cookie (persistance en mémoire),
sans enregistrement de session, sans capture automatique des clics, avec un
identifiant anonyme régénéré à chaque session. Les réglages du projet utilisent ce
modèle. Les événements envoyés ce soir : demarrage au lancement avec la version du
build (l'identifiant de chapitre, lu d'un champ de ReglagesTelemetrie rempli par
construire-web.ps1), scenario_applique avec le nom du scénario, et pause avec l'état.
Mets à jour construire-web.ps1 pour écrire l'identifiant de version dans la fiche
avant le build.

Plus tard : mort avec la position et le lieu, point_sur_atteint, enigme_resolue avec
la durée, abandon à la fermeture de la page avec la durée de session, et un tableau de
bord par version ; un texte dans la page du site dira ce qui est mesuré et comment le
refuser.

Ce que je ne veux pas : aucune donnée personnelle, pas d'adresse IP conservée (régler
le projet PostHog en conséquence, et le dire dans la page), pas d'événement dans
l'éditeur, pas d'envoi si Active est faux.

Quand c'est fait, montre-moi le composant, le modèle de page, et lance le jeu dans
l'éditeur pour que je voie les événements dans la console.

Les tests

PROMPT
Ajoute un test EditMode : avec Active à faux, Evenement n'appelle pas le pont et
n'écrit rien ; et un test que ReglagesTelemetrie a une clé et un hôte non vides.
Lance verifier, puis commit avec le message « La télémétrie ». Montre-moi le résumé
et le journal git.

Le build qui restait gris

Premier build web depuis le chapitre 3, et l'écran reste gris après la barre de chargement. Le jeu tourne pourtant : la console du navigateur montre l'événement de démarrage. Le problème est ailleurs. Le build ouvre d'abord la scène Démarrage, qui ne porte que les systèmes, sans décor ni caméra. Le bac à sable n'est jamais chargé. Dans l'éditeur, on ne le voyait pas : on appuie toujours sur Play depuis le bac à sable. Et le pupitre, la touche F1, n'existe pas dans un build public : c'était voulu au chapitre 13. La correction tient en un prompt : le bac à sable passe en premier, et l'amorceur ajoute Démarrage à côté, comme dans l'éditeur.

PROMPT
Où on en est : le build web de A0-16 se construit et démarre, la console du
navigateur montre l'événement demarrage, mais l'écran reste gris. Les scènes du build
sont Demarrage puis Etabli, dans cet ordre. Demarrage ne porte que Systemes, sans
caméra ni décor. L'Amorceur charge Demarrage en additif quand il manque, dans l'éditeur
comme dans le build. Le Pupitre se détruit dans un build qui n'est pas de développement,
donc F1 n'y fait rien.

Ce que je veux : dans les réglages de build, mets Etabli en premier et Demarrage en
second, et fais en sorte que Construction.Web garde cet ordre : la première scène du
build est celle qu'on montre, l'Amorceur ajoute Demarrage. Vérifie dans le code de
l'Amorceur que Demarrage n'est jamais chargée deux fois. Ajoute un test EditMode : la
première scène cochée des réglages de build n'est pas Demarrage. Puis relance verifier.

Plus tard : le menu titre deviendra la première scène du build, et un niveau choisi
s'ouvrira depuis lui ; l'Amorceur ne changera pas.

Ce que je ne veux pas : pas de pupitre dans le build public, pas de build de
développement, pas de caméra ajoutée dans Demarrage.

Quand c'est fait, montre-moi l'ordre des scènes et le résumé de verifier. Je relancerai
le build moi-même, Unity fermé.

Comment on vérifie

Le vrai test, c'est le build web. On le construit, on l'ouvre sur le site : le cube tourne sur son chemin. On met en pause, on relance. Dans PostHog, en direct, les événements arrivent : démarrage avec la version, puis pause, deux fois. À quelques secondes d'écart. Et personne n'est nommé. Le scénario appliqué ne part pas du build public, puisqu'il n'a pas de pupitre : on le voit dans la console de l'éditeur.

Ce qui a mordu

Sources