OpenFront — Springbarer Replay-Viewer (v0.35.0): einschalten, zu jedem Moment springen, ohne die ganze Partie zu wiederholen

Direkte Antwort: Schalten Sie „New Replay Viewer” in den Einstellungen ein und öffnen Sie eine beendete Partie, um darin zu navigieren

Die v0.35.0-Freigabe hat den linearen Replay, den Sie bisher von Anfang bis Ende abspielten, durch einen springbaren Viewer ersetzt, und er wird optional ausgeliefert. Bei deaktiviertem Schalter öffnet „Watch replay” weiterhin den klassischen Replay, und der einzige Ausweg ist die Option New Replay Viewer im Einstellungsmenü. Diese Option liest die interne Einstellung settings.replayViewer, die standardmäßig deaktiviert ist. Sobald sie aktiv ist, landet jede beendete Partie, die Sie aus Ihrem Verlauf öffnen, im Viewer. Das Prinzip: Der Viewer verarbeitet das archivierte Spielprotokoll ein einziges Mal, in Ihrem Browser, auf dem Engine-Worker selbst — demselben Worker, der auch Live-Spiele antreibt. Nach diesem einmaligen Verarbeitungsdurchlauf kostet jeder Sprung auf der Zeitachse nur etwa 20 ms, weil die gesamte Partie bereits entschlüsselt und im lokalen Speicher liegt. Die Tastenbefehle sind bewusst minimal gehalten: Leertaste spielt oder pausiert, die Pfeiltasten springen vor oder zurück jeweils eine Frame, und das Gedrückthalten der Umschalttaste zusammen mit einem Pfeil springt 100 Frames. Das Geschwindigkeitsmenü bietet 0,5x, 1x, 2x, 4x, 8x, 16x und 32x. Es gibt auch eine Direktlink-Form, #replay-viewer=<gameID>, die den Viewer öffnet, selbst wenn die Option deaktiviert ist. So können Sie einen Link teilen, der direkt in die springbare Ansicht gelangt. Es passiert dabei nichts auf dem Server; der Server stellt nur das archivierte Protokoll bereit. Falls Sie nur eine Geste behalten: Schalten Sie die Option einmal ein, öffnen Sie eine lange beendete Partie aus Ihrem Verlauf und lassen Sie den Verarbeitungsdurchlauf vor Ihrer Bewertung enden. Die erste Öffnung ist langsam per Design, und jede nachfolgende Öffnung derselben Partie auf demselben Gerät ist nahezu augenblicklich, weil der verarbeitete Replay in IndexedDB gespeichert ist.

Eine ehrliche Erwartung gehört dazu: Der Viewer ist ein Analysewerkzeug, kein neuer Weg, Live-Spiele zu schauen. Er funktioniert nur auf beendeten Partien, fügt einen Verarbeitungsschritt hinzu, der dem alten Weg fehlte, und verlangt echten Speicher von Ihrem Browser. Das Store begrenzt das entschlüsselte Archiv bei 256 MB, um bescheidene Hardware zu schützen, und eine sehr große Partie, die dieses praktische Budget überschreitet, wird in einer bereits belasteten Sitzung schlicht nicht entschlüsselt. Anders gesagt: Sie erhalten das Springen nicht umsonst. Im Gegenzug akzeptieren Sie einen einmaligen Verarbeitungsdurchlauf pro Partie und pro Gerät, und genau diesen Tausch zerlegt der Rest dieser Seite in Einzelteile, einschließlich der Grenzen der Versionsbindung, der Speicherrechen und der ehrlichen Grenze der unbestätigten Aufnahmen. Wenn Sie das einzige Merkmal in dieser Seite in Ihrer eigenen Praxis behalten sollen, ist es genau diese Tauschlogik: Sie zahlen einmal pro Gerät und pro Partie, und Sie erhalten danach einen unbegrenzten Zugriff auf jede Sekunde der Partie. Das ist der Kern, und alles Weitere — Tasten, Geschwindigkeiten, Speicher, versionsgebundene Hülle — sind nur die praktischen Umsetzungsfragen, die Sie entscheiden, bevor Sie den Viewer in Ihren eigenen Nachanalyse-Workflow aufnehmen.

