OpenFront — Vision de replays avec positionnement (v0.35.0) : l'activer, sauter à n'importe quel moment, réviser sans tout revoir

Réponse directe : activez « New Replay Viewer » dans les réglages, puis ouvrez une partie finie pour y naviguer

La release v0.35.0 a remplacé le replay linéaire qu’on regardait depuis le début par un visionneur avec positionnement, et il est expédié en option : avec le réglage désactivé, « Watch replay » ouvre toujours le replay classique, et la seule porte de sortie est l’option New Replay Viewer du menu des réglages (elle lit settings.replayViewer, désactivée par défaut). Une fois activée, chaque partie finie que vous ouvrez depuis l’historique entre dans le visionneur. Le principe : le visionneur traite l’enregistrement archivé de la partie une seule fois, dans votre navigateur, sur le worker du moteur lui-même — le même worker que les parties en direct — et après ce passage unique, chaque saut sur la barre temporelle ne coûte qu’environ 20 ms, parce que toute la partie est déjà décodée et en mémoire locale. Les commandes clavier sont volontairement minuscules : Espace joue ou met en pause, les flèches avancent ou reculent d’une frame, et maintenir Maj saute de 100 frames. Le menu de vitesse propose 0,5x, 1x, 2x, 4x, 8x, 16x et 32x. Il existe aussi une forme de lien direct, #replay-viewer=<gameID>, qui ouvre le visionneur même quand l’option est désactivée — c’est ainsi que vous pouvez partager un lien qui atterrit directement dans la vue avec positionnement. Rien ne se passe sur le serveur ; le serveur ne fournit que l’enregistrement archivé. Si vous ne retenez qu’un seul geste : activez l’option une fois, ouvrez une longue partie finie depuis votre historique, et laissez le passage de traitement s’achever avant de juger — la première ouverture est lente par conception, et chaque ouverture suivante de la même partie sur la même machine est quasi instantanée, car le replay traité est stocké dans IndexedDB. Une attente honnête : le visionneur est un instrument de révision, pas une nouvelle façon de specter des parties en direct. Il ne fonctionne que sur des parties finies, il ajoute une étape de traitement absente de l’ancien chemin, et il demande de la vraie mémoire à votre navigateur — le magasin plafonne l’archive décodée à 256 Mo pour protéger les machines modestes, et une partie très volumineuse qui dépasserait son budget pratique tout simplement ne se décodera pas dans une session où la machine est déjà chargée. Autrement dit, vous ne gagnez pas le positionnement gratuitement : en échange vous acceptez une passe de traitement unique par partie et par machine, et c’est exactement le troc que le reste de cette page détaille — un coût payé une fois au début, puis une liberté de navigation qui rend des heures de relecture linéaire en quelques minutes ciblées.

Frontière de version : ce que v0.35.0 a changé, ce qu’il n’a pas changé, et où le visionneur s’arrête encore

Avant v0.35.0, une partie finie ne pouvait être rouverte qu’en rejouant le chemin de replay en direct : vous rejoigniez la partie terminée par URL ou depuis le lobby, et le client la rejouait en temps réel comme si vous l’aviez regardée en direct. Trois limites structurelles en découlaient. D’abord, c’était linéaire — impossible de sauter à la quarantième minute d’une partie de quatre-vingt-dix sans traverser les quarante premières. Ensuite, aucune commande de vitesse ; le replay suivait le rythme de la simulation. Enfin, aucun contrôle d’intégrité ; vous faisiez confiance à l’enregistrement tel quel. v0.35.0 a changé les trois points : l’enregistrement est maintenant traité en frames encodées, la barre est entièrement navigable, le menu de vitesse va de 0,5x à 32x, et le passage de traitement vérifie les points de contrôle de hachage que les clients en direct avaient enregistrés, en s’arrêtant au premier écart. La release a aussi réduit le worker de replay de 815 Ko à 340 Ko en déplaçant le traitement sur le worker du moteur. Ce que v0.35.0 n’a pas changé, c’est la frontière de détermination : la simulation centrale n’est déterministe qu’à l’intérieur d’un même build, donc un enregistrement ne rejoue intégralement que sur le build qui l’a produit. Un enregistrement d’un autre build est routé vers la coquille de version de ce build à replay.<domaine>/<gameID>, exactement comme le mécanisme de versionnage de replay v0.33.6 décrit dans le journal des versions. En pratique : sur le site principal, une partie très ancienne peut encore s’ouvrir (par la coquille ou une copie stockée), mais dès que le build de l’enregistrement n’existe plus nulle part, la partie est perdue — le visionneur ne ressuscite pas les enregistrements, il rend simplement bien plus agréables ceux qui restent disponibles. Le comportement « Catching up… » pendant le jeu en direct est une tout autre affaire : c’est la simulation déterministe qui rattrape le flux d’actions du serveur après un lag, ce n’est pas une fonction de replay, et le visionneur n’y touche pas. Toutes les valeurs de contrôle de cette page — le plafond de 256 Mo, le taux de 10 ticks/seconde, la liste des vitesses, les pas de ±1/±100 frames — sont lues dans la source de la balise v0.35.2, qui est la même source de replay que v0.35.0 à de petites corrections près : les journaux v0.35.1 et v0.35.2 ne modifient aucun comportement de replay, donc les commandes décrites ici restent valides sur toute la série.

