OpenFront — Springbare replay-bezieker (v0.35.0): inschakelen, naar elk moment springen, zonder de hele partij te herijken

Rechtstreekse antwoord: schakel „Nieuwe replay-bezieker” eenmaal in en laat de verwerkingsrun aflopen

De v0.35.0-release heeft de lineaire replay die u van begin tot einde afspelde vervangen door een springbare bezijker, en die wordt optioneel uitgeleverd: met de instelling uit opent „Watch replay” nog steeds de klassieke replay, en de enige weg eromheen is de schakelaar New Replay Viewer in het instellingsmenu. Die schakelaar leest de interne instelling settings.replayViewer, die standaard uit staat. Zodra hij aan is, gaat elke beëindigde partij die u uit uw geschiedenis opent in de bezijker in plaats van de klassieke route. Het principe: de bezijker verwerkt het gearchiveerde partijrecord eenmalig, in uw browser, op de engine-worker zelf — dezelfde worker die live partijen aandrijft — en na die ene verwerkingsrun kost elke sprong op de tijdlijn slechts ongeveer 20 milliseconden, omdat de hele partij al ontcod is en in het lokale geheugen ligt. De toetsenbesturing is opzettelijk minimaal gehouden: de spatiebalk schakelt afspelen en pauzeren, de pijltjestoetsen stappen één frame vooruit of achteruit, en Shift ingedrukt houdt 100 frames per keer over. Het snelheidsmenu biedt 0,5x, 1x, 2x, 4x, 8x, 16x en 32x. Er is ook een directe-linkvorm, #replay-viewer=<partijID>, die de bezijker opent zelfs als de schakelaar uit staat — zo kunt u een link delen die rechtstreeks in de springbare weergave landt. Er gebeurt hierbij niets op de server; de server levert alleen het gearchiveerde record. Als u één gebaar van deze pagina onthoudt: schakel de schakelaar eenmaal in, open een lange beëindigde partij uit uw geschiedenis en laat de verwerkingsrun aflopen voordat u oordeelt — de eerste opening is per ontwerp traag, en elke latere opening van dezelfde partij op dezelfde machine is bijna onmiddellijk, omdat de verwerkte replay in IndexedDB wordt bewaard. Dat is precies de hele productbelofte in één zin: u betaalt eenmalig een verwerkingskosten en krijgt daar een navigatievrijheid voor terug die uren aan lineair herbekijken verandert in een paar minuten gericht zoeken. De eerlijke verwachting die u vooraf moet hebben: de bezijker is een reviewinstrument, geen nieuwe manier om live partijen te specteren. Hij werkt alleen op beëindigde partijen, voegt een verwerkingsstap toe die de oude route niet had, en vraagt echt geheugen aan uw browser — de opslag beperkt het ontcodde archief tot 256 MB om een zwak apparaat te beschermen, en een zeer grote partij die haar praktische budget zou overschrijden wordt in een sessie waarbij de browser dat niet kan betalen gewoon niet ontcod. Het is een opzettelijke plafond: het product is „een beëindigde partij opnieuw openen en naar de minuut springen die ertoe doet”, en voor die taak is het optionele, lokale, servervrije ontwerp precies goed — u behoudt de klassieke replay als valbak, betaalt de eenmalige verwerkingskosten alleen wanneer een partij het herijken waard is, en krijgt een reviewinstrument zonder enige verandering aan hoe live partijen draaien.

Versiegrens: wat v0.35.0 verandert aan het replay-pad en wat het niet verandert