Versionsgrenze: Was v0.35.0 geändert hat, was nicht, und wo der Viewer sich noch aufhält

Diese Funktion wurde in v0.35.0 ausgeliefert. Die Releases v0.35.1 und v0.35.2 waren Bugfixes ohne neue Replay-Funktionalität. Die Spielmechanik selbst hat sich nicht geändert — dieselben Runden, dieselben Zahlen. Was sich geändert hat, ist die Oberfläche um die Wiedergabe herum und wie der Client ein altes Protokoll in eine springbare Wiedergabe verwandelt. Der Verarbeitungsdurchlauf ist die neue, zusätzliche Komponente: Der Viewer entschlüsselt das archivierte Protokoll auf dem Engine-Worker und legt es in einen lokal geprüften Speicher (IndexedDB) unterhalb eines 256-MB-Limits, wobei die entschlüsselte Größe beim Öffnen gemessen wird. Der Viewer ist opt-in; der Standardpfad „Watch replay” bleibt der klassische, lineare Replay, und der alte Weg hat keine Geschwindigkeitsmenü. Die Tastenbefehle sind die neuen; sie greifen nur, wenn der Viewer-Modus aktiv ist und kein Menü offen ist, was sie ignorieren.

Die Grenze, die die meisten Leute zuerst treffen, ist die Versionsbindung. Der Viewer liest die Aufnahmen so, wie der aktuelle Client sie liest. Wenn eine Partie in einer älteren Version gespielt wurde, führt der neue Client diese Version nicht aus. Das war der genaue Schmerz, den ein Community-Thread im November 2025 auf blue.openfront.io dokumentierte, wo eine Seite mit der alten Version die alten Aufnahmen zum Abspielen beibehielt, bis sie offline ging, woraufhin ein älterer Replay für immer unspielbar wurde. Das Produkt hat diese Grenze in v0.35.0 in eine allgemeine Routingregel verwandelt: Wenn eine beendete Partie einer alten Version zugeordnet ist, leitet die Hauptseite sie an eine versionsgebundene Hülle weiter — in der Praxis replay.<domain> — die eine Kopie des alten Client-Builds beibehält, sodass die alte Partie mit den alten Regeln wieder abspielt. Die Hülle ist eine Gnadenfrist, kein Safe: Sehr alte Builds werden irgendwann nicht mehr gehostet, und wenn die Kopie weg ist, kann kein Client, alt oder neu, das Protokoll entschlüsseln und die Partie ist nicht wiederherstellbar. Der direkte #replay-viewer=-Link ist die Ausnahme: Er zwingt den Viewer-Modus an und öffnet die Partie auch, wenn die Einstellung deaktiviert ist, und leitet sie bei Bedarf an dieselbe versionsgebundene Hülle weiter. Der praktische Punkt, den die meisten Spieler am Anfang unterschätzen, ist, dass die versionsgebundene Hülle kein separater Service ist, den Sie aktivieren müssen, sondern eine automatische Weiterleitung, die der Client übernimmt, sobald er erkennt, dass der Build der Aufnahme nicht der aktuelle ist. Das bedeutet, dass Sie keinen zweiten Link speichern müssen und keine separate Seite besuchen, sondern dass derselbe Verlaufseintrag, den Sie normalerweise öffnen, automatisch an den richtigen Ort weiterleitet, sobald die Version nicht mehr übereinstimmt. Die einzige Konsequenz, die Sie selbst tragen, ist die Geduld, die Sie dem alten Build gönnen, der geladen wird, und die Tatsache, dass dieser Build irgendwann weg ist, wenn die Kopie nicht mehr gehostet wird.

Entscheidungsrahmen: Wann sich der Viewer lohnt, wann der klassische Replay immer noch ausreicht

