Analyser un replay OpenFront : transformer une partie en meilleure décision

Réponse directe : examinez la première hypothèse cassée, pas le score final

Ouvrez la partie terminée depuis l’onglet Games d’un profile public, copiez son game link, parcourez Stats, puis regardez trois à cinq tournants du replay. Pour chacun, notez ce que vous saviez, votre choix, le résultat attendu, le résultat réel et le premier signal qui a invalidé le plan. Marquez chaque conclusion comme observée, déduite ou inconnue. Pour la partie suivante, ne changez qu’une action, avec un déclencheur et une condition d’arrêt.

Voilà le but entier d’une analyse de replay. Ce n’est ni un spectacle passif, ni une chasse au moment où la victoire est devenue évidente, ni une façon de ridiculiser l’action qui a perdu le dernier territoire. Une analyse utile reconstruit la décision la plus ancienne qui restait sous votre contrôle. Si une offensive occidentale échoue à la dix-huitième minute, le bon repère peut être la City non construite à 06:00, l’avertissement d’alliance ignoré à 11:00 ou le second front accepté à 14:00. Le résultat indique où l’histoire se termine. Le replay sert à tester quand ses hypothèses ont cessé d’être vraies.

OpenFront v0.34.1 fournit un parcours de preuve cohérent. Les profiles sont publics, leur Games history expose les parties terminées, une carte d’historique peut ouvrir Stats, copier un lien normal ou lancer Watch Replay, et le panneau d’information d’un joueur est accessible en mode spectator du replay. Une ancienne partie peut passer par une enveloppe de replay versionnée lorsque celle-ci existe. Toutes ces fonctions ne sont pas nées avec v34 : les profiles partageables et leur historique étaient déjà documentés en v0.33.13, tandis que le support des anciennes versions était décrit en v0.33.6. v0.34.1 est ici la frontière actuelle, car sa Release officielle et son tag immuable permettent de vérifier comment ces éléments fonctionnent maintenant ensemble.

Cette page possède la méthode après la partie. Le guide de la première partie explique les décisions d’une première partie en direct. L’évaluation des menaces possède le scan à effectuer avant une nouvelle attaque. Le plan de reprise explique comment stabiliser une position déjà endommagée. L’analyse de replay commence après la fin et demande quelle croyance a échoué, quelle réponse était visible et quelle expérience à une variable doit entrer dans la partie suivante. Elle peut examiner ouverture, commerce, alliance, attaque terrestre, échange nucléaire, retour ou comportement inhabituel sans remplacer les guides spécialisés.

Conservez trois étiquettes de preuve. Observé signifie que le replay, le panneau, la carte ou Stats montre directement le fait. Déduit signifie que la séquence soutient l’explication sans exposer sa cause. Inconnu signifie que les éléments disponibles ne départagent pas plusieurs explications plausibles. Un replay peut montrer des transferts répétés entre deux joueurs ou des attaques successives. À lui seul, il ne prouve ni coordination privée, ni triche, ni intention, ni ce qu’une personne voyait sur un autre écran. Cette discipline n’est pas une formule de politesse ajoutée à la fin : elle empêche le recul de transformer une chronologie utile en certitude fausse.

Le test de fin est concret. Vous devez obtenir une phrase comme : « Quand le leader voisin s’engage sur un deuxième front, je teste une poussée limitée jusqu’à l’ouverture d’une nouvelle frontière ou jusqu’à ce que ma réserve passe sous son dernier niveau stable ; dans le prochain replay, je vérifierai si je me suis arrêté au premier signal d’invalidation. » « Être plus agressif » échoue : aucun déclencheur, aucune limite, aucun résultat observable. Une partie fournit une hypothèse. La suivante fournit la première tentative pour la réfuter.

Une bonne conclusion ne promet donc pas la victoire. Elle réduit une décision floue à un comportement contrôlable. Elle indique aussi quelles informations n’étaient pas disponibles sur le moment. Si l’adversaire change de route, si l’alliance expire ou si la carte crée un contact nouveau, l’expérience prévoit une nouvelle lecture plutôt qu’une obéissance aveugle à la règle. Le replay devient alors un outil d’entraînement reproductible, pas une collection d’anecdotes où chaque résultat reçoit après coup une explication parfaite.

Choisir la bonne partie et préserver les preuves avant la lecture