Vóór v0.35.0 kon een beëindigde OpenFront-partij alleen opnieuw worden geopend door de live-replayroute opnieuw uit te voeren: u sloot de beëindigde partij bij URL of uit de lobby aan, en de client speelde hem realtime af zoals u hem live zou hebben bekeken. Dat had drie structurele beperkingen. Ten eerste was hij lineair — u kon niet naar minuut veertig van een negentig minuten durende partij springen zonder de eerste veertig minuten door te wachten. Ten tweede had hij geen snelheidscontrole; de replay liep met het tempo waarmee de simulatie liep. Ten derde had hij geen integriteitscheck van welke soort dan ook, dus u vertrouwde het record zoals het was. v0.35.0 heeft al die drie veranderd: het record wordt nu verwerkt tot gecodeerde frames, de tijdlijn is volledig springbaar, het snelheidsmenu loopt van 0,5x tot 32x, en de verwerkingsrun verifieert de hash-checkpoints waar de live-clients het over eens waren, en stopt bij de eerste mismatch. De v0.35.0-release heeft ook de replay-worker zelf van 815 KB naar 340 KB laten krimpen door de replayverwerking op de engine-worker zelf te verplaatsen. Wat v0.35.0 niet verandert, is de deterministiegrens: de kernsimulatie is alleen binnen één build deterministisch, dus een record wordt alleen volledig afgespeeld op de build die hem speelde. Een record van een andere build wordt gerouteerd naar de versie-afhankelijke verpakking van die build op replay.<dom>/<partijID>, precies zoals het v0.33.6-versiereplaymechanisme dat in de wijzigingenlog stond, dat al hanteerde. In de praktijk betekent dit: op de hoofdsite kan een zeer oude partij nog steeds openen (via de verpakking of een bewaarde kopie), maar het moment dat de build van het record nergens meer bestaat, is de partij weg — de bezijker verwekt records niet, hij maakt de nog-beschikbare veel beter te bekijken. Het „Catching up…”-gedrag tijdens live spelen is iets heel anders: dat is de deterministische simulatie die inspringt op de actiestroom van de server na vertraging, geen replayfunctie, en de bezijker raakt het niet aan. Alle controlewaarden op deze pagina — het 256 MB-plafond, het tempo van 10 ticks per seconde, de snelheidslijst, de ±1/±100 frame-stappen — zijn gelezen uit de v0.35.2-tag broncode, die byte-voor-byte dezelfde replaycode is die de v0.35.0-release uitbracht. Twee praktische gevolgen van deze grens die het waard zijn plain te stellen. Ten eerste hangt de spoed van het zoeken zelf af van uw machine, niet van de server: de ~20 ms-cijfer is een gemeten mediaan voor een typische lange partij op de testhardware van de release, dus een bescheiden laptop die in een drie-uur durende 25-speler FFA zoekt voelt een beetje trager, en de eerste zoek na verwerking is de zwaarste omdat de ontcodde frames nog in het geheugen worden gelegd. Ten tweede erft de bezijker wat het record bevat en niets meer — hij kan toeschouwers tonen die nooit in het record bestonden niet, en hij kan een partij niet verlengen tot voorbij zijn vastgelegd einde, zodat „wat zou er gebeurd zijn als”-vragen buiten bereik blijven. Als uw herijken de bredere spelcontext rond een replay nodig heeft — welke kaart, welke economiekurve, welke nucleaire vensters — dekt de v0.35 nieuwe kaarten overzicht gids en de v0.35 kleine economie en spawn-boost gids de staande regels waar het replay tegen wordt beoordeeld.

Besliskader: wanneer de springbare viewer de review-waarde oplevert en wanneer de klassieke replay nog steeds de goedkoopste keuze is