Die ehrliche Frage ist nicht „ist springen besser?”, sondern „ist der Tausch für meine Partie zu meinem Zweck” lohnend? Der Tausch hat eine einmalige Kosten- und einen wiederkehrenden Ertrags-Teil. Die Kosten sind: erstens ein Verarbeitungsdurchlauf, der beim ersten Öffnen der Partie auf diesem Gerät stattfindet — für eine lange, dichte 25-Spieler-Partie dokumentiert die v0.35.0-Freigabe einen Verarbeitungsdurchlauf von 70 Sekunden; zweitens lokaler Speicher bis zu 256 MB, aufgeteilt zwischen Ihrer Maschine und Ihren anderen Geräten; und drittens die versionsgebundene Hülle als Gnadenfrist, die die Langlebigkeit von Aufnahmen begrenzt. Der Ertrag ist: erstens Sprünge zu etwa 20 ms statt stundenlanger linearer Wiedergabe; zweitens Geschwindigkeitsstufen von 0,5x bis 32x, die auf dem alten Weg nicht existierten; und drittens eine Bestätigung der Integrität — der Viewer berechnet Prüfsummen während der Wiedergabe und markiert eine Aufnahme als bestätigt, wenn sie zu den Hashes passt, die die Live-Clients aufzeichneten, mit einer Checkpoint-Frequenz von einem Checkpunkt pro 10 Runden im Mehrspielermodus.

Die Entscheidungsregel: Wenn Ihre Frage zeitlich verortbar ist — eine einzelne Entscheidung, ein Moment, ein Taktikfehler — ist der Viewer fast immer lohnend, weil der Sprung direkt zur Minute geht, die Sie brauchen, und die Geschwindigkeitsstufen das Durchsuchen billiger machen. Wenn Ihre Frage aggregiert ist — wie haben sich meine Runden über eine Stunde verteilt — ist der klassische lineare Replay oft der ehrlichere Pfad, weil ein Sprung nicht automatisch aggregiertes Denken ersetzt und ein einzelner Moment, den Sie finden, nicht die Gesamtverteilung beantwortet. Wenn Sie die Partie mit jemandem live durchgehen und sie synchron abspielen müssen, ist der lineare Replay der einfachere Ort, weil das Synchronisieren von Sprüngen zwischen zwei Geräten mit der versionsgebundenen Hülle und dem per-Gerät-Speicher umständlich ist. Wenn Sie eine Partie wiederholt analysieren werden — ein Coaching-Szenario oder ein wiederkehrendes Teamproblem — ist der Viewer am wertvollsten, weil die einmaligen Kosten mit jeder Öffnung sinken und jede nachfolgende Öffnung auf demselben Gerät von IndexedDB aus nahezu augenblicklich springen kann. Wenn Sie eine dieser vier Kategorien in einem einzigen Satz zusammenfassen, ist die ehrlichste Zusammenfassung: Der Viewer ist lohnend, wenn Sie eine Frage haben, die auf eine Sekunde hinweist, und er lohnt sich nicht, wenn Ihre Frage auf eine Verteilung hinweist. Das ist der Test, den Sie in Ihrem eigenen Kopf anwenden können, bevor Sie den Viewer überhaupt öffnen, und er hält für die meisten Partien, die Sie analysieren werden, weil die meisten Analysefragen tatsächlich auf einen Moment hinweisen, der gefunden werden muss, und die wenigen, die auf eine Verteilung hinweisen, sind oft die, bei denen Sie bereits wissen, dass Sie die ganze Partie wiederholen müssen.

Szenario eins: Die 25-Spieler-FFA über 3 Stunden — einen Verrat finden, ohne drei Stunden zu wiederholen

Gehen Sie von der Situation aus, die ein Community-Thread im November 2025 beschrieb: eine lange FFA mit hoher Spielerdichte, die zwei Stunden weit überschritten hat, mit einem Zusammenbruch am Ende, den Sie einem bestimmten verbündeten Spieler zuschreiben, der verraten hat. Mit dem klassischen Replay ist Ihr Analyse-Kosten die volle Spieldauer bei 1x — etwa drei Stunden Echtzeit, oder viel Geduld ohne jeden Geschwindigkeitsbefehl. Mit dem Viewer ändert sich die Rechnung. Öffnen Sie die beendete Partie aus Ihrem Verlauf; der Viewer holt das archivierte Protokoll und startet den Verarbeitungsdurchlauf auf dem Engine-Worker.

