Fare buon cliente multiplayer / MMO <> Giochi di server utilizzano latenza all'interno di calcoli di movimento?

Question

Ci sono un paio di domande qui.

Immaginate Ho client A chi sta per inviare il seguente messaggio al server:. "START movimento in avanti"

Il server non riceverà questo messaggio immediatamente, in quanto v'è un ritardo a causa della latenza.

Domanda 1: ping (o meglio: andata e ritorno tempo ) è la quantità di tempo necessario per il cliente di inviare un messaggio al server e ricevere una risposta indietro. Questo significa quanto segue se si può ignorare il tempo necessario per il server a notare di aver ricevuto un messaggio e iniziare a inviare una risposta (questo dovrebbe essere molto breve)?

1. tempo necessario per il cliente di inviare someting al server = round-trip-time / 2
2. tempo necessario per il server di inviare qualcosa da client = round-trip-time / 2

Così, quando il client A invia il messaggio, il server suppone che riceverà il messaggio di andata e ritorno in tempo / 2 millisecondi dopo che il cliente ha inviare il messaggio. Questo mi porta alla prossima domanda.

Domanda 2: se il cliente prima di inviare il pacchetto, e quindi attendere round-trip-time / 2 millisecondi prima di espletare effettivamente il comando sul lato client? (In questo caso: si muovono in avanti) per compensare con la latenza / lag

Ora, il server invierà il seguente messaggio a tutti i giocatori vicini: "CLIENT A si sta ora spostando FORWARD". Questi clienti potranno quindi assicurarsi che il carattere di un cliente inizia a muoversi, questo mi porta alla prossima domanda.

Domanda 3: se il cliente che riceve il messaggio che un altro client si è spostato tener conto che questo messaggio è stato inviato dal server round-trip-time / 2 millisecondi fa? In modo che l'ora attuale utilizzata per i calcoli di movimento timestamp deve essere ridotta del round-trip-time / 2?

Tutti questi metodi sarebbero nella mia mente fare in modo che la sincronizzazione migliora tra i client, come la latenza viene preso in considerazione. È questo il modo giusto di fare le cose? Fare la maggior parte altri giochi multiplayer buone fare questo? Eventuali commenti, suggerimenti, alternative o grida casuali, ma correlati che vorreste dare? Grazie in anticipo.

Answer 1

Credo che nella maggior parte dei MMO del vostro cliente si muove principalmente senza l'interazione con il server a meno che non si verifica cattivo lag. Il server riproduce il movimento con l'aiuto dei messaggi del client invia al server. Così, se per esempio il server è in ritardo, il cliente si fermerà riceve un feedback dal server e ripristinare la posizione del server a determinare che ci si trova. Questo è il motivo per cui si torna indietro di diversi fotogrammi durante il cattivo lag. In questo modo il server avrà anche il controllo della tua velocità in modo che non si speedhacking. Se il client si muove a una certa velocità, che è sopra la velocità determinata dal server, si dovrebbe semplicemente tornare indietro i fotogrammi aggiuntivi.

Altri clienti che non avrebbero permesso di spostare a tutti, senza risposta dal server entro un certo periodo di tempo. Questo è i tempi si sarebbe esperienza 'freeze-lag'.

Naturalmente ci sono anche le occorrenze in cui il server è sufficiente prendere la posizione inviata dal cliente e si fida ciecamente. Questi sono i giochi che sono generalmente vulnerabili di teletrasportarsi hack.

Quando si tratta la posizione di altri giocatori c'è davvero un ritardo, che può essere visto se si prende due computer, connettersi a un gioco come wow e spostare i due personaggi simultaniously. Si vedrebbe che su entrambi i computer il carattere non locale inizierà a muoversi dopo aver iniziato davvero lui muoversi.