De keuze tussen de springbare viewer en de klassieke replay is geen kwestie van voorkeur, maar van wat uw reviewvraag is en welk apparaat u erop opent. Drie vragen bepalen het antwoord. De eerste is of uw vraag waar is of wat is: als u wilt weten op welk moment iets gebeurde, is de springbare viewer het instrument, want het zoeken zelf is het product; als u de partij van begin tot eind wilt herbekijken zoals u hem hebt gespeeld, is de klassieke replay nog steeds de goedkopere route omdat hij geen verwerkingsstap heeft. De tweede is de grootte en de leeftijd van de partij: lange, dichte FFA-partijen leveren de grootste opgeslagen replay en de zwaarste verwerkingsrun, maar precies die partij levert ook de grootste besparing op omdat het lineaire herbekijken het duurst is; korte teampartijen hebben een lagere reviewwaarde per opening omdat het lineaire herbekijken al goedkoop was. De derde is het apparaat: op een krachtige machine is de eerste verwerkingsrun kort en de 256 MB-plafond zelden een probleem, terwijl op een zwak apparaat de verwerkingsrun en het geheugen de grens zijn waarbinnen u werkt. Combineer die drie en u krijgt een eenvoudige regel: gebruik de viewer voor lange, dichte partijen waarin u een specifiek moment moet lokaliseren, en gebruik de klassieke replay voor korte partijen of voor een volledig herbekijken van de hele loop. Een vierde overweging die veel spelers over het hoofd zien is het versie-afhankelijke aspect: de viewer maakt gebruik van een opgeslagen, lokale kopie, en die kopie is pas bruikbaar na een geslaagde verwerkingsrun op de build die de partij speelde; als uw reviewvraag afhangt van een zeer oude partij die al door een update is verouderd, dan is de vraag of de build nog ergens beschikbaar is, en dat bepalen of u überhaupt kunt herijken — in dat geval is de klassieke replay via de versie-afhankelijke verpakking de enige route, en de viewer helpt u alleen als de build nog live is. De praktische consequentie is dat u de viewer niet als een universele upgrade ziet, maar als een instrument voor een specifiek type vraag op een specifiek type partij op een specifiek type apparaat, en die drie specificaties samen bepalen of de eenmalige verwerkingskosten zich betalen. Als u die drie vragen niet kunt beantwoorden voordat u de schakelaar aanzet, dan is de goedkopere default de klassieke replay, want die faalt nooit op een verwerkingsstap die u niet hebt verwacht. De twee scenario’s die hier volgen geven u de schaal van wat de viewer daadwerkelijk verandert, uitgaande van de gedocumenteerde benchmark van 70 seconden verwerken en 24 MB opslag voor een 26-minuten 25-spelerpartij.

Scenario één: de 3-uur durende 25-speler FFA met een late-game verraad

Stel de situatie die het communitythread in november 2025 beschreef: een lange, dichte FFA die ver voorbij twee uur liep, met een late-game ineenstorting die u vermoedt van een specifiek bondgenoot die het vertrouwen brak. Met de klassieke replay is uw reviewkosten de volledige speelduur op 1x — ruim drie uur aan echte tijd, of veel geduld zonder enige snelheidscontrole. Met de bezijker verandert de berekening. U opent de beëindigde partij uit uw geschiedenis; de bezijker haalt het gearchiveerde record en start de verwerkingsrun op de engine-worker. Voor een partij van die lengte en spelerdichtheid kost de verwerkingsrun op een moderne machine van de orde van één tot twee minuten, opgebouwd vanaf de 70 seconden voor een 26-minuten 25-spelerpartij; terwijl de verwerking loopt toont de onbewerkte staart van de tijdlijn zich grijs, en zoeken in het grijze springt terug — probeer dus niet verder te springen vóór de run klaar is. Zodra de verwerking klaar is, is de hele tijdlijn levend. U werkt vanaf het einde: zet de snelheid op 16x of 32x en veeg terug vanaf de finish, terwijl u de terreinen en eenheden in een tiende van de kosten volgt, tot het instortingsvenster verschijnt; ga voor de beslissende wissels naar 1x; gebruik de spatiebalk om een frame te bevriezen terwijl u een eenheidenaantal of een vlag leest, en Shift+links om 100 frames terug te springen — tien ticks op het tempo van 10 ticks per seconde — wanneer één stap de moment mist. De opgeslagen replay van een partij van die omvang landt ergens in de tientallen MB, ver binnen het 256 MB-budget; de specifieke getallen hangen af van kaart, duur en gebeurtenisdichtheid, maar de benchmark geeft u de schaal: lange, drukke partijen kosten echte opslag, korte kosten bijna niets. De reviewvraag die u nu kunt stellen en voordien niet goedkoop kon stellen is een causale — welke beslissing, genomen op welke minuut, produceerde de ineenstorting — en het antwoord komt in minuten in plaats van in uren. Dat is het hele product in één workflow: eenmaal verwerken, snel vegen, traag zoomen, de specifieke frame verifiëren. En omdat de reviewvraag hier causaal is in plaats van cosmetisch, is de ene uitkomst die het waard is op te schrijven de exacte speltijd waarop het verraad zichtbaar werd — niet „ergens in het derde uur” maar een tijdstip waar uw toekomstige zelf in seconden naar kan springen. In een 25-speler FFA is de aantekening van wie met wie bondgenoot was impliciet in gedrag, dus als de moment op 1x ambigu is, is de frame-voor-frame stap met de spatiebalk de scheidsrechter: bevries de frame, lees de vlaggen en de eenheidsrichtingen, en pas dan beslis u of de breuk een voorgeplande aanval was of een gedwongen retirade. Die onderscheid — bewuste verraad versus wanhoop — is wat uw volgende lobby-alliantiepolitiek verandert, en het is het soort oordeel dat de oude lineaire replay voor een partij van deze lengte bijna onmogelijk maakte.