Cadre de décision : quand le visionneur paie et quand le replay classique suffit encore

La première décision est simple : si vous reregardez régulièrement des parties pour trouver l’instant où une décision a déraillé, le visionneur paie immédiatement, parce que la partie la plus coûteuse de l’ancien processus — attendre les passages que vous connaissez déjà — est supprimée. Le visionneur est fait pour la question exacte que la communauté relancait en 2025 : « peut-on sauter à l’instant voulu ? ». La deuxième décision porte sur le moment d’ouvrir un replay, pas sur le oui ou non. Le traitement se fait une fois par partie, par machine, par build : la première ouverture d’une longue partie coûte un passage de traitement — environ 70 secondes pour une partie de 26 minutes à 25 joueurs selon le benchmark documenté, et ce passage se passe sur votre machine, pas dans un data center — tandis que chaque ouverture suivante est un tir du cache qui charge les frames stockées depuis IndexedDB et s’ouvre quasi instantanément. Le processus rationnel est donc de traiter une partie une fois sur la meilleure machine disponible, puis de naviguer librement depuis n’importe où, y compris depuis un téléphone, où le replay stocké se charge sans re-traitement. La troisième décision porte sur le budget de stockage. Le magasin plafonne à 256 Mo au total sur tous les replays stockés, en évacuant d’abord le moins récemment visionné ; la partie du benchmark pesait environ 24 Mo, donc le plafond tient de l’ordre d’une douzaine de longues parties, et au-delà, les entrées anciennes disparaissent silencieusement au fur et à mesure que vous en regardez de nouvelles. Si vous ne révisez que quelques parties par semaine, le plafond ne vous mordra jamais ; si vous traitez chaque match comme matériau de révision, attendez que vos replays stockés les plus anciens vieillissent et soient re-traités à votre retour. La quatrième décision porte sur ce que vous n’avez pas à faire : pas besoin d’enregistrer des fichiers, d’exporter quoi que ce soit, ni de garder l’onglet ouvert — le stockage est automatique dès qu’un replay a fini de se traiter, et un replay qui n’arrive jamais à fin de traitement (par exemple un enregistrement coupé par un écart de hachage) n’est simplement pas conservé. Le replay classique reste l’outil juste dans exactement deux cas : quand vous voulez le chemin minimal et léger en dépendances sur une machine modeste (il ne lance pas le passage de vérification), et quand vous regardez une partie très ancienne dont l’enregistrement cessera bientôt d’être hébergée (le chemin classique peut l’ouvrir par la coquille avec moins de pièces en mouvement). Dans tous les autres cas, le visionneur est strictement meilleur pour réviser.

Scénario un : l’FFA à 25 joueurs de 3 heures — trouver une trahison sans revoir trois heures