Il cliente di solito hanno una sorta di compensazione lag. Quindi, se un altro giocatore si muove ad una certa direzione e poi si ferma, il vostro cliente sarà ancora simulare il movimento di quel giocatore fino a quando si riceve un messaggio dal server che ha cambiato direzione o fermato in movimento. È per questo che gli altri giocatori possono saltare avanti e indietro quando il ping è alta. Questo è anche il motivo per cui i giocatori possono sembrare a scivolare solo / run / piedi quando si colpisce lagspikes e poi tornare alla loro posizione reale quando i vostri clienti ricevono posizioni dal server.

Naturalmente questo cambia da motore a motore ma è un aproach piuttosto generale.

Edit: Ho dimenticato di aggiungere che è molto comune per il server da utilizzare anche la compensazione di ritardo. Se si colpisce qualcuno in un MMO che si trova nel raggio di voi, quella persona potrebbe non essere nella gamma dalla vista dei server. Quindi il server prende la latenza sia per i vostri clienti e cerca di abbinare se foste realmente in gamma di vicenda oppure no.

Answer 2

Questa è una vecchia questione, ma ho lavorato fuori codice simile di recente così forse questo aiuterà qualcuno.

Si latenza è sempre utile nel calcolo. Ma è un po 'più complesso di RTT. il tempo di andata e ritorno è sempre in evoluzione ... il vostro codice di rete può mantenere una media, ma la varianza da quella media è di grandi dimensioni.

Il client locale, client remoto e il server tutto prevedere la posizione corrente utilizzando algoritmi. I seguenti dati è vicino al tipico:

• Tempo: t
• Posizionamento: posizione (x, y, z) e orientamento (x, y, z, w)
• Movimento: movimento lineare vettore dando direzione con lunghezza velocità (x, y, z), e rotazionale vettore movimento dando asse con lunghezza come velocità di rotazione (x, y, z)

È necessario che gli algoritmi estrapolare da un [T, P, M] impostato sul simtime. Io non fornirà coloro che sono qui.

Quando il client registra un cambiamento nel drive della nave [T, P, M], che non otterrà al server finché T + deltaT. Ma se deltaT è all'interno della tolleranza tipici latenze di rete, il server può dire "Sì, è successo a T, lo accetto." In caso contrario, si potrebbe desiderare di correggere il cliente dicendo "No questo è fuori tolleranza, è successo al mio tempo T'", nel qual caso il cliente dovrà riprodurre tutti i successivamente guidati [T, P, M] passa da una corretta del server (che significa è necessario mantenere una coda o un elenco di loro).

Il prossimo cliente otterrà a T + deltaT + differentdeltaT. Esso non può assolutamente cambiare quello che ha già simulato, quindi se non sta ritardando è simulazione salterà la nave a distanza e si vedrà una cornice coglione. Ecco perché le navi azionate a distanza dovrebbero essere le loro simulazioni ritardata di un tempo sempre maggiore di 2 * typicaldeltaT. Dovrebbe essere un ritardo costante, o un ritardo che cambia gradualmente, e in tempi di grave ritardo si vedrà fotogrammi impulsive comunque

è possibile regolare tutti i cretini con il codice di livellamento in più, ma non lo fai fino a quando il codice è altrimenti perfetta perché sarà solo l'impossibilità di vedere dove i problemi sono.

È necessario disporre di un buon riferimento temporale sincronizzato. Un sacco di codice là fuori lo fa piuttosto spiccia (ad esempio RakNet non lo fa (o non fatto) farlo molto bene). Ecco un buon suggerimento: nel breve periodo si può presumere che gli orologi di tutti sono in esecuzione alla stessa velocità, e hai solo bisogno di capire ciò che l'offset è, in modo da mantenere una finestra di massimo e minimo offset e chiuderlo come si impara; Nel lungo periodo è necessario per compensare i clienti i cui orologi sono in esecuzione veloce o lento, in modo da permettere la finestra da aprire se si sa per certo si deve. È necessario utilizzare un timesource locale che è monotonicamente crescente e non calettato fuori della velocità del processore (che oggi è variabile).