Für eine Partie dieser Länge und Dichte dauert der Durchlauf auf einer aktuellen Maschine etwa eine bis zwei Minuten, ausgehend von den 70 Sekunden für eine 26-minütige 25-Spieler-Partie. Während des Verarbeitens erscheint die unverarbeitete Queue der Zeitleiste grau, und darin zu navigieren springt zurück — versuchen Sie also nicht, weiter zu springen, bevor der Durchlauf beendet ist. Wenn das Verarbeiten fertig ist, ist die ganze Zeitleiste lebendig. Arbeiten Sie von hinten: Stellen Sie die Geschwindigkeit auf 16x oder 32x und durchsuchen Sie rückwärts vom Ende, während Sie das Gebiet und die Einheiten in einem Zehntel der Kosten verfolgen, bis das Fenster des Zusammenbruchs erscheint. Gehen Sie für den entscheidenden Austausch auf 1x herunter. Verwenden Sie Leertaste, um eine Frame einzufrieren, während Sie eine Einheitenzahl oder eine Flagge lesen, und Umschalttaste plus linker Pfeil, um 100 Frames zurückzuspringen — zehn Ticks bei 10 Ticks pro Sekunde — wenn ein einzelner Schritt den Moment verfehlt.

Der gespeicherte Replay einer Partie dieser Größe landet irgendwo im Bereich von einigen Dutzend MB, gut innerhalb des 256-MB-Budgets. Die exakten Zahlen hängen von Karte, Dauer und Ereignisdichte ab, aber der Benchmark gibt die Skala: Lange, dichte Partien kosten echten Speicher, kurze fast nichts. Die Analysefrage, die Sie jetzt stellen und zuvor nicht zu einem vernünftigen Preis hätten stellen können, ist kausal — welche Entscheidung, in welcher Minute, hat den Zusammenbruch verursacht — und die Antwort kommt in Minuten statt Stunden. Genau dieser Wechsel von „Ich schaue alles” zu „Ich springe zum Moment” ist der Spielveränderer, und er funktioniert nur, weil das Verarbeiten einmal pro Gerät stattfindet und jeder Sprung danach auf die bereits entschlüsselte Partie wirkt statt auf das rohe Protokoll. Wenn Sie diese Rechnung auf eine echte 25-Spieler-FFA über drei Stunden anwenden, ist der Tausch so klar, dass er sich fast wie eine Selbstverständlichkeit anfühlt: Sie sparen zwei Stunden und fünfzehn Minuten lineare Wiedergabe gegen einen ein- bis zweiminütigen Verarbeitungsdurchlauf, und der gesparte Zeitraum ist so groß, dass er jede nachfolgende Entscheidung in diesem Szenario — wie viel Speicher Sie verwenden, ob Sie die versionsgebundene Hülle riskieren — relativ klein macht.

Szenario zwei: Der zweite Durchgang am Handy — auf dem Desktop verarbeiten, am nächsten Morgen am Telefon springen

Das zweite Szenario ist das, das das alte Pattern des Versionslock-Pain durchbricht. Sie beenden eine kompetitive Team-Partie am Vorabend auf dem Desktop, den Viewer aktiviert, und öffnen sie einmal, damit der Verarbeitungsdurchlauf abgeschlossen ist und der Replay auf dieser Maschine in IndexedDB landet. Am nächsten Morgen sind Sie am Telefon und möchten einen einzigen Übergang prüfen. Wenn der Build der Aufnahme noch der aktuelle ist, wird die Öffnung auf openfront.io desselben beendeten Spiels auf dem Telefon einen eigenen Verarbeitungsdurchlauf starten. IndexedDB-Speicher ist pro Gerät, daher wandert der Desktop-Cache nicht mit — und danach ist der Sprung verfügbar. Auf einem Telefon dauert der Verarbeitungsdurchlauf für eine typische Team-Partie kurz, aber real, öffnen Sie ihn also einmal und lassen Sie ihn enden, bevor Sie springen.