Scenario twee: de mobiele tweede doorgang — verwerken op de computer, springen de volgende ochtend

Het tweede scenario is korter maar net zo beslist: u wilt een partij die u gisteravond speelde vanmorgen snel herijken, maar uw laptop zit in de la en uw telefoon is het enige apparaat binnen bereik. Met de klassieke replay kon u dat niet goedkoop: u had de partij op een machine moeten afspelen en kon niet naar een specifieke minuut springen. Met de bezijker opent u de partij op uw telefoon; de verwerkingsrun kost op een recente telefoon van de orde van een paar minuten voor een normale teampartij, en zodra de run klaar is kunt u in de tijdlijn springen en met 16x of 32x het venster vinden dat u zoekt, en met de spatiebalk de frame bevriezen terwijl u de aantekening maakt die u gisteravond miste. De opgeslagen replay van een teampartij is veel kleiner dan die van een FFA, dus het 256 MB-budget op de telefoon is zelden de beperkende factor; de beperking is eerder het batterijniveau tijdens de verwerkingsrun, en dat is de reden om de run te laten aflopen terwijl de telefoon aan de lader zit. De waarde van dit scenario zit in het feit dat de verwerking eenmalig is per apparaat: zodra de run op de telefoon klaar is, is elke latere opening van dezelfde partij op dezelfde telefoon bijna onmiddellijk, en u hoeft de verwerkingsrun niet nog eens te betalen wanneer u de volgende ochtend terugkomt. Dat maakt de „eenmaal verwerken, terugkomen voor het details” workflow veilig, en precies die workflow is wat de bezijker van een video-speler onderscheidt: de sprong bestaat om de specifieke vraag te beantwoorden die u de ochtend nog moet beantwoorden, en het antwoord is alleen bruikbaar als u het op het apparaat kunt openen dat u dat moment bij de hand heeft. De twee praktijken die dit scenario het meest versterken zijn het de run laten draaien terwijl de telefoon op de lader zit — de verwerkingsrun is de duurste stap en vraagt het meeste batterij, dus een opgeladen telefoon die de hele ochtend open kan blijven zonder te stoppen — en het de aantekening direct tijdens het bekijken schrijven in plaats van achteraf uit het geheugen, want het getal dat u op de bevroren frame las — het eenheidsaantal, de speltijd, de vlag — is het enige dat de volgende lobby daadwerkelijk verandert. Een fout die u uit het geheugen herschrijft verliest die getallen en wordt een vage herinnering; een getal dat u tijdens het 1x-bevriezen noteert is reproduceerbaar en kan de volgende ochtend in seconden worden nagecheckt door naar dezelfde speltijd te springen.

Falingsmodi en tegenmaatregelen: wat misgaat en hoe u het oplost