No, non ritardare la simulazione locale quando il locale si muove "avatar". Sembrerebbe troppo insensibile. Si potrebbe ritardare leggermente (fino a forse 50ms) per contribuire a migliorare la sincronizzazione, ma un ritardo tutta la via d'uscita per l'RTT renderebbe il vostro gioco sembrare frustrante non risponde. Impostare un'opzione per il ritardo locale e giocare con lui, perché un piccolo ritardo consistente può essere accettabile e migliorare la sincronizzazione. Ma non è necessario e può causare un sacco di problemi, quindi vi consiglio di farlo ultimo codice. (Se si sta cercando di fare un gioco FPS in mischia, avrete bisogno di fare questo e tutti gli altri aiuto possibile).

Per quanto riguarda la prevenzione della frode contro la scorrevolezza di simulazione: In primo luogo, i clienti dovrebbero non solo estrapolare dal ultima posizione nota, quando cambia posizione ufficiale. Dovrebbe registrare un vettore di regolazione e spostare lentamente dal vecchio percorso al nuovo percorso di levigatezza (ma come ho detto sopra fare questo ultimo codice o si maschera altri insetti). In secondo luogo, il server deve tollerare una vasta gamma di ritardi ... anche su macchine sulla stessa ethernet del ritardo di pacchetto funziona tipicamente 5ms a 100ms o così ... che è piuttosto gamma. Naturalmente è necessario tagliarefuori e dire "se dici è stato spostato al tempo T, ma ho avuto il pacchetto a T + some_large_number allora penso che si sta cercando di regolare il passato e mentire a me". some_large_number non dovrebbe essere molto più grande del RTT media per tenere la gente onesta.

Le simulazioni saranno mai perfettamente sincronizzati. Essi dovrebbero rimanere all'interno di 400ms o giù di lì su Internet, ma di certo si allontanerà al di fuori di che durante i periodi di lag ... per 30 secondi o più, ed è necessario tollerare cose che che perché non sono rari. Dato che Internet è limitata dalla velocità della luce in rame, si può sempre aspettare latenze a senso unico ad essere generalmente nel range di almeno 100 ms minimo per i vostri clienti lontani, spesso 500ms o più a lungo.

Quindi mi raccomando non provare a fare una mischia FPS gioco via Internet (alcune grandi aziende provare, ma avranno sempre problemi). Ci sono trucchi che si possono fare se si utilizza proiettili (eseguendo loro velocemente in una simulazione e lento in un altro) in modo che, anche se la tempistica è spento, esso sta a guardare. Inoltre, giochi FPS usano la regola che ha colpito di rilevamento si basa sulla simulazione aggressori ... ci si sente più sbagliato quando l'attaccante sa che era morto sul bersaglio e manca, poi, quando un difensore sa che era fuori strada e viene colpita in ogni modo. Devi scegliere uno o l'altro, e psicologicamente è così che è stato fatto. Melee richiede un livello di sincronizzazione, che è francamente impossibile e la maggior parte delle società di gioco non toccherà MMORPG FPS in mischia, ma piuttosto utilizzare Auto-targetting (provare a giocare a Mortal Online, vedrete cosa intendo).

In bocca al lupo.

Answer 3

per il Q1:. Che sembra giusto per me

Q2: Il modo in cui ho fatto questo in passato è: se si desidera che le cose si sentono reattivo, avviare eseguendo l'azione immediatamente sulla simulazione del cliente, quindi il server simula avanti nel gioco-tempo in cui la persona ha iniziato l'azione . vale a dire il cliente sa a ciò che ms nel tempo di gioco-simualation è iniziato, in modo che il server può iniziare in quel momento anche (nota: questo è sempre a ritroso nel tempo dal tick corrente del server, in modo da avere per salvare lo stato indietro nel tempo per farlo).

Q3: i clienti solo davvero bisogno di sapere che stanno simulando al momento X, e il server dice l'insieme degli eventi {A, B, C} è accaduto a volte {X, Y, Z}. Poi client e server in grado di simulare in avanti con le stesse informazioni e, in generale rimanere sincronizzato (tranne quando si verificano conflitti simultanei). In questi casi si hanno le cose server di ri-sincronizzazione in modo che di solito finisce con un margine piuttosto stretto di errore e un'esperienza per lo più liscia.

