Attenzione: Useremo 30 fps come riferimento in questo post poiché è il valore condiviso in For Honor tra tutte le piattaforme.
GENESI DEL TIME SNAP
L'Arte della guerra è stata sin dall'inizio il fulcro del design di For Honor. Pertanto è sempre stato molto importante per noi assicurarci che gli attacchi basati sulla postura e i blocchi fossero il più chiari e intelligibili possibile. Ecco un piccolo esempio del problema iniziale affrontato dal nostro team nello sviluppo del gioco:
Video 1
Nel video 1 si può vedere un cambio di postura che blocca con successo l'attacco quando il giocatore in difesa immette il comando all'ultimo momento possibile
Video 2
Abbiamo confrontato questo con un blocco non riuscito, dove il giocatore in difesa immette il comando del cambio di postura 33 ms più tardi. Come mostrato nel video 2, abbiamo ritenuto che la differenza non fosse abbastanza chiara e che avrebbe causato frustrazione al giocatore in difesa. Abbiamo deciso che, per essere sufficientemente comprensibile, la differenza tra un blocco riuscito e uno non riuscito dovrebbe essere sempre di almeno 100 ms.
A questo scopo, abbiamo creato il sistema "Time Snap", che allinea tutte le azioni dei giocatori allo scatto successivo di 100 ms su un orologio globale. Come mostrato nella figura 1, anche se il giocatore 1 ha immesso il comando di attacco 33 ms prima del giocatore 2, gli attacchi verranno lanciati contemporaneamente, portando in questo caso a un doppio colpo.
PROBLEMI DEL TIME SNAP
Lo svantaggio principale del Time Snap è che ha introdotto un ulteriore ritardo negli input dei comandi di 0 ms, 33 ms o 66 ms, a seconda di quando l'input del giocatore veniva immesso sull'orologio globale. Essendo ancora in fase di sviluppo, il nostro team ha ritenuto all'epoca che ciò potesse rappresentare un effetto collaterale accettabile, ma abbiamo rapidamente cambiato opinione a riguardo.
Mentre continuavamo a lavorare sul bilanciamento e sul comfort, abbiamo ricevuto feedback dai nostri tester interni ed esterni che ci hanno lasciati sempre più insoddisfatti riguardo alla reattività del nostro input di cambio postura. Abbiamo optato per rimuovere il Time Snap dal cambio di postura, il che ha risolto alcuni dei problemi nella reattività agli input, ma ha fortemente inficiato l'obiettivo originario del Time Snap.
Dopo l'uscita del gioco, abbiamo deciso di rimuovere completamente il Time Snap, giacché eravamo fermamente decisi a eliminare quell'incoerenza nella reattività agli input. Poiché il sistema funzionava come una sorta di compensazione della latenza di rete, rimuoverlo avrebbe portato a ulteriori conseguenze sul gioco.
Diamo un'occhiata ad alcuni esempi per spiegare meglio come funzionava questo sistema quando era attivo. Per ragioni di semplicità, supponiamo di avere una latenza di rete di 100 ms dal giocatore in attacco al giocatore in difesa
Nella figura 2, il giocatore in attacco immette il comando a 400 ms, quindi l'attacco viene immediatamente avviato. Il giocatore in difesa riceve questo input dopo 100 ms, quindi perde i primi 100 ms dell'attacco.
Nella figura 3, il giocatore in attacco immette il comando a 366 ms, quindi l'attacco viene avviato a 400 ms. Questo ritardo di 33 ms agisce come compensazione della latenza di rete, poiché il giocatore in difesa ora perde solo i primi 66 ms dell'attacco.
Nella figura 4, infine, il giocatore in attacco immette il comando a 333 ms, e l'attacco viene avviato a 400 ms. Qui abbiamo 66 ms di ritardo negli input dei comandi che permettono al giocatore in difesa di perdere solo i primi 33 ms dell'attacco.
Considerando che questa compensazione della latenza di rete era casuale e inattendibile, non rappresentava la soluzione ideale per consentire ai giocatori di reagire in modo affidabile agli attacchi. Abbiamo pensato che, dal momento che una volta su tre gli attacchi non avevano compensazione di latenza, rimuovere il Time Snap non avrebbe avuto conseguenze negative sulla reattività dei giocatori. Tuttavia, il feedback della community ha chiarito che, in sostituzione all'inaffidabile Time Snap, dovevamo trovare una soluzione alla perdita di dati extra introdotta con la sua rimozione.
IMPLEMENTAZIONE ATTUALE
L'implementazione qui proposta è un approccio ibrido al ritardo negli input dei comandi: tutti gli input considerati "offensivi" (vedi elenco sotto) saranno ritardati del valore fisso di 33 ms. Tale valore non influisce troppo sulla reattività all'input poiché influenza solo le nostre azioni "offensive" che sono, per loro natura, lunghe. Come spiegato nella figura 5, se un giocatore in attacco innesca un attacco da inattivo, invece di iniziare immediatamente questo inizierà solo dopo 33 ms. In questo modo, la parte nascosta dell'attacco per il giocatore in difesa sarà ridotta dal ritardo negli input dei comandi (da 100 ms a 66 ms), migliorando la sua finestra di risposta.
Cos'è un input offensivo, dunque?
- L'attacco leggero è sempre considerato un input offensivo
- Un attacco pesante è considerato come un input offensivo tranne quando è una parata, che non viene ritardata
- Lo Spezzaguardia è considerato offensivo, tranne quando viene utilizzato in modo difensivo per un contrasto allo Spezzaguardia, che non viene ritardato
- Un cambio di postura coincidente con un attacco leggero o pesante ritarderà il cambio di postura per iniziare con l'attacco
- Schivata o Interruzione/Finta sono considerate offensive se vengono attivate mentre un input offensivo è già stato ritardato per impedire l'inversione di input, che potrebbe causare qualche sfarfallio
- Rilasciare uno Spezzaguardia, un attacco leggero o attacco pesante è anche considerato un input offensivo in quanto può attivare attacchi per alcuni personaggi (ad esempio la Corsa tempestosa dell'Orochi)
FASI SUCCESSIVE
Dopo i nostri test interni e quelli effettuati dai membri della community, riteniamo di aver compiuto un buon primo passo verso il miglioramento della reattività generale della nostra esperienza di combattimento. Avrà un lieve impatto sulla tempistica di determinate azioni quali serie, collegamenti o interruzioni poiché sarà necessario immetterne i comandi 33 ms in anticipo. Stiamo attualmente esaminando ulteriori modi per migliorare la nostra gestione della latenza di rete nel gioco, ma abbiamo voluto implementare questa prima modifica per offrire immediatamente un'esperienza di gioco migliore. Come sempre, vi terremo aggiornati su eventuali ulteriori sviluppi.
