Compensazione del ritardo con giochi 2D collegati in rete


31

Voglio creare un gioco 2D che è fondamentalmente un gioco sandbox / attività basato sulla fisica. C'è qualcosa che davvero non capisco però. Dalla ricerca, sembra che gli aggiornamenti dal server dovrebbero essere solo ogni 100 ms. Vedo come funziona per un giocatore dal momento che possono simulare contemporaneamente la fisica e compensare il ritardo attraverso l'interpolazione.

Quello che non capisco è come funziona per gli aggiornamenti da altri giocatori. Se i clienti ricevono notifiche sulle posizioni dei giocatori solo ogni 100 ms, non vedo come funziona perché in 100 ms possono accadere molte cose. Il giocatore avrebbe potuto cambiare direzione circa due volte in quel momento. Mi chiedevo se qualcuno avrebbe avuto qualche idea su questo problema.

Fondamentalmente come funziona per le riprese e cose del genere?

Grazie

Risposte:


58

Riepilogo per coloro a cui non piacciono le risposte lunghe ...

Si può fare ma è impossibile fare una perfetta fisica multiplayer in caso di latenza. Viene spiegato perché la latenza influisce sulla fisica e vengono offerti suggerimenti per ridurre l'impatto della latenza sulla simulazione fisica.


La creazione di un gioco di fisica multiplayer può essere piena di pericoli. È impossibile creare un'esperienza fisica multigiocatore online "perfetta". Ci sono cose che puoi fare per renderlo migliore, ma non c'è modo di fare in modo che la fisica perfetta assuma una latenza.

Il problema è che la fisica deve essere veloce e reattiva per essere realistica, ma allo stesso tempo deve essere calcolata sulla base delle azioni combinate di TUTTI i fattori, vale a dire le azioni combinate di tutti i giocatori. E se c'è latenza, questo non può essere fatto in tempo reale.

Spetta a te come sviluppatore decidere se puoi tenere sotto controllo i diversi fattori e capire che l'esperienza del giocatore peggiorerà se la latenza diventa troppo alta. Se riesci a convivere con quello (e i tuoi giocatori possono), allora provaci. Vedi verso la fine di questo post per alcune note su come rendere le cose più fluide.

Un esempio per mostrare come le cose possono essere incasinate

Immagina un gioco in cui due giocatori (client) sono collegati a un server. Sono necessari 100 millisecondi (1/10 di secondo) affinché un messaggio passi attraverso Internet dal client al server. Quando un giocatore fa qualcosa, un messaggio viene inviato al server dicendo ciò che ha fatto. Il server quindi trasmette il messaggio agli altri giocatori in modo che tutti sappiano cosa ha fatto il giocatore che recita.

Ora crea uno scenario in cui due giocatori hanno una cassa sul terreno che è un oggetto fisico. Il giocatore A lo colpisce da un lato, facendolo muovere in una direzione. Tuttavia, allo stesso tempo, il giocatore B lo colpisce da un'altra parte, mandandolo in un'altra direzione.

Diamo un'occhiata a diversi modi per gestire questo e quali sarebbero i risultati ...

Cosa succede se la fisica viene calcolata solo sul server?

Supponiamo di avere la fisica calcolata solo sul server. Il giocatore A invia il messaggio "Ho colpito la cassa in questo modo" al server, 1/10 di secondo dopo il server riceve il messaggio. Il giocatore B invia il messaggio "Ho colpito la cassa in questo altro modo". Il server calcola il cambiamento di fisica dalla combinazione delle due azioni e rimanda il messaggio a entrambi i giocatori dicendo "OK, si muove in questo modo". Viene eseguita una fisica perfetta, basata sulle azioni di entrambi i giocatori combinati.

Ma il problema è che passerà 2/10 di secondo prima che uno dei due giocatori veda reagire la cassa. I messaggi di entrambi i giocatori impiegano 1/10 di secondo per raggiungere il server, quindi un altro 1/10 di secondo affinché i risultati del calcolo del server vengano inviati per entrambi i giocatori.

Concludendo, gameplay ritardato.

Cosa succede se la fisica viene appena calcolata sul client?

Supponiamo di avere una fisica calcolata solo sul cliente. Vediamolo dal punto di vista del giocatore A. Il giocatore A colpisce la cassa e inizia immediatamente ad andare nella loro direzione. Viene anche inviato un messaggio al server che dice cosa ha fatto il giocatore A.

Allo stesso tempo, però, B ha fatto colpo e ha visto la cassa andare nella loro direzione e ha inviato un messaggio al server su ciò che ha fatto.