Commencez par le profile, pas par le souvenir du meilleur moment. Dans v0.34.1, le client peut demander un profile public et sa Games history paginée sans exiger l’authentification du lecteur. Un profile se partage par une URL contenant l’identifiant public du joueur, et ses onglets comprennent Stats, Games et Clans. Ouvrez Games, choisissez la partie terminée et relevez la carte avant de toucher aux commandes du replay. Elle peut afficher carte, date, résultat, clan tag, nom, type de partie, nombre de joueurs et durée. Ces champs définissent le cas. « Ma partie sur une île » ou « le gros FFA » ne suffit pas pour une comparaison future.

Copiez aussitôt le game link. L’action de l’historique copie une route normale sur l’origine actuelle, souvent /w15/game/<id> lorsqu’un worker est connu, sinon /game/<id>. Ne fabriquez pas vous-même un hôte replay.. La route normale charge d’abord l’enregistrement archivé. Si son gitCommit diffère du client courant, celui-ci peut tester une enveloppe versionnée disponible et ne rediriger qu’après une réponse HTML valide. La différence compte : le lien normal est la preuve durable qu’un second analyste peut ouvrir ; l’enveloppe versionnée reste une infrastructure conditionnelle, pas une garantie de conservation de chaque build historique.

Avant la lecture, écrivez une question étroite et la raison de son importance. « Pourquoi ai-je perdu ? » ouvre une recherche sans limite et autorise n’importe quel moment embarrassant comme réponse. « Quand l’attaque occidentale a-t-elle cessé d’être protégée par mon alliance méridionale ? » identifie relation, route et événement invalidant. « Mes trois Factories ont-elles financé le retour, ou leur construction a-t-elle exposé ma seule City connectée ? » identifie investissement et résultat de survie. Une seule séquence doit pouvoir répondre. Si un autre problème apparaît, placez-le dans une liste d’attente au lieu de remplacer silencieusement la cible.

Ouvrez ensuite Stats, mais traitez les classements comme des localisateurs, pas des verdicts. La vue du tag peut montrer carte, heure de début, durée et nombre de joueurs, puis des rangs comme survival, conquests, Atoms, Hydros, MIRVs, Total Gold, Stolen Gold, Naval Trade, Train Trade et Conquered Gold. Un Total Gold élevé ne prouve pas une bonne dépense. Beaucoup de conquests ne prouvent pas que l’attaque est partie au bon moment. Un Train Trade important ne révèle pas quelle station ou quel transfert a changé la partie. Un classement dit où regarder ; la causalité reste dans la chronologie.

Choisissez trois à cinq repères avant Play. Les valeurs par défaut utiles sont l’engagement après le spawn, la première expansion contestée, le premier gros achat de structure, la première alliance ou trahison, le premier engagement nucléaire, la première lourde perte de territoire et le moment où une coalition finale devient inévitable. Ne gardez que ceux qui répondent à la question. Regarder trente minutes avec la même attention produit un autre souvenir flou. Des repères rendent les comparaisons possibles et permettent à une seconde personne de reproduire l’analyse.

À chaque repère, conservez deux colonnes. « Connu alors » contient uniquement ce qui était raisonnablement visible : frontières, notifications, alliances, ressources courantes, structures visibles et attaques actives. « Visible dans le replay » contient l’état plus complet accessible après coup. Ne déplacez jamais une information réservée au replay dans la première colonne pour rendre l’ancien choix ridicule. Cette séparation fonde un diagnostic équitable : une décision pouvait être raisonnable au départ et devenir mauvaise après un avertissement visible. Cette formulation guide beaucoup mieux la partie suivante que « le plan entier était mauvais puisque le résultat l’était ».

Avant de lancer la vidéo, vérifiez enfin que le lien, la carte et la question désignent bien la même partie. Une date voisine ou un même type de carte peut facilement faire analyser le mauvais cas. Notez aussi les informations absentes. Si la carte ne montre pas un champ, si l’historique ne remonte pas assez loin ou si une enveloppe ancienne est indisponible, marquez cette limite au lieu de reconstruire une valeur de mémoire. Préserver les lacunes fait partie de la preuve et évite qu’une comparaison future ne repose sur une donnée inventée.

Employer TRACE pour convertir la chronologie en un changement réfutable

