Networking Pong Clone

Ho i fondamenti dei socket TCP, delle comunicazioni UDP ecc., Ma non riesco a trovare molto su come applicarli a un ambiente di gioco in tempo reale.

Ho un clone Pong, con 4 giocatori, e ho bisogno di sincronizzare le posizioni di paddle tra i tre client e il server (il server è il quarto giocatore). Attualmente utilizzo UDP per inviare aggiornamenti in tempo reale (movimenti di paddle) e TCP per impostare la lobby di gioco, ecc.

È MALE COSA fare spamming su enormi quantità di traffico UDP? Dovrei cercare qualcosa come DCCP per le sue caratteristiche di congestione? O questo non è davvero un problema con un progetto su piccola scala come questo?

Quando devono essere inviati i messaggi di sincronizzazione tra client / server? Attualmente il server sta inviando spam ai pacchetti UDP con lo stato di gioco corrente il più velocemente possibile e i client stanno inviando spam al server la loro posizione di pagaia il più velocemente possibile. È questo il modo migliore per farlo? C'è una sorta di ritardo che dovrei aggiungere in modo che i messaggi vengano inviati una volta ogni X millisecondi o dovrei inviare messaggi solo quando si verificano eventi? (ad es. velocità della paletta modificata a causa dell'input dell'utente)

Sarebbe meglio far comunicare ai clienti le loro posizioni di pagaia tra loro peer to peer?

Sto ponendo queste domande nel contesto di Pong, ma sono anche interessato a come questi problemi sarebbero superati in altri giochi o soluzioni generalizzate.

Avere un intervallo di aggiornamento configurabile (in modo da poter modificare e provare 5 pacchetti al secondo o 20) e ogni frame vede se è il momento di inviare un aggiornamento. Potresti essere d'accordo con un semplice gioco che invia pacchetti per ogni evento, ma in un gioco più complesso questo non è pratico. Inoltre, tieni presente che c'è un sovraccarico di pacchetti, quindi se stai inviando un sacco di piccoli pacchetti sprecherai la larghezza di banda.

Ogni intervallo di aggiornamento prevede che ciascun client invii la propria posizione di paddle al server o a ciascun client (peer-peer). Chiedi al server di inviare anche la posizione della palla e un vettore di velocità. Ogni client può eseguire lo stesso codice di disegno dello schermo come nel singolo giocatore, in modo che il movimento della palla sia regolare. Nel multiplayer, però, hai solo il server che invia gli aggiornamenti di posizione / velocità per la palla a intervalli regolari (e se ti piace ogni volta che colpisce qualcosa).

Fai in modo che gli aggiornamenti della posizione della pallina facciano riferimento a un gametime su tutti i client in modo da poter scartare i pacchetti fuori ordine e persino rendere più accurata l'interpolazione della posizione delle palline (conosci la posizione e la velocità in un momento specifico nel passato in modo da poter interpolare il nuovo posizione).

Con questo modello con un gioco ritardato potresti vedere la palla muoversi all'indietro a volte o saltare un po '. Ma con una connessione decente dovrebbe essere abbastanza regolare.

Per quanto riguarda i problemi di traffico, si desidera evitare di inviare più di 20-30 pacchetti al secondo per peer. Nel caso generale, se si inviano pacchetti più piccoli e con un numero inferiore, si verificherà (leggermente) una minore latenza e una minore possibilità di pacchetti persi.

Sicuramente non vuoi inviare aggiornamenti a una velocità maggiore di framerate, poiché i giocatori non saranno in grado di dire la differenza - anzi, se invii solo pacchetti 10 volte al secondo e interpoli / estrapoli i risultati alla fine della ricezione , la maggior parte dei giocatori non noterà alcuna differenza.

Questa è una domanda piuttosto ampia, ma cercherò di riassumere gli aspetti importanti.

La prima decisione da prendere nel codice di rete per il tuo gioco è se desideri una configurazione client / server di una disposizione peer to peer. La maggior parte dei giochi, con RTS probabilmente l'unica eccezione notevole, utilizza probabilmente un'architettura client / server. Il vantaggio principale è che questa disposizione è più tollerante ai guasti e fornisce un maggiore controllo sui dati che ogni cliente riceve. Il peer to peer consente di inviare molti meno dati, ma richiede a ciascun peer di simulare completamente il mondo esattamente come ogni altro peer. Se un peer è in ritardo o desincronizza, tutti devono aspettare che si riprendano o semplicemente si perdono.

