Devtalk - Sprint e collisioni

[emmea90]

Negli scorsi giorni Cyanide ha pubblicato su Steam dei DevTalk riguardo gli sprint e le collisioni. Ve li riportiamo qua di seguito

Gli Sprint

Cari giocatori,

Vorremmo darvi alcune spiegazioni sugli sprint in PCM 24.

Per quanto riguarda quello che viene chiamato il "bug dello sprint"

Questo riguarda lo sprinter che si trova dietro il suo apripista e che rimane leggermente indietro quando inizia il suo sprint.

È qualcosa che stiamo cercando di risolvere. Non è stato integrato nella patch 2 (Open Beta dal 27 giugno) perché non è una correzione semplice da fare e spieghiamo perché:

Le indagini hanno mostrato che non è un problema nuovo, ma la causa è presente nel gioco da diversi anni. Questo non significa che il problema fosse necessariamente così visibile, perché, come sempre, altri effetti possono influenzarlo, attenuandolo o peggiorandolo.

La causa è essenzialmente un problema legato all'attributo "Accelerazione" e a come viene utilizzato nel motore di gioco. Quando sei ben protetto dietro il tuo apripista e lui ha ancora energia rossa, e improvvisamente inizi il tuo sprint: hai una sorta di doppia penalità:

• Effetto del vento: lo sprinter perde la protezione dal vento.
• Effetto ACC: lo sprinter impiega un po' di tempo per raggiungere la massima potenza (dipende dal valore di ACC).

Quindi, mentre il tuo apripista è alla massima o quasi massima potenza, il tuo sprinter è lontano dal suo valore massimo E penalizzato dal vento: questo è sufficiente per farlo perdere qualche metro al suo apripista, invece di superarlo direttamente come ci si aspetterebbe! Più basso è il valore di ACC per lo sprinter, più si nota il problema.

Per quanto riguarda l'effetto del vento, non c'è molto da dire, è il comportamento desiderato. Per quanto riguarda l'effetto ACC, il tempo attuale per raggiungere la massima potenza è probabilmente troppo lungo ed è il cuore del problema qui.

Quello su cui stiamo lavorando attualmente è ridurre il tempo per raggiungere questa potenza massima, e ha un chiaro effetto positivo su questo problema. Il primo effetto collaterale minore è che l'attributo ACC sarà meno importante, ma potrebbe essere accettabile (e possiamo dire che forse era troppo importante).

Un altro effetto collaterale è che cambia la dinamica dello sprint: l'energia rossa non si svuota più nello stesso modo.

È bene ricordare che non è un sistema semplice ma complesso con molti dati e attori. Quindi dobbiamo testare, assicurarci di non peggiorare le cose rispetto a prima. È chiaramente più facile rompere il sistema che migliorarlo un po'.

Per concludere con una nota positiva, mentre pubblichiamo questa notizia, abbiamo una correzione già ben avanzata, i test interni sono in corso e speriamo di poter rilasciare una patch per questo problema la prossima settimana.

-------------------------------

Le Collisioni

Cari fan del ciclismo,

Alcuni di voi si lamentano che ci sono ancora collisioni negli sprint e sono sorpresi da ciò che è stato comunicato nel Devblog.

Per cominciare, riconosciamo che una parte del Devblog non era abbastanza precisa e ha suggerito che tutte le collisioni erano state rimosse alla fine di una gara, questo è un errore da parte nostra e ci scusiamo per aver creato questa confusione.

All'inizio di questo Devblog ci siamo concentrati sul problema degli arrivi sinuosi, che era il punto di partenza di tutto questo problema e su cui volevamo concentrarci, ma più avanti nell'articolo la precisione non è stata data di nuovo, il che può essere chiaramente interpretato male (“Dopo molti test che non sono stati davvero conclusivi, abbiamo rischiato semplicemente rimuovendo le collisioni negli ultimi 5 chilometri delle tappe”).

Pertanto, tutte le collisioni non sono rimosse alla fine delle gare. Per essere più precisi, tre criteri devono essere rispettati per consentire la disattivazione delle collisioni e delle repulsioni (che quindi viene eseguita temporaneamente ogni volta):

• Essere negli ultimi 5 chilometri della gara.
• Avere una curvatura del turno sufficientemente pronunciata (le collisioni/le repulsioni sono disattivate 200 metri prima, durante la curva e 200 metri dopo - scala del gioco -).
• Avere una pendenza ≤ 6%.

Il primo criterio è basilare, arbitrario e serve a distinguere la fase a monte dello sprint, ma questo non è davvero l'argomento dei problemi sollevati.

Il terzo criterio è anche semplice da capire, ma dopo averlo discusso, pensiamo che sia superfluo e lo rimuoveremo in un futuro aggiornamento. Ciò eviterà possibili frustrazioni in arrivi come “Mur de Huy” (curve significative e pendenza > 6% quasi per tutto il percorso tranne gli ultimi pochi metri).

Il secondo criterio (curvatura della curva) è l'elemento più delicato. È essenziale mantenere un equilibrio e serve a delimitare i casi che consentono il passaggio o meno forzato.

Abbiamo testato nuovamente disattivando completamente collisioni/repulsioni (cioè rimuovendo il criterio della curvatura per le curve) e, come ci si poteva aspettare, ovviamente sembra terribile:

• Questo distorce completamente la fase dello sprint (il buon posizionamento è quasi inutile o ridotto a un guadagno marginale).
• Visivamente il risultato è inaccettabile, poiché i corridori tendono ad accalcarsi l'uno sull'altro.

Questo è il risultato di un test estremo, e non c'è alcuna intenzione di fare questa scelta in qualsiasi momento, ma considereremo un leggero aggiustamento della soglia della curvatura delle curve, in modo che collisioni/repulsioni siano disattivate un po' più facilmente. Stiamo parlando di un piccolo aggiustamento e in nessun caso di un cambiamento profondo: di più non è necessariamente meglio, specialmente in questo caso specifico, e tutto è una questione di trovare un compromesso il più soddisfacente possibile nel gioco.

Per dare un'idea, nella versione attuale, gli ultimi 5 chilometri della tappa Plaisance - Torino (tappa 3 del Tour 2024) non consentono mai la disattivazione delle collisioni, sono curve lievi che sono al di sotto della soglia di attivazione.

Mentre siamo sull'argomento, riguardo al multiplayer, questo aggiunge un ulteriore livello di complessità, poiché il sistema implica che la visualizzazione sui client (= tutti i giocatori eccetto l'host) è meno precisa rispetto al solo.

Anche se è un gioco che punta a essere il più realistico possibile, rimane limitato da scelte e vincoli tecnici, la rappresentazione 3D tra i client non è sempre fedele al 100% a ciò che sta accadendo a livello di calcolo del server (= l'host).

C'è meno precisione nei dati inviati nel multi (rispetto al solo dove abbiamo maggiore precisione perché non c'è invio di rete), e quando ci sono storie di collisioni che si mescolano a tutto questo, è possibile avere un'esperienza meno soddisfacente rispetto al solo.

Naturalmente, il nostro team è sempre alla ricerca di feedback e verranno effettuati aggiustamenti nelle prossime settimane.

Il Team di PCM 2024.