TRACE est un cadre éditorial d’analyse, pas une mécanique d’OpenFront. Ses cinq lettres ramènent un long replay à une petite décision : Target, cibler le moment ; Reconstruct, reconstruire l’état ; Audit, auditer la preuve ; Classify, classer la cause ; Edit, modifier une seule chose. Appliquez la même séquence à chaque repère choisi. La répétition empêche d’accorder aux actions gagnantes une indulgence spéciale et d’exiger des actions perdantes une perfection impossible.

Target nomme la décision précise et son bénéfice attendu. Écrivez une action, pas une humeur : « J’ai envoyé la deuxième vague vers l’ouest parce que Blue combattait au nord, et j’espérais prendre le Port avant la fin de l’avertissement d’alliance. » Ajoutez l’objet sur la carte et le signal visible. Si vous ne trouvez pas la décision, remontez depuis la perte jusqu’au dernier instant où une option différente existait. La cible est rarement « la bataille finale » ; c’est l’engagement qui a supprimé la prochaine solution sûre.

Reconstruct produit une phrase d’état. Notez les ressources lorsqu’elles sont visibles, le territoire connecté, les frontières ouvertes, les conflits actifs, les structures menacées, les alliances et leurs alertes d’expiration, puis les joueurs capables d’intervenir. Formulez ensuite l’hypothèse qui reliait ces faits : « Blue ne peut pas pivoter avant la capture » ou « cette route commerciale survivra à l’amélioration du Port ». Mettez en pause quand elle devient fausse pour la première fois. Ce signal invalidant peut être une nouvelle frontière, une notification, un transport qui part, un compte à rebours d’alliance, une structure ennemie ou un plancher de ressources. Le signal se réutilise mieux que les dégâts finaux.

Audit croise la carte avec le panneau joueur du replay et Stats. L’état spectator peut ouvrir le panneau d’information du joueur sélectionné sans le radial d’actions de la partie en direct. Le panneau peut exposer identité, ressources, statistiques, alliances, nombre de trahisons et état commercial à cet instant. Ne notez que ce qui apparaît réellement. Si une valeur manque, marquez-la inconnue au lieu de l’emprunter à votre mémoire ou aux sous-titres automatiques. Les classements finaux servent à repérer un total de ressources, conquêtes, commerce ou nucléaire remarquable, puis vous devez revenir au moment exact où ce total commence à compter.

Classify attribue une étiquette de preuve et une classe d’erreur. La preuve est observée, déduite ou inconnue. La première rupture contrôlable peut être une mauvaise compréhension des règles, une erreur de mesure ou de timing, une contrainte de carte ou de mode, une adaptation ennemie, une coordination hors de votre contrôle ou la chance. Plusieurs facteurs peuvent contribuer, mais choisissez une cause principale. Tout appeler malchance ignore les alertes visibles ; tout appeler mauvais jeu condamne un choix fait sans les informations désormais disponibles. Le classement pose une frontière juste entre progrès technique et récit rétrospectif.

Edit transforme la rupture en expérience à une variable : « Quand signal, je fais une action jusqu’à condition d’arrêt ; je l’évalue par un résultat observable dans le prochain replay. » Restez modeste. Modifier en même temps spawn, ordre de construction, taille d’attaque, politique d’alliance, réserve et partenaire commercial crée une autre histoire, sans leçon attribuable. Une expérience utile peut limiter la première vague, retarder une structure, programmer un nouveau scan lors d’une alerte d’alliance ou conserver une retraite connectée. Au repère suivant, le prochain replay peut réfuter l’expérience même si vous gagnez.

TRACE n’est complet que si une autre personne peut suivre le lien, trouver le même repère, comprendre quels faits étaient visibles et dire ce qui réfuterait votre conclusion. L’accord n’est pas requis ; l’auditabilité l’est. Un joueur peut classer l’événement comme adaptation adverse plutôt que faute de timing. Les deux lectures doivent néanmoins pointer vers le même avertissement et expliquer ce que mesure l’expérience suivante. Si personne ne peut décrire un contre-exemple possible, la conclusion reste probablement un verdict vague, pas une hypothèse testable.

Scénario un : trouver le surengagement avant l’effondrement territorial