Partez de la situation décrite par le fil de discussion de la communauté en novembre 2025 : une longue FFA à forte densité de joueurs, qui a dépassé largement deux heures, avec un effondrement en fin de partie que vous suspectez de venir d’un allié précis qui a trahi. Avec le replay classique, votre coût de révision est la durée complète de la partie à 1x — environ trois heures de temps réel, ou beaucoup de patience sans aucune commande de vitesse. Avec le visionneur, le calcul change. Ouvrez la partie finie depuis votre historique ; le visionneur récupère l’enregistrement archivé et lance le passage de traitement sur le worker du moteur. Pour une partie de cette longueur et densité, le passage de traitement prend de l’ordre d’une à deux minutes sur une machine récente, en partant des 70 secondes documentées pour une partie de 26 minutes à 25 joueurs ; pendant le traitement, la queue non traitée de la barre apparaît en gris, et y naviguer fait reculer — donc ne tentez pas de sauter plus loin avant la fin du passage. Une fois le traitement achevé, toute la barre est vivante. Vous travaillez depuis la fin : réglez la vitesse à 16x ou 32x et balayez à rebours depuis la fin, en suivant le territoire et les effectifs à un dixième du coût, jusqu’à ce que la fenêtre de l’effondrement apparaisse ; redescendez à 1x pour les échanges décisifs ; utilisez la barre Espace pour figer une frame en lisant un effectif ou un drapeau, et Maj+flèche gauche pour reculer de 100 frames — dix ticks au taux de 10 ticks par seconde — quand un pas unique manque le moment. Le replay stocké d’une partie de cette taille atterrit quelque part dans les dizaines de Mo, bien dans le budget de 256 Mo ; les chiffres précis dépendent de la carte, de la durée et de la densité d’événements, mais le benchmark donne l’échelle : les parties longues et denses coûtent du vrai stockage, les courtes presque rien. La question de révision que vous pouvez désormais poser et que vous ne pouviez pas poser à bon prix auparavant est causale — quelle décision, prise à quelle minute, a produit l’effondrement — et la réponse arrive en minutes au lieu d’heures. C’est tout le produit en un seul processus : traiter une fois, balayer vite, zoomer lentement, vérifier la frame précise — et c’est exactement la différence entre une rétrospective que vous n’avez jamais trouvée le temps de faire et une que vous feriez chaque semaine.

Scénario deux : la seconde passe sur mobile — traiter sur ordinateur, naviguer au téléphone le matin suivant

Le deuxième scénario casse le vieux schéma de la douleur verrouillée par la version, qui était exactement ce que le fil de discussion de novembre 2025 décrivait : une partie enregistrée un jour, puis in visionnable la veille au lendemain parce que le site avait changé. Vous terminez une match d’équipe compétitif sur votre ordinateur la veille, visionneur activé, et vous l’ouvrez une fois pour que le passage de traitement s’achève et que le replay atterrisse dans IndexedDB sur cette machine. Le lendemain matin vous êtes sur un téléphone et voulez vérifier un franchissement. Si le build de l’enregistrement est encore l’actuel, l’ouverture sur openfront.io depuis le téléphone lance son propre passage de traitement — le stockage IndexedDB est par appareil, le cache de l’ordinateur ne vous suit pas — puis le positionnement est disponible ; sur téléphone, le passage de traitement d’une match d’équipe typique est court mais réel, donc ouvrez une fois et laissez-le finir avant de naviguer. La frontière de version fait alors son travail : si une mise à jour du site est passée pendant la nuit et que le build de l’enregistrement n’est plus l’actuel, le site principal route l’enregistrement vers sa coquille de version, et la coquille préserve le vieux build pour que le replay s’ouvre toujours avec les vieilles règles — le même mécanisme que le fil de novembre 2025 a découvert sur blue.openfront.io, généralisé à replay.<domaine>. La règle pratique : pour une match que vous savez vouloir le matin suivant, ouvrez-la sur votre meilleure machine la même nuit, avant qu’aucune mise à jour puisse atterrir, et l’enregistrement est fixé à un build dont vous savez qu’il existe. Si la mise à jour est déjà passée, vérifiez que la coquille héberge encore le build — les builds très anciens cessent d’être hébergés un jour, auquel point aucun client, neuf ou vieux, ne peut traiter l’enregistrement et la match est irrécupérable. Traitez la coquille de version comme une période de grâce, pas comme un coffre. Une limite propre à ce scénario : le passage de vérification contrôle les hachages enregistrés par les clients en direct, au rythme d’un point de contrôle tous les 10 tours en multijoueur, donc un replay multijoueur est contrôlé denses ; si l’enregistrement arrive sans ses hachages, le visionneur le signale à l’écran et le replay est marqué non vérifié — donc si vous révisez une partie d’équipe que vous avez enregistré vous-même, notez la version du site dans vos notes de partie : c’est la seule information qui permet plus tard de savoir si l’enregistrement est encore vérifiable et si la partie restera contrôlée par hachage.

Modes d’échec et contre-mesures : ce qui casse, et quoi faire