2/10 di secondo dopo, arriva un messaggio dal server ai client. A viene detto ciò che B ha fatto e B viene detto ciò che A ha fatto. Il problema è, affermano entrambi i clienti, "Beh, il giocatore X potrebbe aver fatto quel colpo in questo punto, ma non c'è più una cassa in quel punto, quindi il suo colpo non ha fatto nulla".

In conclusione, due giochi non sincronizzati e i giocatori non hanno un'esperienza condivisa. Che senso ha il multiplayer se entrambi vedono cose diverse?

Cosa succede se la fisica viene calcolata sia sul client che sul server?

In questo caso, la fisica viene calcolata sul client in modo che i giocatori vedano una reazione immediata senza ritardi, ma viene anche calcolata sul server, quindi è "corretta" per tutti i giocatori.

Entrambi i giocatori colpiscono la cassa nelle rispettive direzioni e ciascuno vede la cassa muoversi solo in base al proprio colpo. Ma poi 2/10 di secondo dopo, il server ritorna e dice: "Beh, in realtà, entrambi avete torto. La cassa è andata in questo modo." All'improvviso entrambi i giocatori vedono la cassa cambiare drasticamente le direzioni e si bloccano in una nuova posizione.

La linea di fondo è, un gioco glitch.

Conclusione

Fondamentalmente non c'è modo di creare un gioco di fisica perfetto con più giocatori quando esiste un tipo di latenza. Puoi fare un gioco abbastanza buono, ma avrai sempre il rischio di un'eccessiva latenza creando una brutta esperienza per alcuni giocatori. Tuttavia ci sono cose che puoi fare per mantenere una buona esperienza di gioco.

Cose che puoi fare per far funzionare bene una partita multiplayer

Usa semplici volumi di collisione. Non preoccuparti di modellare ogni dettaglio di una forma con la fisica quando farà una semplice forma cubica. Una palla spikey non deve essere modellata come una palla spikey per la fisica. Invece, modellalo come una sfera.

Crea piccoli oggetti senza risposta solo oggetti client. Un esempio potrebbe essere frammenti di vetro rotto da una finestra rotta. Puoi consentire a ciascun client di simularlo da solo e non importa se sono diversi.

Crea oggetti oggetti di fisica solo se devono essere oggetti di fisica per mantenere basso il numero di oggetti di fisica attiva.

Esegui il tuo gioco al rallentatore quando fai fisica multigiocatore. Pensa forse al "proiettile". I giochi al rallentatore compensano la latenza e consentono a più giocatori di interagire con la fisica insieme.

Consentire ai giocatori di impostare una situazione di qualche tipo insieme, e poi su alcuni spunti, la fisica viene simulata per entrambi i giocatori ed entrambi guardano il risultato delle loro azioni combinate. I giocatori non possono interferire con la sequenza fino a quando non è stata completata.

Separare i giocatori in modo che non possano interferire tra loro. Sarebbe fantastico per un gioco come il bowling o il biliardo, in cui solo un giocatore alla volta ha il controllo, o ogni giocatore ha il proprio "sandbox" (come una pista da bowling).

Se non puoi batterli, unisciti a loro e fai in modo che il ritardo fisico faccia parte del tuo gioco. Immagina una storia sull'essere in un universo glitch con leggi della fisica infrante o qualcosa del genere :)

Appendice: come i giochi di tiro affrontano

I giochi di tiro affrontano il problema non facendo una fisica troppo complessa. Usano gli effetti collaterali del client in modo che i giocatori vedano le cose rapidamente, ma poi il server effettua l'ultima chiamata su ciò che è successo.

Immagina uno scenario in cui il giocatore A spara al giocatore B. Il tuo tipico gioco sparatutto farà qualcosa del genere ...

  1. A calcolerà localmente se colpiscono B, e se sembra che ci sia un colpo, gioca un effetto "colpo" come un soffio di sangue. Questo viene fatto dal lato client in modo che il giocatore veda immediatamente una reazione alla propria azione. Se non lo fai, il gioco sembra ritardato.
  2. A invia anche un messaggio al server dicendo "Ho sparato lungo questo vettore"
  3. Quando il server riceve il messaggio, osserva dove l'IT pensa che siano i giocatori e decide se il vettore di tiro di A colpisce B.
  4. Se il server decide A hit B, decide che B è hit e invia un messaggio a ENTRAMBI i client dicendo cosa è successo.
  5. Se il server decide che A NON ha colpito B, B va bene e A "manca". Potrebbe sembrare che A abbia colpito ("Ho visto l'esplosione di sangue!"), Ma sono i server che chiamano che hanno perso.

Quindi come poteva A mancare B quando sembrava che li colpissero? Perché B potrebbe essersi spostato, ma A non lo ha ancora visto perché il server non ha ancora inviato un messaggio "B spostato qui" al client.