Supposons un FFA à 65 joueurs sur Greece, avec une chronologie inspirée du type de situation vu dans la vidéo communautaire vérifiée, sans lui emprunter de mécanique. À 02:00, vous tenez une zone peu dense et lancez des poussées limitées à 10 % tout en envisageant une annexion. À 06:00, vous possédez une City et une Factory connectées, une alliance protège la frontière nord et l’adversaire occidental combat au sud. Vous lancez une attaque plus grande vers l’ouest, car la route semble momentanément bon marché. À 10:00, un second joueur atteint votre nouvelle côte. À 14:00, l’alliance nord affiche une alerte d’expiration. À 18:00, vous renforcez toujours l’ouest avec moins de réserve qu’à 06:00, tandis qu’une menace nucléaire apparaît. Le territoire ne s’effondre visiblement qu’à 22:00.

Une lecture centrée sur le score commence à 22:00 et accuse l’arme nucléaire. TRACE remonte plus tôt. Ciblez l’engagement occidental de 06:00 : le bénéfice attendu était une capture courte avant le rétablissement du défenseur. Reconstruisez les faits connus : cet adversaire était occupé, l’alliance nord existait encore, City et Factory restaient connectées et aucune seconde frontière côtière n’était ouverte. Le premier test pouvait être raisonnable. Le premier signal invalidant arrive à 10:00, lorsque le nouveau joueur atteint la côte. Il modifie à la fois le nombre d’intervenants et la forme à défendre. L’alerte d’alliance de 14:00 est un deuxième signal plus fort. Continuer après l’un ou l’autre demande une nouvelle hypothèse, pas la prolongation automatique du plan de 06:00.

Auditez les joueurs concernés à 06:00, 10:00 et 14:00. Notez seulement les ressources, alliances, échanges et statistiques que le panneau expose réellement. Utilisez conquests, Total Gold, nucléaire ou commerce finaux uniquement pour choisir la séquence à revoir. Un bon rang Gold ne prouve pas que la Factory était correcte, et le MIRV ultérieur ne prouve pas que l’attaque initiale était absurde. La conclusion causale défendable est plus étroite : après l’ouverture de la côte, l’offensive ne bénéficiait plus de la protection à un front supposée au départ, mais les renforts ont dépassé deux signaux visibles de nouveau scan.

Classez la rupture principale comme une faute de timing, avec la géométrie de carte et l’adaptation adverse comme facteurs. Il ne s’agit pas forcément d’une méconnaissance de règle. L’erreur consistait à traiter un test valable comme une autorisation permanente de renforcer après transformation de la route. Marquez l’ouverture côtière et l’avertissement d’alliance observés. Marquez « le second joueur attendait mon engagement » déduit, car la séquence n’expose pas son intention. Toute affirmation de coordination privée reste inconnue.

Modifiez une seule action : « Quand le territoire gagné par ma poussée rend un nouveau joueur joignable, j’arrête les renforts et je rescane toutes les frontières actives ; je ne reprends que si la réserve initiale reste connectée et si l’alliance expirante possède une réponse nommée. » Le résultat observable n’est pas la victoire. C’est la fin de la première vague avant qu’un second front ne consomme la réserve. Gardez autant que possible ordre de construction, spawn et politique d’alliance inchangés pour attribuer l’effet au signal d’arrêt.

L’adversaire peut contrer cette expérience. Il peut montrer une petite approche pour vous faire arrêter à bon compte, dissimuler une pression derrière une alliance ou attendre la fin de votre scan. Cela ne réfute pas automatiquement la règle ; le prochain replay doit distinguer contact et engagement. Notez si la frontière formait une vraie route, si la force opposée persistait et si l’arrêt conservait une option utile. Un arrêt discipliné peut être bon tout en cédant des cases faciles ; une poussée poursuivie peut gagner une fois sans devenir répétable.

Le test se termine lorsque vous pouvez comparer le même signal dans une autre partie. Si aucune nouvelle frontière ne s’ouvre, la victoire ne valide pas la règle. Si vous stoppez, gardez votre réserve mais perdez ailleurs, la règle peut avoir rempli sa mission sans résoudre toute la partie. Cette modestie empêche une expérience locale de devenir une doctrine universelle après un seul résultat favorable.

Scénario deux : séparer un retour reproductible du lobby qui l’a permis