De bezijker voegt een verwerkingsstap toe aan een route die voorheen nooit kon falen, en die nieuwe stap is waar de meeste problemen zitten. De eerste en meest voorkomende falingsmodus is dat de verwerkingsrun een partij niet kan verwerken omdat de build die de partij speelde niet meer live is of de engine een incompatibele versie heeft; de klassieke replay faalt op dezelfde manier, maar de bezijker maakt het probleem zichtbaarder omdat u een halfvolle, grijze tijdlijn ziet in plaats van simpelweg een lege speelsessie. De tegenmaatregel is om de versiegrens te kennen: de bezijker is het beste in staat om partijen van de huidige en onlangs afgetakte builds te verwerken, en voor oudere partijen moet u controleren of de build nog bereikbaar is. De tweede falingsmodus is geheugen- of opslagoverstijging: een zeer lange, zeer dichte partij kan een opgeslagen replay produceren die dicht bij het 256 MB-plafond landt, of de verwerkingsrun kan op een zwak apparaat te veel geheugen vragen; in dat geval ziet u een fout in plaats van een grijze tijdlijn die vult. De tegenmaatregel is om op een krachtigere machine te verwerken, of om de partij in de klassieke replay af te spelen in plaats van de bezijker te forceren. De derde falingsmodus is dat u probeert naar een grijs, niet-verwerkt deel van de tijdlijn te springen; de bezijker springt terug naar het laatste verwerkte punt in plaats van verder te gaan, wat er toe kan leiden dat u denkt dat er een sprong gemist is terwijl in feite de verwerking nog bezig is. De tegenmaatregel is simpel: wacht tot de verwerkingsrun klaar is vóór u in het grijze gebied springt, en gebruik de grijze indicatie als een signaal dat u nog moet wachten. De vierde falingsmodus is dat u de bezijker op een apparaat opent dat de verwerkingsrun niet kan afronden binnen een redelijke tijd, meestal een oudere telefoon met een zwakke CPU; de tegenmaatregel is om de run te laten aflopen terwijl het apparaat aan de lader zit en niet onderweg, of om de review op een krachtiger apparaat uit te voeren. De vijfde en subtielste falingsmodus is dat u de bezijker gebruikt voor een vraag waar de klassieke replay goedkoper voor is: als u de hele partij van begin tot eind wilt herbekijken, betaalt u de verwerkingsstap voor een taak die de klassieke replay zonder die stap kon uitvoeren, en dan is de bezijker een extra kostenpost zonder extra waarde. De tegenmaatregel is het besliskader hierboven: gebruik de bezijker voor het lokaliseren van een specifiek moment, en gebruik de klassieke replay voor een volledig herbekijken. De gemeenschappelijke noemer van alle vijf is dat de bezijker een eenmalige verwerkingsinvestering is die zich alleen betaalt wanneer de reviewvraag een specifiek moment vereist; als u die reviewvraag niet hebt vóór u de schakelaar aanzet, dan is de klassieke replay de goedkopere en minder kwetsbare route.

Afspelen en besturen: de volledige toetsen- en snelheidsreferentie

De bezijker is toetsenbord-vanaf-ontwerp en het hele besturingsoppervlak is klein genoeg om in een tabel te passen. Het verwerkingstempo daaronder is 10 ticks per seconde, dus een frame is één tick van de simulatie — tien frames is één echte spelseconde — en elke sprong, stap en snelheid hieronder is gedefinieerd tegen die basis.

