Bitte beachtet: Wir sehen in diesem Blogeintrag 30 FPS als Richtwert an, weil For Honor auf allen Plattformen problemlos mit diesem Basiswert läuft.
DIE ENTSTEHUNG VON TIME SNAP
Das Kampfsystem „die Kunst des Krieges“ war von Anfang an das Herzstück des Designs von For Honor. Darum ist es besonders wichtig für uns, dass die deckungsbasierten Angriffe und Blocks so klar und eindeutig wie möglich sind. Wir haben ein paar Beispiele von Problemen für euch zusammengestellt, mit denen wir zu Beginn der Spiel-Entwicklung zu tun hatten:
Video 1
In Video 1 seht ihr, wie die Änderung der Deckungsrichtung zum erfolgreichen Block eines Angriffs führt, wenn der verteidigende Spieler sie zum letztmöglichen Zeitpunkt ausführt.
Video 2
Wir verglichen das mit einem fehlgeschlagenen Block, bei dem der Verteidiger seine Deckungsrichtung 33 ms später gewechselt hatte. In Video 2 könnt ihr euch ein Bild davon machen. Wir fanden, dass der Unterschied nicht deutlich genug war und für Frust beim Verteidiger sorgen würde. Um den Unterschied klarer herauszuarbeiten, entschieden wir uns dafür, dass sich ein erfolgreicher und ein fehlgeschlagener Block um mindestens 100 ms unterscheiden sollten.
Dazu führten wir das sogenannte „Time Snap“-System ein, das die Aktionen aller Spieler für die nächsten 100 ms auf einer globalen Uhr festschrieb. Wie ihr in Grafik 1 sehen könnt, werden der Angriff von Spieler 1, der seine Taste 33 ms vor Spieler 2 betätigt hat, und der Angriff von Spieler 2 zur selben Zeit ausgeführt. In diesem Fall führt das zu einem Doppeltreffer.
PROBLEME MIT TIME SNAP
Das größte Problem mit Time Snap war, dass es zu einer zufällig anmutenden Verzögerung von 0 ms, 33 ms oder 66 ms kam, je nach dem, wann der Spieler seine Eingabe auf der globalen Uhr gemacht hat. Damals, wir waren immer noch im Entwicklungsstadium, empfanden wir die Auswirkungen als vernachlässigbar. Aber wir haben unsere Meinung bald darauf geändert.
Während wir weiter am Balancing gearbeitet haben, erreichte uns Feedback von den internen und externen Testern, das uns den Deckungswechsel überdenken ließ. Wir entschieden uns dafür, Time Snap für die Deckungswechsel zu entfernen, was einige Probleme mit verzögerten Reaktionen auf Steuerungseingaben behob. Leider warf es uns bei der Erreichung des eigentlichen Ziels, das wir mit Time Snap erreichen wollten, wieder deutlich zurück.
Nachdem das Spiel in den Verkauf gegangen war, haben wir schließlich beschlossen, Time Snap vollständig zu entfernen, um Unregelmäßigkeiten bezüglich der Reaktionszeiten auf Steuerungseingaben zu beheben. Weil das System gleichzeitig aber auch die Latenzzeiten des Netzwerks kompensiert hat, hätte die vollständige Entfernung Auswirkungen auf andere Gameplay-Elemente gehabt.
Sehen wir uns einige dieser Fälle an, um zu erklären, wie das System funktioniert hat, als es noch aktiv war. Der Einfachheit halber nehmen wir an, dass zwischen Angreifer und Verteidiger eine Netzwerk-Latenz von 100 ms besteht.
In Grafik 2 leitet der Angreifer nach 400 ms seinen Angriff ein, der sofort ausgeführt wird. Beim Verteidiger kommt diese Eingabe mit einer Verzögerung von 100 ms an. Er verpasst also die ersten 100 ms des Angriffs.
In Grafik 3 leitet der Angreifer nach 366 ms seinen Angriff ein, der Angriff wird dann bei 400 ms ausgeführt. Diese Eingabeverzögerung von 33 ms kompensiert einen Teil der Netzwerk-Latenz, sodass der Verteidiger nun nur noch die ersten 66 ms des Angriffs verpasst.
In Grafik 4 leitet der Angreifer nach 333 ms seinen Angriff ein, der Angriff wird dann bei 400 ms ausgeführt. Es kommt zu einer Eingabe-Verzögerung von 66 ms. Der Verteidiger verpasst damit nur noch die ersten 33 ms des Angriffs.
Weil diese Kompensierung der Netzwerk-Latenz aber rein zufällig und damit unzuverlässig geschah, führte sie zu einer Beeinträchtigung der Reaktionsfähigkeit des Verteidigers auf Angriffe. Bei 1 von 3 Fällen kam es zu keinem Latenzausgleich. Das Entfernen von Time Snap hätte also negative Auswirkungen auf die Reaktionsfähigkeiten der Spieler gehabt. Doch das Feedback der Community war eindeutig und so machten wir uns auf die Suche nach einer Lösung für den Informationsverlust, zu dem es durch die Abschaffung des Systems kam.
DERZEITIGE UMSETZUNG
Die hier vorgeschlagene Implementierung folgt einer Hybrid-Lösung: Alle Eingaben, die als „offensiv“ betrachtet werden (siehe Liste weiter unten), erfolgen mit einer festgelegten Verzögerung von 33 ms. Dieser Wert führt zu keiner spürbaren Auswirkung auf die Reaktionsgeschwindigkeit, da er lediglich „offensive“ Aktionen betrifft, die, schon aufgrund ihres Designs, ohnehin etwas länger dauern. Wie wir in Grafik 5 zeigen, wird ein Angriff, den der Angreifer aus der Untätigkeit heraus ausführt, nicht sofort ausgeführt, sondern 33 ms später. Auf diese Weise verringert sich der für den Verteidiger verborgene Teil des Angriffs (bei einer Netzwerklatenz von 100 ms auf 66 ms), was ihm einen größeren Reaktionsspielraum bietet.
Was ist eine „offensive“ Eingabe?
- Ein Leichter Angriff wird immer als „offensiv“-Eingabe gewertet.
- Ein Schwerer Angriff wird als „offensiv“-Eingabe gewertet, außer es handelt sich um eine Parade, die als defensiv betrachtet und nicht verzögert wird.
- Ein Deckungsdurchbruch ist offensiv, außer er wird defensiv als Deckungsdurchbruch-Konter eingesetzt, welcher dann nicht verzögert wird.
- Deckungswechsel, die zeitgleich mit leichten oder schweren Angriffen erfolgen, werden verzögert und erst mit Beginn des Angriffs ausgeführt.
- Ausweichbewegungen oder Abbrüche/Finten werden als offensiv gewertet, wenn sie während einer bereits verzögerten „offensiv“-Eingabe ausgelöst werden. So sollen Eingabeüberschneidungen verhindert werden, die sonst zu einem Flackern führen könnten.
- Das Loslassen der Tasten für einen Deckungsdurchbruch, einen leichten oder schweren Angriff wird ebenfalls als „offensiv“-Eingabe gewertet, weil damit bei einigen Charakteren ein Angriff ausgelöst wird (z.B die „Sturmfront“ der Orochi).
NÄCHSTE SCHRITTE
Nach einigen Tests, sowohl intern als auch mit Mitgliedern der Community, sind wir überein gekommen, dass wir einen guten ersten Schritt nach vorn gemacht haben, was die Verbesserung der Reaktionsgeschwindigkeiten im Kampf betrifft. Ihr werdet dennoch den geringen Einfluss auf das Timing einiger Aktionen wie Kettenangriffe, Kettenglieder oder Abbrüche spüren, da diese 33 ms früher eingeleitet werden müssen. Wir untersuchen derzeit andere Möglichkeiten zur Verbesserung des Netzwerk-Latenz-Managements im Spiel. Zunächst führen wir aber diese erste Änderung ein, um eure Spielerfahrung so schnell wie möglich zu verbessern. Wie gewohnt werden wir euch über Updates zu diesem Thema auf dem Laufenden halten.