Supposons que vous terminiez premier d’un long FFA après avoir été réduit à une position étroite et presque déconnectée. La carte d’historique indique 48 minutes. Le replay révèle trois actions apparemment décisives : vous avez conservé une Factory, accepté le commerce d’un tiers et construit un SAM avant de reprendre l’expansion terrestre. Les rangs finaux montrent un Train Trade élevé et plusieurs conquests. La conclusion séduisante devient une recette héroïque : « Quand l’élimination approche, construisez Factory et SAM, attendez, puis repartez. » La discussion Reddit vérifiée montre pourquoi ce récit est trop simple. Son auteur cite aussi la guerre entre rivaux, les transferts d’un tiers, les adversaires qui l’ont ignoré, le surinvestissement d’un rival presque éliminé et la chance.

Tenez deux registres. Le registre contrôlable contient les choix du joueur étudié : garder une structure connectée, ne pas attaquer durant la phase la plus faible, accepter ou préserver un accès commercial, répondre à une menace nucléaire visible et choisir une première réentrée limitée. Le registre des conditions facilitatrices contient ce que les autres ont créé : deux leaders qui s’épuisent, un partenaire qui continue ses transferts, un ennemi qui choisit une autre cible et une route précieuse qui reste ouverte. Mettez en pause à l’apparition de chaque condition. Une action n’entre dans l’expérience suivante que si vous pouvez nommer le signal qui la rendait rationnelle ; une condition externe entre dans le scan, car vous ne pouvez pas la commander.

Imaginons qu’à 12:00 la Factory survive sans chaîne de stations sûre, qu’à 16:00 un tiers commence à commercer, qu’à 20:00 les deux leaders entrent en guerre, qu’à 25:00 vous ajoutiez un SAM après l’apparition visible d’un Silo et qu’à 31:00 vous avanciez sur un terrain abandonné par l’un des leaders. TRACE ne distribue pas le mérite causal depuis le classement final. Ciblez la réentrée de 31:00. Reconstruisez les éléments connus : les leaders restent engagés, la route est ouverte depuis onze minutes, la structure défensive couvre le noyau survivant et aucune frontière immédiate ne s’ouvre derrière. Auditez ressources et alliances à 20:00, 25:00 et 31:00. Classez conflit et commerce comme conditions facilitatrices, le SAM comme réponse à une menace observée et la poussée limitée comme décision contrôlable.

L’expérience suivante doit préserver cette frontière : « Quand deux joueurs plus forts et joignables restent engagés l’un contre l’autre et que mon noyau connecté a survécu pendant un intervalle complet de revue, je teste une seule expansion vers une route abandonnée ; j’arrête si l’un des leaders se désengage ou si la route crée un second front actif. » N’ajoutez ni « exactement trois Factories », ni attente fixe, ni retour garanti. Une seule partie n’établit pas ces nombres. Le test demande seulement si attendre un conflit vérifiable tout en gardant une sortie améliore les options de survie.

Ajoutez maintenant une variante anormale. Le replay peut montrer quatre voisins attaquant successivement ou déplaçant plusieurs fois leur commerce vers le même bénéficiaire. Utilisez le lien copié et relevez positions, horodatages, transferts, changements de relations et explications alternatives plausibles. Marquez la séquence observée. Marquez l’hypothèse d’une coordination extérieure inconnue tant qu’aucun autre élément ne l’établit. Un replay permet un rapport neutre sur les événements, mais ne lit ni messages privés ni intentions. Une coopération inhabituelle peut être planifiée, émergente, profitable aux participants ou simplement coïncidente.

La condition de fin est la même pour les deux variantes. Un second analyste doit pouvoir séparer votre action des conditions qui l’ont facilitée, trouver le premier choix contrôlable et préciser quel événement futur réfuterait la leçon. Un retour dépendant de rivaux qui vous ignorent reste instructif. Il enseigne « reconnaître et protéger l’ouverture », pas « cet ordre de construction gagne toujours ». Le registre doit aussi garder les cas où l’ouverture semblait présente mais s’est refermée avant votre action ; ils empêchent de sélectionner seulement les réussites.

Le contre-jeu compte. Un leader peut feindre un engagement, un partenaire commercial peut interrompre ses transferts, ou le territoire abandonné peut devenir un piège qui allonge votre frontière. Votre règle doit donc utiliser des signaux réversibles et une sortie nommée. Si vous ne pouvez pas arrêter la réentrée après le désengagement d’un leader, l’expérience est trop grande. Si vous survivez seulement grâce à un transfert non reproductible, classez cette partie comme cas facilité plutôt que comme validation de la construction.

