Tecniche MMO, algoritmi e risorse per mantenere bassa la larghezza di banda?


9

Esistono risorse e documentazione su come gli attuali MMO gestiscono i dati di azione e movimento dalla compressione alla gestione sul client? Qualche risorsa per gli algoritmi di previsione del movimento?

Sono particolarmente interessato a coloro che hanno movimento wsad e si concentrano sul mantenimento della latenza bassa. Qual è anche la frequenza e la dimensione dei pacchetti per i diversi tipi di MMO (per quanto riguarda la rete)?

C'è un modo per ridimensionare la frequenza dei pacchetti o disabilitare completamente alcuni pacchetti se il giocatore non può raggiungerli o in un secondo momento vederli?

Risposte:


9

Bene, c'è questo libro - che ora è un po 'vecchio, e non l'ho mai letto davvero, ma è di un editore rispettabile. Ho anche trovato questo , che è più recente, ma non ne ho mai sentito parlare prima. Entrambi affermano di coprire i problemi di sviluppo di giochi MMO (o almeno online); detto ciò, la previsione sul lato client è più o meno la stessa indipendentemente dalla scala della base di giocatori simultanea e Google ha molte informazioni al riguardo .

È importante rendersi conto che da un punto di vista pratico è piuttosto difficile per uno sviluppatore indipendente / hobby mettere insieme un gioco che sarà abbastanza popolare da raccogliere anche abbastanza giocatori da raggiungere un picco di concorrenza teorica abbastanza alto da essere considerato "massiccio". Ma le tecniche possono ancora essere educative per la ricerca.

Esistono due principali classificazioni delle cose che puoi fare:

  • Sii aggressivo nell'inviare solo la minima quantità di dati al minimo set di clienti che ne hanno bisogno.
  • Progetta un gioco che non dia ai giocatori l'incentivo di ingombrare troppo, aiutandoti a mantenere "l'insieme di clienti che hanno bisogno di" piccole cose in generale.

Il secondo è davvero un problema di progettazione del gioco e di manipolazione sociale - è particolarmente complicato perché i giochi multiplayer sono naturalmente sociali, fa parte del loro fascino, quindi non vuoi scoraggiare troppo i gruppi di giocatori. D'altra parte, un gioco in cui tutti nel mondo stanno generando il campeggio, l'unico ragazzo che rilascia il bottino migliore nel gioco sarà difficile da scalare.

Per la prima opzione che potresti prendere in considerazione per fare messaggi a più livelli - ci sono alcune cose su altri giocatori che sono sempre importanti da sapere, come le posizioni. Ma altre cose, come la salute, potrebbero non essere così importanti per gli oggetti che il giocatore attuale non può ancora vedere, quindi cancelli ciò che invii a quel giocatore in base alla distanza relativa di tutte le altre entità nelle sue vicinanze - questo è essenzialmente un throttling i dati che invii, come indicato nell'ultima parte della tua domanda, oltre a filtrarli.

Le architetture multiplayer su larga scala bufferizzeranno anche i report che non necessitano di azioni immediate su di essi. I messaggi di salvataggio dei caratteri inviati al server possono essere eseguiti in delta, con aggiornamenti completi solo in punti critici e questi aggiornamenti possono essere bufferizzati su un server di limitazione in modo che vengano inviati al server che detiene effettivamente i dati dei personaggi in modo costante, moda periodica - man mano che la base del tuo giocatore si ridimensiona, devi preoccuparti di ottimizzare l'IO del disco e il traffico di rete. Non vuoi provocare il crash del database dei personaggi.

La velocità e la dimensione dei pacchetti differiscono ampiamente da gioco a gioco, proprio come farebbe per i giochi non MMO. È davvero una cosa molto specifica e non ci sono standard generalizzati.


1
C'è anche un sequel del primo libro (Massively Multiplayer Game Development 2). A mio avviso non è una serie di libri terribilmente utile (non è sicuramente un libro make-a-MMO-in-x-hours completo come la maggior parte dei libri di sviluppo di giochi), ma discute alcuni dei problemi teorici chiesto in questa domanda. E forse sarebbe più utile per qualcuno che ha già sviluppato un MMO in parte.
Ricket,

5

Oltre alla risposta sopra, leggi su TCP_NODELAY e come funziona il ridimensionamento delle finestre. Comprendere i dettagli di TCP (e sì, si desidera utilizzare TCP non UDP a meno che la prospettiva di gestire gli aggiornamenti differenziali che arrivano fuori ordine ti sembri divertente) e la ritrasmissione è fondamentale per il controllo della latenza.


4
Ripeterò che se stai usando aggiornamenti differenziali (di solito diff diff binari di strutture in-game) e usi qualsiasi cosa con consegna fuori ordine (affidabile o no) te ne pentirai. Le persone a cui non piace il TCP nei giochi in genere non ne sanno abbastanza (come sapere cosa fa NODELAY). UDP ha senso per cose come i dati vocali, in cui i pacchetti fuori servizio possono semplicemente essere eliminati, questo è raramente il caso di un gioco.
coderanger

1
"raramente il caso in un gioco"? A condizione che il server mi fornisca gli stati di gioco autorevoli in ogni frame, non mi interessa cosa è successo in passato. Un semplice numero di frame in aumento monotono dai pacchetti UDP è perfetto per questo. Di quanti dati hai davvero bisogno per trasmettere in modo affidabile?
ChrisE,

2
"A condizione che il server mi stia dando un gioco autorevole afferma ogni frame" Certo, se lo consideri come un dato. Si noti che ho detto "se si utilizzano aggiornamenti differenziali" che sarebbe l'opposto dello stroboscopico dello stato completo di ogni frame. In un MMO con qualsiasi livello di complessità per il mondo diventerà rapidamente impossibile fornire aggiornamenti completi che frequentemente.
coderanger

1
Anche se invii lo stato completo delle cose che cambiano, si finisce con problemi di consegna fuori servizio in cui la fusione delle cose può diventare impossibile. Pensa agli aggiornamenti "x = 1, y = 2" e poi "y = 1, z = 2". Se quelli arrivano all'indietro, vuoi eliminare il "primo" in modo che il valore di y sia corretto, ma poi perdi la modifica in x.
coderanger

1
@Adam Ecco perché ho detto che dovresti andare a leggere le specifiche TCP e capire come funziona il ridimensionamento delle finestre e come interagisce con la ritrasmissione ;-) La riscrittura del TCP è fondamentalmente sempre sbagliata, le probabilità di rovinarlo sono quasi al 100%. Se desideri una consegna affidabile e in ordine, non dovresti utilizzare UDP.
coderanger,
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.