Se il vostro obiettivo è quello di migliorare la percezione di latenza si potrebbe anche solo provare fidarsi del cliente.

Answer 4

Ci sono diversi modelli di rete per risolvere questi problemi;

Nel gioco di rete, è necessario sincronizzare due cose, uno è il tempo, altro è lo spazio.

1. Un modello di gioco di rete chiamato sincronia;

si dovrebbe avere uno sguardo al l'articolo scritto da all'età di Studio empire2 gioco, che descrivono i dettagli nel modello di pari passo.

In questo modello, client e server di gioco di corsa fotogramma per fotogramma logica, per esempio, usano RTS 100ms come una cornice, server e client sincronizzerà Id telaio, il che significa che per la sincronizzazione del tempo.

Client a telaio 50, inviare il comando MoveForward, ma non eseguirlo immediatamente, client dirà server per eseguire il comando mossa a telaio 51; poi, quando telaio 51 arriva, server e client verrà eseguito il comando allo stesso tempo. così client e la logica del server sarà lo stesso.

In tale modello, al telaio 50, client e server eseguirà comando inviato al telaio 49 forse, così ci sono sempre puntuale 100ms o più ritardi nelle risposte ingresso client.

il ritardo tra client e server non contiene solo RTT di rete, ma contiene anche logica ritardo di trama, che è 100ms;

in questo modello, per sincronizzare lo spazio, è necessario rendere il codice cliente e codice del server deterministici, in modo che possano sincronizzare unico comando e frameId, non ci sono esigenze da sincronizzare ente statale.

In questo modello, il feedback di ingresso è di grandi dimensioni, quindi è necessario per riprodurre l'animazione o il suono per aiutare il giocatore ignorare il ritardo.

2. altri modelli utilizzano la sincronizzazione dello stato

in questo modello, abbiamo anche bisogno di sincronizzare il tempo, in modo da client indovinare che cosa ora corrente a server.

quando l'input del giocatore, cliente mossa immediatamente, quindi inviare comando di movimento o pos bersaglio client al server con data e ora corrente del server, che è stimato dal cliente.

quando il server riceve il comando client, sapere quando il comando è rilasciato in ora del server dal cliente, si cercherà di eseguire il comando con estrapolazione.

tutti gli altri client riceveranno il comando, con la sua ora del server, gli tutti gli altri client cercheranno di estrapolare il comando.

Queste tecnologie includono Prediction client, la compensazione Lag Server, Server entità interpolazione.

In questo modello, il feedback input del client è breve, ma per qualche impulso di comando, come l'utilizzo di abilità, abbiamo ancora bisogno di utilizzare il metodo pari passo, con animazione, suono e particelle effetti al trucco il tempo di reazione di ingresso.

Nel gioco di rete, lì almeno due tipi di comando, prima come il movimento, il comando verrà eseguito per un certo tempo, come un flusso costante, che ha l'attributo di continuità.

l'altro come l'utilizzo di abilità con tempo freddo, effetto di comando avrà a impulso, dobbiamo trattarli in modo diverso.

Answer 5

Alcuni buoni giochi multiplayer utilizza un meccanismo per permettere ai giocatori muoversi agevolmente anche in tempi di round trip pesanti consentendo cliente di decidere e inviare la posizione del giocatore al server. Ci sono meccanismi di controllo di frode ma il client è gratuito per questo. Quindi, se il tempo di andata e ritorno va wacko che si vede gente che salta da un posto all'altro, mentre si è in movimento senza intoppi. Anche alcuni giochi MMO lo prendono alla fase successiva, consentendo cliente di gestire contenuti single player senza il consenso del server. Solo statistiche, report di battaglia e qualche altra informazione viene inviata al server insieme ai pochi dati di controllo delle frodi.