Le premier mode d’échec est l’écart de build, et c’est la raison la plus fréquente pour laquelle un replay « ne marche pas ». Un enregistrement ne rejoue intégralement que sur le build qui l’a produit ; le visionneur vérifie cela avant de faire le travail lourd et vous renvoie vers la coquille de version pour les autres builds. Contre-mesure : comprendre que « le replay s’est arrêté ou redirigé » est presque toujours un problème de version, pas une partie corrompue. Sur le site principal, si le build de l’enregistrement est hébergé, la coquille l’ouvre ; si le build a disparu de l’hébergement, rien du côté client ne le récupère, donc la seule contre-mesure est amont — ouvrez et traitez le replay tant que son build est encore hébergé, et si vous êtes le joueur qui archive ses parties, notez le build dans le contexte du lien partagé. Le deuxième mode d’échec est l’écart de hachage en cours de traitement, qui veut dire que l’enregistrement récupéré n’est pas bit à bit ce que les clients en direct ont vérifié. Le passage de traitement s’arrête au premier écart, et par construction tout ce que le visionneur vous a déjà envoyé reste la vraie partie — les frames ne sont livrées qu’une fois qu’un point de contrôle suivant a matché — donc le résultat visible est que la barre se termine en avance ou qu’un saut recule, et le visionneur vous dit que le replay a été signalé. Contre-mesure : ne traitez pas une barre tronquée comme un bug d’affichage ; c’est le contrôle d’intégrité qui fait son travail. Si un enregistrement censé être propre échoue encore, récupérez-le à nouveau ; l’enregistrement serveur est la source de vérité et un glitch de récupération transitoire est plus probable qu’un moteur cassé. Le troisième mode d’échec est la pression de stockage : le plafond de 256 Mo avec éviction du moins récemment visionné signifie que vos replays stockés les plus anciens disparaissent silencieusement au fil de nouveaux visionnages. Il n’y a pas d’épingle par partie, donc la contre-mesure est un processus, pas un réglage — si un replay compte, révisez-le tant qu’il est stocké, et gardez une copie de l’identifiant de partie et du lien pour pouvoir le re-traiter plus tard depuis l’enregistrement. Le quatrième mode d’échec est le repli de chargement de blocs : si le chargement différé du visionneur échoue, la page retombe sur le replay classique, donc le premier réflexe quand une ouverture « paraît différente » est de vérifier la console, puis de recharger.

Commandes de lecture : la référence clavier et vitesses complète

Le visionneur est d’abord piloté au clavier, et toute la surface de commande est assez petite pour tenir dans un tableau. Le taux de traitement en dessous est de 10 ticks par seconde, donc une frame est un tick de la simulation — dix frames sont une seconde réelle de partie — et chaque saut, pas et vitesse ci-dessous sont définis par rapport à cette base.

Quelques notes rendent le tableau utilisable. D’abord, le pas de frame est exact : à 10 ticks/seconde, une flèche droite unique est un dixième de seconde de partie, et Maj+flèche droite est dix secondes de partie — la constante de 100 frames est choisie pour qu’un Maj maintenu couvre une portée significative en quelques appuis. Deuxièmement, les touches sont volontairement ignorées tant qu’un menu de réglages est ouvert — la release l’a signalé comme une correction, pour que chercher l’option en pleine visionneuse ne balaye pas accidentellement la barre. Troisièmement, les vitesses sont multiplicatives sur le temps réel, donc 32x joue une simulation de 10 ticks/seconde à 320 ticks/seconde ; le rendu et les frames décodées suivent, mais traitez 32x comme une vitesse de balayage pour repérer où quelque chose s’est passé, pas une vitesse pour lire des effectifs. Quatrièmement, naviguer vers la queue non traitée n’est pas une erreur à redouter : la queue est grise précisément parce qu’elle n’existe pas encore, et un saut dedans recule à la dernière frame traitée. Le bon comportement est de laisser le passage finir, puis naviguer. Cinquièmement, comme l’état de lecture est local à la page du visionneur, fermer l’onglet en plein visionnage perd le curseur mais pas le travail — le replay stocké reste dans IndexedDB et l’ouverture suivante repart du début avec un accès immédiat aux frames. Sixièmement, les mêmes touches sont mortes dans la superposition des réglages : la release a corrigé précisément le cas où appuyer sur une touche de saut pendant qu’on cherche un réglage balayait silencieusement la barre derrière le menu. Septièmement, le choix de vitesse est collant pour la session — il ne se réinitialise pas quand on ferme le menu de réglages — ce qui est pratique pour le motif « balayer à 32x puis redescendre à 1x » et seulement agaçant si l’on oublie qu’on l’a laissé à 32x.

Ajustements par mode et par carte : FFA, équipe et solo tirent chacun une valeur différente