Valve ha una buona notizia sul proprio sito al riguardo. Vedi http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking


2
Questo è vero su un server con una buona connessione. Ci sono molti casi in cui la fisica nei giochi multiplayer fallisce e sono sicuro che ci sono molte brutte esperienze di fisica nei giochi Mod di Garry. Tuttavia, se c'è latenza, i problemi che ho delineato esisteranno. Non puoi aggirare il fatto che la fisica deve essere calcolata molto rapidamente per essere fluida. E se hai la latenza, ci sarà un ritardo. Ritardo significa ritardo.
Tim Holt,

1
Potresti voler tornare indietro e rileggere il mio post. Meno un po 'd'opinione sul front-end da parte mia, sto descrivendo esattamente cosa succede in una simulazione di fisica con più giocatori, comprese le sessioni di gioco Mod di Garry. Non puoi aggirare i fatti.
Tim Holt,

2
Ok, ho cambiato il mio voto negativo in un voto positivo. Ma dipingi un quadro davvero negativo per i giochi multiplayer con la fisica, quando è stato davvero fatto prima e relativamente privo di problemi.
Attaccando

7
@AttackingHobo: "Glitch free" è relativo. Avendo lavorato su un gioco con una buona previsione della rete, ora vedo problemi che non avevo mai visto prima. Raramente influenzano significativamente la meccanica, ma sono presenti. L'intero punto di previsione è che una piccola imprecisione in tempo reale è migliore dell'accuratezza ritardata; ciò non cambia il fatto che sei sempre inesatto.

1
+1 per "Immagina una storia sull'essere in un universo glitch con leggi della fisica infrante o qualcosa del genere".
Patryk Czachurski,

13

Ho scritto una serie di articoli sull'argomento qui: http://www.gabrielgambetta.com/fpm1.html

I primi tre articoli trattano un'introduzione all'argomento, la previsione sul lato client, la riconciliazione del server e l'interpolazione dell'entità (questa è la parte che risponde alla domanda specifica). Il quarto articolo (in arrivo) tratterà di "materiale da tiro" :)

La risposta di Tim Holt è praticamente tutto. I miei articoli hanno un paio di diagrammi che possono aiutarti a capire cosa sta succedendo, ma io e Tim stiamo praticamente dicendo la stessa cosa.


Roba buona ggambett!
Tim Holt,

2
Così tanti giocatori non capiscono come funziona questa roba, ma è così fondamentale per capire l'eterno "WTF PERCHÉ HO MANCATO?" domanda.
Tim Holt,

O "perché il mio personaggio è legato a quella colonna con un elastico gigante?" su una connessione interrotta :)
ggambett,

Il Wiki di Valve ha anche un commento su questi problemi. La pagina è su developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
Tim Holt il

1
Adoro la demo live. Che bel modo di visualizzare ciò che sta accadendo.
Richard Marskell - Drackir,

2

Non è irragionevole fare previsioni complete sul proprio personaggio per la capacità di risposta e avere altri personaggi in ritardo di 100 ms per coerenza. Se questo sembra male, considera di avere un po 'di ritardo il tuo personaggio per tenerli sincronizzati. In entrambi i casi avrai ancora bisogno di meccanismi di correzione per appianare le previsioni errate in caso di picchi di ritardo, e quel sistema affronterà situazioni come quella che descrivi. Non importa se la latenza è di 100ms o 1ms: il tuo cliente è sempre "in ritardo" in un certo senso e quindi deve sempre comportarsi come se avesse a che fare con dati vecchi e applicare effetti cosmetici come l'interpolazione per renderlo ragionevole.


0

Alla fine si tratta di accontentarsi delle risorse di rete disponibili. Idealmente, vivremmo in un mondo a latenza zero e tutto può essere perfettamente sincronizzato. Realisticamente, aggiorni i client ogni 100, 200, 300 ms e nel client deve esserci una logica in atto per rendere tutto ciò che è accaduto liscio. La "scorrevolezza" è molto importante, alla fine il gioco deve solo sembrare fluido anche se sul retro si verifica una sincronizzazione caotica tra client e server.

È possibile trovare un buon post e una risposta migliore:

Come scrivere un gioco di rete?


0

Il problema non è proprio la latenza. Può essere compensato e previsto abbastanza bene per nascondere eventuali problemi causati. Neanche la perdita di pacchetti è un problema: il sistema di rete dovrebbe essere scritto per essere solido e tollerabile per la perdita di pacchetti. Tuttavia, il problema sono i picchi di ritardo e la latenza imprevedibile. Pacchetti che arrivano fuori sincrono, alcuni di essi vengono eliminati solo a causa di oscillazioni di latenza, incapacità di prevedere e interpolare a causa di oscillazioni di latenza ecc.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.