Die versionsgebundene Grenze tut dann ihre Arbeit: Wenn über Nacht eine Seitenaktualisierung gelandet ist und der Build der Aufnahme nicht mehr der Live-Build ist, leitet die Hauptseite die Aufnahme an ihre versionsgebundene Hülle weiter. Die Hülle beibehält den alten Build, sodass der Replay weiterhin mit den alten Regeln öffnet — derselbe Mechanismus, den der November-2025-Thread auf blue.openfront.io entdeckte, jetzt auf replay.<domain> verallgemeinert. Die praktische Regel: Für eine Partie, die Sie am nächsten Morgen sicher brauchen, öffnen Sie sie auf Ihrer besten Maschine noch am selben Abend, bevor eine Aktualisierung landen kann, und die Aufnahme ist an einen Build gepinnt, dessen Existenz Sie kennen. Wenn die Aktualisierung bereits gelandet ist, prüfen Sie, ob die Hülle den Build noch hostet — sehr alte Builds werden irgendwann nicht mehr gehostet, und wenn die Kopie weg ist, kann kein Client das Protokoll entschlüsseln und die Partie ist nicht wiederherstellbar. Behandeln Sie die versionsgebundene Hülle als Gnadenfrist, nicht als Safe.

Eine weitere Grenze, die zu diesem Szenario gehört: Die Bestätigungsprüfung prüft die Hashes, die die Live-Clients aufzeichneten, mit einer Frequenz von einem Checkpunkt pro 10 Runden im Mehrspielermodus, sodass ein Mehrspieler-Replay einer Team-Partie dicht geprüft wird. Und wenn die Aufnahme ohne ihre Hashes ankommt, markiert der Viewer sie auf dem Bildschirm als unbestätigt, zeigt den Hinweis „This game’s record has no checks, so this replay couldn’t be verified against the game that was played” und speichert sie absichtlich nicht. Ein unbestätigter Replay ist ansehbare, aber nicht vertrauenswürdig und nicht gecacht, was der richtige Kompromiss ist: Sie würden ein verdächtigtes Protokoll lieber neu verarbeiten, als es stillschweigend zu cachen. Die praktische Konsequenz all dessen ist, dass Sie auf dem Telefon dieselbe Analyse machen können, die Sie auf dem Desktop machen würden, mit der einen Ausnahme, dass der erste Verarbeitungsdurchlauf auf dem Telefon etwas länger dauert. Wenn Sie eine Partei am Vorabend auf dem Desktop verarbeitet haben und am nächsten Morgen nur auf dem Telefon sind, ist die versionsgebundene Hülle der Teil, der dafür sorgt, dass die Aufnahme überhaupt noch geöffnet werden kann, und der per-Gerät-Speicher ist der Teil, der dafür sorgt, dass Sie den Verarbeitungsdurchlauf auf dem Telefon erneut durchlaufen.

Fehlerszenarien und Gegenmaßnahmen: Was kaputt geht und was Sie dagegen tun

Die Partie ist in einer alten Version — das häufigste Szenario. Der Viewer liest Aufnahmen so, wie der aktuelle Client sie liest, und der aktuelle Client führt den Code der alten Version nicht aus. Das Produkt leitet solche Partien an die versionsgebundene Hülle (replay.<domain>) weiter, die den alten Build beibehält, sodass der Replay mit den alten Regeln wieder abspielt. Die Grenze: Sehr alte Builds werden irgendwann nicht mehr gehostet, und wenn die Kopie weg ist, ist die Partie für keinen Client wiederherstellbar. Gegenmaßnahme: Analysieren Sie, während Sie es können, und öffnen Sie eine Partie, die Sie später brauchen, noch am selben Abend auf Ihrer besten Maschine, sodass der Verarbeitungsdurchlauf auf dem Build stattfindet, der Ihnen gehört, und der Replay in IndexedDB liegt.

Der Verarbeitungsdurchlauf dauert länger als erwartet — der 70-Sekunden-Benchmark der v0.35.0-Freigabe gilt für eine 26-minütige 25-Spieler-Partie auf einer aktuellen Maschine. Längere, dichtere oder schwächere Partien kosten mehr, und während des Verarbeitens erscheint die unverarbeitete Queue grau und springt zurück, wenn Sie darin navigieren. Gegenmaßnahme: Erhöhen Sie nicht die Geschwindigkeit und springen Sie nicht weiter, bis das Verarbeiten beendet ist — warten Sie den Durchlauf aus, und öffnen Sie die Partie auf Ihrer besten Maschine, wenn Sie es können, damit der erste Durchlauf der teuerste ist.