Auditer les statistiques et le panneau sans les transformer en verdict

Le profile, la carte d’historique, Stats, la carte du replay et le panneau joueur répondent à des questions différentes. Le profile identifie le compte et offre le chemin vers l’historique public. La carte fixe contexte et actions. Stats résume les résultats. La carte du jeu montre la séquence. Le panneau expose l’état du joueur sélectionné à un instant. Les erreurs commencent lorsqu’une couche doit prouver ce qu’elle ne possède pas : un rang final n’explique pas une alliance, une capture d’écran ne démontre pas une tendance antérieure de ressources, un profile public ne prouve pas qui contrôlait le compte à cet instant.

Utilisez une table compacte et écrivez la limite à côté de l’observation :

Surface de preuve	Bonne question	Conclusion dangereuse	Usage pendant la revue
Carte d’historique	Quelle partie, carte, date, durée, type et résultat ?	Le résultat révèle l’erreur décisive	Définir le cas et préserver le lien
Game Stats	Quelle catégorie finale est anormalement haute ou basse ?	Un total élevé prouve timing ou causalité	Choisir une séquence à inspecter
Carte du replay	Quand frontières, conflits et menaces visibles changent-ils ?	La carte révèle une intention privée	Localiser signaux et réponses
Panneau joueur	Quelles ressources, alliances, trahisons, statistiques ou échanges sont exposés ?	Toute valeur ou action cachée est disponible	Croiser un repère
Profile public	Quelles parties terminées sont liées à cette identité publique ?	L’historique prouve motif, niveau ou faute	Trouver des cas comparables

Le chemin du replay dans le tag est un état spectator. Un clic droit sur une case joueur peut ouvrir la route du panneau en lecture plutôt que le radial d’actions en direct, et les intentions normales envoyées au serveur sont omises de cette branche spectator. Cela établit une interface d’analyse, pas l’omniscience. Le tag courant ne possède pas un test unitaire spécifique au replay pour chaque champ et action du panneau. Relevez ce que le build devant vous rend réellement. Ne promettez pas que chaque action disparaît, que chaque statistique est historique à chaque tick ou que les outils de moderation partagent exactement cette frontière.

Les classements exigent une retenue particulière. Survival peut orienter vers une phase de reprise ; conquests, vers une suite de poussées ; Atoms, Hydros et MIRVs, vers une phase nucléaire ; Total Gold, Stolen Gold, Naval Trade, Train Trade et Conquered Gold, vers une question économique. Aucun n’établit si la dépense était opportune, la route sûre ou la menace connue. Utilisez le rang pour choisir les repères, puis revenez à l’état, la décision, l’attente, la réponse et le premier signal invalidant.

Surveillez quatre fautes fréquentes. Le biais de résultat déclare bon tout choix gagnant et mauvais tout choix perdant. La fuite rétrospective place des faits du replay dans la colonne « connu alors ». La substitution de métrique remplace la question par le rang le plus facile à citer. L’empilement narratif change cinq comportements après une partie puis attribue la prochaine victoire au changement préféré. TRACE les limite en préservant l’hypothèse initiale, en étiquetant les faits et en n’éditant qu’une variable.

Le comportement adverse limite également l’attribution. Un rival peut montrer une fausse ouverture, dépenser juste assez pour provoquer une réponse, accepter une alliance afin d’interrompre une séquence nucléaire ou se retirer pour allonger votre frontière. L’objectif n’est pas de supprimer l’incertitude, mais d’identifier celle qui était visible et l’action réversible disponible. Si aucun signal fiable n’existait, la bonne étiquette peut être « inconnu » plutôt que « erreur ». Gardez ce cas comme contre-exemple : toutes les défaites ne contiennent pas une faute réparable.

Pour chaque observation, exigez enfin une provenance compréhensible par un autre lecteur : carte, panneau, catégorie Stats ou information de la carte d’historique. « Je l’ai senti » peut lancer une question, mais ne clôt pas l’audit. À l’inverse, une absence de champ ne prouve pas une absence d’action. Cette asymétrie est essentielle : l’interface montre certains faits positifs, tandis que le silence doit rester une limite, sauf si la règle officielle garantit que l’élément serait visible.

Respecter les limites de carte, mode, version, confidentialité et disponibilité