UDP è generalmente anche la scelta corretta, sicuramente per qualsiasi modello client / server. TCP potrebbe essere pratico per un gioco peer to peer, ma anche allora UDP potrebbe essere una scelta migliore. Fondamentalmente, UDP gestisce meno per te, il che significa più sforzo ma anche un maggiore controllo su come gestire i guasti.

Per Pong la scelta che farei è client / server, essendo un gioco orientato all'azione. Una cosa da notare qui, anche se dici che un giocatore "è il server", è meglio strutturare il tuo codice in modo tale che essenzialmente stiano eseguendo un server locale e si connettano ad esso come client.

Sicuramente non vuoi nemmeno essere "spamming" aggiornamenti in nessuna direzione. È sufficiente un aggiornamento dal server per frame e il server dovrebbe essere in esecuzione a un frame rate fisso. Ciò che dipende da te, ma non è necessario esagerare. Un frame da 50ms (20 FPS) è sufficiente per ottenere un gioco fluido e piacevole. Per mantenere le cose fluide sul client, si desidera utilizzare l'interpolazione. Il client dovrebbe essere costantemente in transizione tra le istantanee dei frame del server, ma questo potrebbe facilmente essere l'argomento di una domanda separata.

Anche gli aggiornamenti dei client dovrebbero essere limitati, anche se uno per frame sarà probabilmente troppo se il client funziona a un frame rate decente.

Ti interessa barare?

In caso contrario, il peer-to-peer dimezza il ritardo, poiché è A <-> C anziché A <-> B <-> C. In tal caso, per correttezza nella sincronizzazione potresti voler rendere la risposta un po 'ritardata per il giocatore locale, o cosa fa la maggior parte dei giochi - lascia che il giocatore faccia qualsiasi cosa a livello locale e poi ritorna indietro se il risultato del server differisce da quello locale simulato.

Un clone di pong è in realtà un po 'complicato, perché a differenza della maggior parte dei giochi non puoi (come sviluppatore) imbrogliare avendo un lato vedere un colpo e l'altro no.

Per quanto riguarda qualcosa di generalizzato, una tecnica di cui ho sentito parlare ma che non ho trovato necessaria (potrebbe essere per i giochi d'azione) è quella di mantenere le azioni con i loro timestamp reali (tempo di ricezione - ping / 2) e far ripristinare il server ( snap) se arriva un evento precedente e quindi riapplica le azioni successive. In questo modo, tutti sono coerenti a livello locale a meno che non ci siano conflitti a causa delle interazioni dei diversi giocatori. L'unico pericolo è la possibilità di "tornare indietro nel tempo" se fingono una connessione ritardata.

Calcolo dei morti di Google. L'invio di aggiornamenti per 4 giocatori non sarà significativo. La quantità di dati inviati sarà dell'ordine dei byte. Quindi, ciò significa che gli aggiornamenti frequenti dovrebbero essere ok. Con la resa dei conti morta, si sposta il giocatore sul client e sul server. Il server è l'autorità. Quando la posizione dei client diventa troppo lontana dalla sincronizzazione dal server, deve tornare all'allineamento. http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking L' utilizzo di UDP è la strada da percorrere. I bupdate verranno inviati frequentemente che i dati persi saranno presto sostituiti dai dati in arrivo comunque. La ritrasmissione di pacchetti di TCP non vale per la posizione del giocatore. Leggi questo articolo per maggiori informazioni su come mantenere sincronizzati client e server.

Ho programmato un gioco-pong-network-locale-2 giocatori qualche settimana fa, ecco come l'ho fatto:

-Un lato apre un server, l'altro si connette automaticamente -sono entrambi spamming le loro palette x posizione l'una verso l'altra @ 60fps o meno [UDP] -se un lato colpisce la palla decidono sulle nuove velocità e posizione delle palle e inviano che all'altro [TCP] - se la palla vola oltre una paletta, il giocatore che l'ha persa contatta l'altra con un messaggio di punteggio in aumento e la palla viene resettata [TCP] - la palla viene simulata in modo indipendente tutto il tempo, il che si adatta alla semplice fisica della palla del pong

Questo crea circa 0,3 a 0,5 KByte / s di traffico a 60 fps e i giocatori non hanno alcun ritardo nella loro percezione, ma solo se il ping è al di sotto di una certa soglia, perché le nuove posizioni delle palle devono essere trasmesse.

Anche imbrogliare è facile con questo sistema e c'è un'alta possibilità di andare fuori sincrono con una connessione molto lossy, ma a chi importa di imbrogliare in pong ?!