Das Replay-Größe überschreitet das 256-MB-Budget — das Store begrenzt das entschlüsselte Archiv bei 256 * 1024 * 1024 Bytes, gemessen beim Öffnen. Eine sehr große Partie in einer bereits belasteten Sitzung wird nicht entschlüsselt. Gegenmaßnahme: Prüfen Sie, wie viel Speicher Ihnen auf dem Gerät bleibt, und schließen Sie andere Speicher-fressende Reiter. Wenn eine Partie wirklich zu groß ist, ist der klassische lineare Replay der Fallback, der nicht denselben Speicherpfad nimmt.

Die Aufnahme ist unbestätigt — der Viewer berechnet Prüfsummen und markiert eine Aufnahme als bestätigt, wenn sie zu den Hashes passt, die die Live-Clients aufzeichneten. Wenn die Aufnahme ohne ihre Hashes ankommt, zeigt der Viewer den Hinweis und speichert sie nicht. Gegenmaßnahme: Ein unbestätigter Replay ist ansehbare, aber nicht vertrauenswürdig. Für einen Wettstreit, den Sie einem anderen Spieler zuweisen, ist der unbestätigte Replay die schwächere Beweislage, also notieren Sie die Version der Seite in Ihren Notizen, wenn Sie die Partie selbst aufgenommen haben.

Der Cursor überlebt die Schließung des Reiters nicht — die gespeicherten Replay-Daten überleben, aber Ihre aktuelle Wiedergabeposition innerhalb des Replays tut es nicht, weil der gespeicherte Index die Wiedergabeposition nicht speichert. Gegenmaßnahme: Notieren Sie die Frame- oder Zeitmarken der Momente, die Sie brauchen, bevor Sie den Reiter schließen, und öffnen Sie den Replay erneut, wenn Sie ihn wieder brauchen.

Wiedergabesteuerung: Die vollständige Tasten- und Geschwindigkeitsreferenz

Die Tasten- und Geschwindigkeitsbefehle sind der tägliche Teil des Viewers, und sie greifen nur, wenn der Viewer-Modus aktiv ist und kein Menü offen ist. Leertaste spielt oder pausiert. Der rechte Pfeil springt vor eine Frame, der linke Pfeil springt zurück eine Frame — ein einziger Tick bei der internen Rate von 10 Ticks pro Sekunde — und das Gedrückthalten der Umschalttaste zusammen mit dem Pfeil springt 100 Frames, was zehn Sekunden entspricht. Das Geschwindigkeitsmenü bietet sieben Stufen, 0,5x, 1x, 2x, 4x, 8x, 16x und 32x, und 32x ist die schnellste Stufe, die das Menü bietet.

Die gesamte Steueroberfläche ist klein genug, um in einer Tabelle aufzugehen. Die Verarbeitungsrate darunter beträgt 10 Ticks pro Sekunde, sodass ein Frame ein Tick der Simulation ist — zehn Frames sind eine reale Spielsekunde — und jeder Sprung, jeder Schritt und jede Geschwindigkeit darunter ist gegen diese Basis definiert.

Die Zeitleiste selbst ist die primäre Steueroberfläche. Die gespielte Partie zeigt eine Zeitleiste, in der Sie per Klick oder Zug an beliebige Stelle springen können, und die gesamte entschlüsselte Partie liegt in diesem Punkt im lokalen Speicher, sodass jeder Sprung die Partie auf den gewählten Frame auswirkt statt sie neu vom Anfang zu entschlüsseln. Während des Verarbeitungsdurchlaufs zeigt die Zeitleiste die unverarbeitete Queue grau, und darin zu navigieren springt zurück, bis der Durchlauf beendet ist. Die Geschwindigkeit, die Sie wählen, wird über Reiter hinweg gespeichert, sodass Ihre gewählte Wiedergabegeschwindigkeit bei einem späteren Öffnen wiederhergestellt wird. Der Viewer zeigt auch eine Bestätigung, wenn die Aufnahmeeinschreibung den Prüfsummen entspricht, die die Live-Clients aufzeichneten, und markiert eine Aufnahme als unbestätigt und zeigt den entsprechenden Hinweis, wenn die Aufnahme ohne ihre Hashes ankommt.