Une leçon ne devient portable qu’après avoir nommé son environnement. Relevez carte, type de partie, nombre de joueurs, durée et règles visibles du mode avant de comparer deux matchs. Un replay insulaire privilégie l’accès à l’eau, la survie du Port, les routes de transport et les joueurs capables d’entrer dans la composante. Un corridor continental étroit privilégie le nombre de frontières et la géométrie des Defense Posts. Une carte compact et encombrée réduit le temps de réaction et crée plus tôt les contacts avec un tiers. Une grande carte préserve parfois une fenêtre plus longue tout en masquant une intervention distante. « S’étendre plus tôt » ne décrit donc pas la même action dans ces formes.

Les modes changent aussi la preuve. En Team, un investissement apparemment inefficace isolément peut protéger la route d’un coéquipier ou compléter un objectif commun. Analysez l’état de l’équipe et les joueurs capables de renforcer, pas seulement le rang du joueur ciblé. En FFA, une coopération temporaire et un ennemi commun peuvent produire des attaques synchronisées sans équipe formelle. En singleplayer, la pause et une moindre coordination extérieure modifient la pression d’exécution. Un lobby privé peut désactiver des unités ou changer les réglages. Ne comparez pas une action entre modes avant d’avoir nommé les hypothèses équivalentes de relation, victoire, unités et timing.

La version appartient au cas ; ce n’est pas une décoration. v0.33.13 documentait déjà les profiles publics et partageables ainsi que leur game history. v0.33.6 documentait la lecture de parties issues d’anciennes versions. v34 a ensuite réuni la politique de profile public, le bouton de game link sur les cartes et un panneau d’information utilisable en replay dans le parcours actuel. Si le gitCommit de la partie archivée diffère du client courant, l’application peut tester https://replay.<audience>/<gameId> et rediriger lorsqu’une enveloppe valide répond. Elle conserve un état de mismatch si celle-ci manque. Gardez donc le lien normal, laissez le client router et ne promettez jamais l’accès permanent à tous les builds historiques.

Cette frontière change aussi les conclusions stratégiques. Une ancienne version peut avoir un équilibre d’attaque, des seuils de victoire, un timing nucléaire, une IA, un ensemble de cartes ou des signaux d’interface différents. N’étudiez la décision qu’après avoir contrôlé les règles de la version. N’utilisez pas un conseil v0.34.1 pour déclarer rétrospectivement irrationnel un choix v33. Quand la mécanique pertinente diffère, ouvrez l’article de version ou la réponse principale actuelle et marquez le replay historique. Les notes de version v34 établissent la frontière stable ; les guides de combat terrestre et de victoire en Overtime possèdent les règles elles-mêmes.

La confidentialité doit être explicite, car la Release officielle v0.34.1 affirme que les profiles sont publics et que chacun peut revoir les games d’un joueur. Elle indique aussi la suppression du compte comme moyen de cacher toutes les parties. Le client confirme les requêtes publiques de profile et d’historique ainsi que les champs visibles, mais il ne prouve ni le délai de suppression côté serveur, ni la durée de conservation, ni chaque règle de masquage. Ne partagez que le game link ou le profile link nécessaire. Évitez de republier des données personnelles, de transformer une analyse stratégique en dossier d’accusation ou de suggérer qu’une partie publique annule toute préoccupation de confidentialité.

La disponibilité reste conditionnelle. L’historique emploie une pagination avec curseur opaque ; le schéma ne garantit ni taille de page ni horizon permanent. Un lien peut dépendre plus tard d’une enveloppe jamais archivée. Le réseau ou le déploiement peut interrompre une route valide. Conservez un petit registre écrit à côté du lien afin que la leçon survive à l’artefact. Ne téléchargez ni ne collectez des données privées pour contourner l’accès normal. La preuve utile est une séquence analysée avec ses limites, pas une copie permanente de l’historique d’autrui.

Prévoyez enfin le désaccord. Deux analystes peuvent accepter la même chronologie observée et choisir des causes principales différentes. Comparez le premier signal invalidant et l’expérience proposée, pas la confiance ou la rhétorique. Si une règle, une carte, un mode, une version ou une limite de visibilité modifie le sens du signal, la conclusion doit changer. C’est le comportement normal d’une analyse gouvernée par les preuves.