Le visionneur est uniforme entre les modes, mais la valeur par ouverture ne l’est pas, parce que la question de révision diffère. En FFA à 25 joueurs, la densité d’événements simultanés est la plus haute et la barre la plus longue : une partie à ce nombre de joueurs produit plus de changements d’état par seconde, donc le passage de traitement est le plus lourd, le replay stocké le plus volumineux, et le gain du positionnement le plus grand — tout l’enjeu est de trouver un fil dans une partie bruyante. Balaie à 16x ou 32x, ne descends à 1x qu’à l’intérieur de la fenêtre trouvée. En modes d’équipe (1c1, 2c2, 4c4), la partie est plus propre et la question de révision est d’habitude tactique : un atterrissage précis, un franchissement précis, un tirage de noyau précis. Le pas au niveau de la frame est l’outil juste ici — 10 frames sont une seconde réelle, donc on peut atterrir exactement sur le moment et dérouler la suite tick par tick — et les replays sont moins chers en temps de traitement comme en stockage, ce qui permet d’en réviser davantage ; le plafond de 256 Mo tient bien plus de parties d’équipe que de FFA. En solo, deux choses changent. Le rythme de hachage est plus grossier — un point de contrôle tous les 100 tours au lieu de tous les 10 — donc le contrôle d’intégrité est moins dense, et la queue d’un replay (les frames après le dernier hachage enregistré) n’a plus rien à contrôler ; la documentation est explicite que ces frames finales sont envoyées telles quelles, ce qui en pratique est au plus les quelques dernières secondes. Le second changement du solo est que l’enregistrement peut venir de votre propre run, ce qui rend un drapeau non vérifié plus probablement un vrai trou de données qu’un glitch de récupération ; quand vous voyez le signalement non vérifié sur votre propre replay solo, enregistrez à nouveau le run plutôt que de faire confiance aux frames stockées. La taille de la carte compte dans les modes : une grande carte avec de longues routes de commerce produit plus d’historique d’événements et un replay stocké plus volumineux qu’une carte compacte à durée égale, donc si vous êtes près du plafond de stockage et que vous révisez des FFA sur grandes cartes, c’est le premier à tailler en regardant simplement des replays plus récents et plus petits. Aucun de cela ne change les commandes — le même tableau s’applique partout — cela ne change que l’endroit où votre temps de révision vaut le mieux. Un habitude transvers aux modes suit du calcul de stockage : les replays d’équipe coûtant moins cher, traitez-les plus souvent, et gardez le budget de stockage pour les FFA denses qui en valent vraiment la peine.

Processus de révision : faire du visionneur un habitude post-partie répétable

Le visionneur est un outil de preuve, et l’habitude qui le fait payer est un passage fixe en cinq étapes que vous lancez sur chaque partie qui compte. Étape un : activez l’option une fois — New Replay Viewer dans les réglages — et n’y pensez plus jamais ; la forme de lien direct #replay-viewer=<gameID> est votre plan de fuite pour partager une vue navigable avec quiconque, y compris des joueurs dont l’option est désactivée. Étape deux : ouvrez la partie finie depuis votre historique la même nuit, pour que le passage de traitement se passe sur votre meilleure machine et que le replay soit stocké tant que le build est assurément en ligne — cette habitude unique est toute la défense contre la douleur verrouillée par la version où une belle partie devient in visionnable après une mise à jour pendant la nuit. Étape trois : laissez le passage finir avant de naviguer, et utilisez la queue grise comme indicateur de progression ; si vous êtes pressé, le passage est court pour les parties d’équipe et vous pouvez sortir et revenir — le magasin se souvient. Étape quatre : balaie vite puis atterris lentement : 16x ou 32x pour trouver la fenêtre, 1x pour la lire, Espace pour figer une frame en vérifiant des chiffres, Maj+flèches pour déplacer des blocs de dix secondes — et notez la frame ou le timestamp du moment qui compte, parce que le curseur ne survit pas à la fermeture de l’onglet. Étape cinq : transformez le moment en un changement testable avant la partie suivante, ce qui est exactement la méthode de révision que le guide Révision de replay codifie : trouvez la première hypothèse cassée au moment que vous venez de localiser, et changez une seule chose dans le prochain lobby. Cette dernière étape est ce qui distingue le visionneur d’un lecteur vidéo — le saut existe pour répondre à « pourquoi cette décision a échoué à cette seconde-là », et la réponse n’est utile que si elle change le prochain lobby. Si votre question de révision porte sur comment vous jouez en général plutôt que sur une partie, la surface de contrôle plus large du guide Touches rapides est là que vivent les habitudes côté en direct ; cette page couvre le côté post-partie, du moment où une match se termine au moment où vous avez une idée testable de ce qui doit changer, et c’est cette boucle de cinq étapes qui transforme une simple navigation dans un replay en un avantage récurrent dans le lobby suivant.