Een paar notities maken de tabel bruikbaar. Ten eerste is de frame-stap exact: bij 10 ticks per seconde is een enkele pijlrechts een tiende van een spelseconde, en Shift+pijlrechts is tien spelseconden — de constante van 100 frames is gekozen zodat een ingedrukte Shift in een paar drukken een betekenisvolle span overdekt. Ten tweede worden de toetsen opzettelijk genegeerd terwijl een instellingenmenu open staat — de release notities noemen dit als een correctie, zodat het zoeken naar de schakelaar midden in de bekijk de tijdlijn niet per ongeluk aanstoot. Ten derde zijn de snelheden vermenigvuldigd over de echte tijd, dus 32x speelt een 10-tick-per-seconde simulatie af op 320 ticks per seconde; de renderer en de ontcodde frames houden bij, maar behandel 32x als een scantempo om te zien waar iets gebeurde, niet als een tempo waarop u eenheidenaantallen leest. Ten vierde is het springen in de onbewerkte staart geen foutconditie waar u zich zorgen over moet maken: de staart is grijs precies omdat die nog niet bestaat, en een sprong daarin springt terug naar de laatste verwerkte frame. Het juiste gedrag is om de run klaar te laten lopen en dan te springen; de bezijker neemt dat niet voor u over. Ten vijfde is de afspeeltoestand lokaal aan de bezijkerspagina: als u de tab midden in de bekijk sluit, verliest u de afspeelkop maar niet het werk — de opgeslagen replay blijft in IndexedDB en de volgende opening begint vanaf het begin met onmiddellijke frame-toegang, wat de „eenmaal openen, later terugkomen” workflow die in de scenario’s wordt beschreven veilig maakt. Ten zesde zijn dezelfde toetsen dood binnen het instellingenoverlay: de release notities hebben specifiek het geval gecorrigeerd waarbij het indrukken van een zoektoets terwijl u naar een schakelaar zoekt de tijdlijn achter het menu stil aanstoot, dus als uw pijlen onresponsief lijken, controleer dan of een instellingenpaneel nog open is en sluit het vóór u aanstoot. Ten zevente is de snelheidskeuze kleverig voor de sessie — hij wordt niet heropgezet wanneer u het instellingenmenu sluit — wat handig is voor het „vegen op 32x, dan afzakken naar 1x” patroon en alleen hinderlijk als u vergeten bent dat u hem op 32x had laten staan; als een replay lijkt voorbij te vliegen zonder dat u dat hebt gekozen, is de snelheid de eerste verdachte.

Aanpassingen per modus en kaart: wat FFA, team en solo elk anders opleveren

De modus bepaalt het meeste over hoe u de bezijker inzet en hoeveel u de bevindingen moet wegen. In FFA is de bezijker het waardevolst omdat de partijen lang en dicht zijn en omdat de alliantievraag — wie bondgenoot was met wie en op welk moment brak die vrede — exact de vraag is die de bezijker beantwoordt; de 25-speler 3-uur FFA uit het scenario hierboven is de extreme, maar zelfs een 12-speler FFA van een uur of een half uur levert een opgeslagen replay op die de moeite van het verwerken waard is. In team-spel is de bezijker vooral bruikbaar voor het lokaliseren van een specifieke fout — een te late rotatie, een verkeerde doelaanval, een gemiste steun — omdat de partij korter is en de vraag specifieker; de reviewvraag is dan minder over alliantiepolitiek en meer over executie, en de bezijker beantwoordt die vraag in minuten in plaats van in een volledig herbekijken. In solo of kleinere formaties is de reviewwaarde per opening het laagst omdat de partijen kort zijn en het lineaire herbekijken al goedkoop was; de bezijker werkt er nog steeds, maar de eenmalige verwerkingsstap betaalt zich minder vaak terug. De modus bepaalt ook hoe u de bevindingen weegt: in team-spel is de bevinding onderdeel van uw bewijs voor de volgende lobby, in FFA is de causale sprong het waardevolste deel, en in solo is de bezijker voornamelijk een hulpmiddel om de eigen fouten te vinden. De kaart is de tweede variabele die u in uw eigen workflow niet onderschatten moet: een grote, dichte kaart kan een replay produceren die dicht bij de 256 MB-grenze ligt, terwijl een kleine kaart een replay oplevert die bijna niets kost; de gedocumenteerde benchmark van 24 MB voor een 26-minuten 25-spelerpartij geeft u de schaal, maar de specifieke kaart en duur bepalen de exacte opslag. De praktische consequentie is dat u de bezijker per modus en per kaart anders inschat: in een grote FFA-kaart is de bezijker een must-have voor elke partij die u wilt herijken, in een kleine team-kaart is hij een selectief instrument, en in solo is hij meestal overbodig. Die inschatting is wat het verschil maakt tussen de bezijker als standaardworkflow en de bezijker als uitzondering, en die inschatting baseert u op de modus en de kaart vóór u de schakelaar aanzet. Als u twijfelt welke kant een specifieke kaart uitgaat — groot en dicht of klein en dun — is de snelle test de geschatte spelerdichtheid vermenigvuldigd met de partijlengte: een dichte kaart met veel spelers die lang duurt is het profiel dat dicht bij de 256 MB-grens kan komen, en daar kiest u de bezijker alleen voor de partijen die het herijken waard zijn; een dunne kaart die kort duurt is vrijwel altijd goedkoop genoeg dat u de schakelaar gewoon aan kunt laten staan zonder per-partij afweging.