Die Zeitleiste selbst ist der Ort, an dem die meisten Ihrer Sprünge stattfinden, während die Tastenbefehle der Ort sind, an dem Sie fein justieren — Leertaste zum Einfrieren, Pfeile zum einzelnen Frame-Justieren, Umschalttaste zum 100-Frame-Block. Der gesamte Satz ist bewusst klein gehalten, damit er sich auf jeder Tastatur einprägen lässt, die Sie in der Partie nutzen. Sie werden die Stufen 16x und 32x am häufigsten verwenden, um den Moment zu finden, und dann auf 1x heruntergehen, um ihn zu lesen. Die Feinjustierung über die Pfeile ist der letzte Schritt, bevor Sie die Frame für Ihre Notizen einfrieren. Die gesamte Tasten- und Geschwindigkeitslogik ist darauf ausgelegt, dass Sie mit einer Hand navigieren und mit der anderen die Werte ablesen, die Sie gerade brauchen. Das bedeutet, dass Sie in einem typischen Nachanalyse-Durchgang den Großteil Ihrer Zeit auf der Zeitleiste verbringen werden, während Sie den Moment finden, und nur kurze Zeit auf die einzelnen Frame-Stufen umschalten, um den Moment zu prüfen, den Sie gefunden haben. Wenn Sie die Steuerung zum ersten Mal ausprobieren, ist der schnellste Weg, sich daran zu gewöhnen, eine kurze Solo-Partie zu öffnen und nur die drei Kernbewegungen zu üben: Leertaste, ein Pfeil und Umschalttaste plus Pfeil.

Modus- und Kartenanpassungen: FFA, Team und Solo holen jeweils einen anderen Wert

Der Tausch des Viewers wiegt unterschiedlich je nach Modus. In FFA (Free-For-All) ist das Durchsuchen am wertvollsten, weil eine 25-Spieler-FFA über zwei Stunden eine sehr lange und dichte Partie sein kann. Die Analysefrage ist oft kausal — ein einzelner Verrat, ein einzelner Taktikfehler — und der Sprung geht direkt zu dieser Minute, während die Geschwindigkeitsstufen 16x und 32x das Durchsuchen billiger machen. Der gespeicherte Replay einer solchen Partie ist der größte Speicherfall, und Sie sollten das 256-MB-Budget vor dem ersten Öffnen prüfen.

In Team-Spiel ist die Bestätigung der Integrität der Teil, der sich am meisten ändert. Ein Mehrspieler-Replay wird mit einer Frequenz von einem Checkpunkt pro 10 Runden geprüft, was für eine Team-Partie dicht ist, und die Bestätigung ist der Teil, der es als Beweismittel für einen Wettstreit zwischen Teammitgliedern qualifiziert. Der Analyse-Kosten ist niedriger als in FFA, weil die Partien kürzer sind, aber der Beweiswert ist höher, weil die Bestätigung den Replay als vertrauenswürdig markiert, vorausgesetzt, die Aufnahme hat ihre Hashes.

In Solo (gegen Bot) ist der Viewer der am wenigsten notwendige, weil die Partien kurz sind und der klassische lineare Replay sie in einer sauberen Durchsicht abspielt. Der Wert liegt stattdessen darin, dass Sie ein Solo-Szenario wiederholt durchspielen können, ohne jedes Mal die Wiedergabe von vorne zu starten, und der Sprung Sie direkt zu dem Moment bringt, der Sie interessiert. Was die Karten angeht, bestimmt die Karte die Größe des gespeicherten Replays durch ihre Dauer und Ereignisdichte — größere, dichtere Karten produzieren größere Aufnahmen, und der 256-MB-Budget ist die Grenze, an der eine Karte, die zu groß ist, ausfällt. Die praktische Regel: Prüfen Sie die Speichergröße Ihrer größten Karte, bevor Sie den Viewer auf ihr aktivieren, und wenn eine Partie das Budget überschreitet, ist der klassische lineare Replay Ihr Fallback. Der Modus bestimmt auch, wie viel Gewicht Sie der Bestätigung geben: In Team-Spiel ist sie Teil Ihres Beweismittels, in FFA ist sie nützlich, aber der kausale Sprung ist der wertvollste Teil, und in Solo ist sie praktisch irrelevant. Die Karte wiederum ist die zweite Variable, die Sie in Ihrem eigenen Workflow nicht unterschätzen sollten: Eine große, dichte Karte kann einen Replay produzieren, der nahe an der 256-MB-Grenze liegt, und in diesem Fall ist die Frage nicht, ob der Viewer funktioniert, sondern ob er auf Ihrer Maschine funktioniert, wenn der Speicher bereits durch andere Reiter belegt ist. Der praktische Test, den Sie vor dem ersten Öffnen einer neuen Karte durchführen können, ist, die gespeicherte Größe der letzten Partie auf derselben Karte zu prüfen und zu sehen, ob sie sich in der Nähe der Grenze befindet.