Avant de transférer une leçon, écrivez une phrase de portée : « Ce test concerne un FFA à 65 joueurs sur une carte côtière, avec les signaux visibles de v0.34.1. » Puis nommez ce qui manquerait dans un Team ou un ancien build. Ce simple contrôle empêche une règle locale de devenir un conseil universel. Il aide aussi le prochain analyste à choisir une partie comparable au lieu d’additionner des résultats incompatibles.

Tenir un registre, tester un changement et revenir au guide responsable

Utilisez les mêmes sept colonnes après chaque partie analysée. Une feuille stable rend deux matchs comparables et empêche le récit le plus récent d’effacer l’hypothèse précédente.

Moment ou événement	Ce que je savais alors	État visible en replay	Décision et attente	Résultat réel	Étiquette de preuve	Changement suivant
Spawn ou premier engagement
Première expansion contestée
Première alliance ou trahison
Premier surengagement majeur
Changement décisif de fin

Commencez par la carte d’historique. Conservez séparément le game link, puis inscrivez carte, type, date, durée, nombre de joueurs et résultat. Rédigez la question avant Watch Replay et ne remplissez que trois à cinq lignes. Dans « ce que je savais », excluez les informations réservées au spectator. Dans « état visible », citez carte, panneau ou catégorie Stats plutôt que « évident ». L’étiquette est observé, déduit ou inconnu. La dernière colonne reste vide jusqu’à l’identification de la première rupture contrôlable.

Écrivez l’expérience sous une forme stricte : « Quand signal, je fais une action jusqu’à condition d’arrêt. Je la juge par un résultat observable. » Si l’analyse révèle des renforts poursuivis après l’ouverture d’une nouvelle côte, l’action peut être un nouveau scan et un gel des renforts ; la condition, une réserve sous son dernier niveau stable ; le résultat, la fin de la première vague avant la formation d’un second front actif. Ne changez pas simultanément ouverture, structures, alliances et taille d’attaque. Conservez les autres variables autant qu’un lobby réel le permet.

Après la partie suivante, examinez le même repère même si vous gagnez. Le déclencheur est-il apparu ? Avez-vous exécuté l’action ? La condition d’arrêt s’est-elle activée ? Le résultat prévu a-t-il suivi ? Une victoire sans déclencheur ne valide rien. Une défaite où l’action préserve une seconde option peut néanmoins soutenir le test. Consignez les contre-exemples. Deux ou trois cas comparables peuvent améliorer une règle personnelle ; ils ne créent toujours pas une mécanique universelle.

Revenez ensuite à la page qui possède l’entrée défaillante. Utilisez l’évaluation des menaces si la cible était mauvaise ou un tiers manquait. Consultez le combat terrestre si le contact existait mais que l’engagement, la densité, la route ou la réserve échouait. L’économie fondamentale possède les contraintes de Gold et de capacité. La diplomatie et trahison possède le timing relationnel. N’ouvrez la reprise après MIRV que pour les minutes suivant un MIRV. Cette page diagnostique la responsabilité ; le guide spécialisé fournit règle et méthode.

La frontière de preuve est OpenFront v0.34.1, vérifiée le 15 septembre 2026. La Release v0.34.1 établit la politique publique et porte les fonctions v34. L’historique du profile, les Game Stats, le panneau du replay, le routage versionné et ses tests au tag établissent le comportement et les limites. Les discussions et vidéos sous-titrées du source pack montrent que les joueurs veulent rouvrir des versions anciennes, partager une partie exacte, distinguer surengagement et malchance, examiner des retours et décrire une coopération inhabituelle. Elles n’établissent ni règles, ni intention, ni jeu optimal.

Terminez en envoyant à votre partenaire le game link et l’unique expérience, pas un verdict. Une bonne analyse reste utile en cas de désaccord, car chronologie, étiquettes et condition d’arrêt se contrôlent. La partie suivante doit répondre à une question plus petite que la précédente. C’est ainsi que l’historique public devient une pratique plutôt qu’un spectacle.

Après deux ou trois essais, conservez aussi la formulation rejetée. Elle explique pourquoi la nouvelle règle est plus étroite et évite de répéter l’expérience sous un autre nom. Si aucune partie comparable n’apparaît, gardez l’hypothèse ouverte au lieu de la déclarer vraie. Le registre n’a pas besoin de produire une certitude à chaque ligne ; sa valeur vient de la possibilité de vérifier, contredire et améliorer le prochain choix.