Review-workflow: maak van de bezijker een herhaalbare gewoone na elke partij

De bezijker is het meest waardevol wanneer u hem niet als een eenmalig hulpmiddel gebruikt maar als een vaste stap in uw na-elke-partij ritueel. De vijf-staps workflow die u elke keer kunt herhalen begint met het opslaan: zodra de partij is beëindigd, opent u hem vanuit uw geschiedenis met de bezijker ingeschakeld, zodat de verwerkingsrun start terwijl u nog vers bent en de vragen die u heeft nog scherp zijn. De tweede stap is het snel terugvegen: zet de snelheid op 16x of 32x en veeg terug vanaf de finish terwijl u alleen op de grote overwinningsevents let — terreinwinsten, verlies van hoofdvestigingen, en de moment waarop de voorsprong definitief omsloeg. De derde stap is het inschakelen op 1x: zodra u het venster heeft gevonden, zet u de snelheid terug naar 1x en bevriest u de frame met de spatiebalk terwijl u de causale vraag stelt: welke beslissing, door wie, op welk moment, produceerde deze wending. De vierde stap is het opschrijven: noteer de exacte speltijd van het moment dat u gevonden heeft, niet een vage omschrijving, zodat u de volgende keer direct kunt springen naar dat tijdstip in plaats van opnieuw te zoeken. De vijfde stap is het toepassen: neem de ene bevinding die het meest uw volgende lobby zou veranderen en maak er een concrete aanpassing van — een andere rotatietiming, een andere alliantiekiezen, een andere doelaanval. Exact deze vijf-staps doorloop is wat het eenvoudige navigeren van een replay verandert in een herhaalbaar voordeel in de volgende lobby, en het is de reden waarom de bezijker een investering in uw review is in plaats van een eenmalige bekijk. De gemeenschappelijke noemer van de hele workflow is dat u de bezijker gebruikt om de specifieke vraag te beantwoorden die u de ochtend nog moet beantwoorden, en dat u die beantwoording opschrijft zodat u de volgende keer sneller kunt springen naar hetzelfde type moment. Dat maakt de bezijker van een spelhulpmiddel om een reviewhulpmiddel, en dat is de verschuiving die de meeste spelers niet maken: ze gebruiken de bezijker om te kijken in plaats van om te leren, en dan betalen ze de verwerkingsstap voor iets dat ze niet in hun volgende lobby zouden gebruiken. De bredere toetsenoppervlak voor de live-kant van uw spel zit in de Hotkeys gids, en de reviewmethode die deze workflow codificeert staat in de Replay Review gids: dit blad bezit de na-de-partij kant, van het moment dat een partij eindigt tot het moment dat u één concrete volgende-partij aanpassing hebt. Alles hierboven is gegrond in de v0.35.2 bron en de v0.35.0 release: de v0.35.0 release noemt de ~20 ms seek en de opt-in rollout, en de tag-bron fixeert de 256 MB-grens, het tempo van 10 ticks per seconde, de 0,5x-32x snelheidslijst en het exacte toetsenbordgedrag dat in de tabel wordt beschreven.