Analyse-Arbeitsablauf: Den Viewer in eine wiederholbare Nachanalyse-Gewohnheit verwandeln

Der Viewer ist ein Beweismittel, und die Gewohnheit, die ihn bezahlt, ist ein fester fünf-Schritte-Durchgang, den Sie auf jede Partie anwenden, die zählt. Schritt eins: Schalten Sie die Option einmal ein — New Replay Viewer in den Einstellungen — und denken Sie nie wieder darüber nach. Die Direktlink-Form #replay-viewer=<gameID> ist Ihr Ausweichplan, um eine navigierbare Ansicht mit jedem zu teilen, einschließlich Spielern, deren Option deaktiviert ist.

Schritt zwei: Öffnen Sie die beendete Partie aus Ihrem Verlauf am selben Abend, damit der Verarbeitungsdurchlauf auf Ihrer besten Maschine stattfindet und der Replay gespeichert bleibt, solange der Build sicher online ist. Diese eine Gewohnheit ist die gesamte Abwehr gegen den Versionslock-Pain, bei dem eine schöne Partie nach einer Aktualisierung über Nacht nicht mehr ansehbar wird. Schritt drei: Lassen Sie den Durchlauf enden, bevor Sie navigieren, und verwenden Sie die graue Queue als Fortschrittsindikator. Wenn Sie es eilig haben, ist der Durchlauf für Team-Partien kurz und Sie können gehen und zurückkommen — das Store erinnert sich.

Schritt vier: Durchsuchen Sie schnell und landen Sie langsam: 16x oder 32x, um das Fenster zu finden, 1x, um es zu lesen, Leertaste, um eine Frame einzufrieren, während Sie Zahlen prüfen, und Umschalttaste plus Pfeile, um Blöcke von zehn Sekunden zu verschieben. Notieren Sie die Frame- oder Zeitmarke des Moments, der zählt, weil der Cursor die Schließung des Reiters nicht überlebt. Schritt fünf: Wandeln Sie den Moment in eine testbare Änderung um, bevor die nächste Partie. Das ist genau die Analyse-Methode, die der Leitfaden Replay-Analyse codifiziert: Finden Sie die erste gebrochene Annahme am Moment, den Sie gerade lokalisiert haben, und ändern Sie genau eine Sache im nächsten Lobby.

Dieser letzte Schritt ist es, was den Viewer von einem Videoplayer unterscheidet. Der Sprung existiert, um „warum ist diese Entscheidung in genau dieser Sekunde gescheitert” zu beantworten, und die Antwort ist nur nützlich, wenn sie den nächsten Lobby ändert. Wenn Ihre Analysefrage darauf beruht, wie Sie im Allgemeinen spielen, statt auf einer Partie, ist die größere Steuerungsfläche des Leitfads Schnelltasten der Ort, an dem die Live-Gewohnheiten leben. Diese Seite deckt den Teil nach der Partie ab, vom Moment, in dem eine Partie endet, bis zu dem Moment, in dem Sie eine testbare Idee davon haben, was sich ändern soll. Genau dieser fünf-Schritte-Durchgang ist es, was das einfache Navigieren in einem Replay in einen wiederkehrenden Vorteil im nächsten Lobby verwandelt. Wenn Sie nur einen Schritt aus diesem Durchgang in Ihrer eigenen Routine beibehalten, ist es Schritt zwei — die beendete Partie noch am selben Abend auf Ihrer besten Maschine öffnen — weil dieser einzelne Schritt die gesamte Langlebigkeit der Aufnahme sichert und die einzige Aktion ist, die Sie vor dem ersten Springen ausführen müssen.