Come gestire un gran numero di pickup in un gioco MMO

Come possono gestirli con giochi come Minecraft o qualsiasi altro gioco MMO con pickup?

Di 'terreno genera 3 gocce di raccolta di "sporcizia" ogni volta che si scava detto terreno. Supponiamo che ogni elemento abbia un'animazione di rotazione calcolata su ogni fotogramma. Se il numero di pickup nel mondo aumenta molto, sarebbe un inutile sovraccarico nel calcolo del frame per un client in un determinato server, poiché è probabile che molti di questi elementi di pickup siano lontani anni luce da te.

Quindi quello che ho pensato è che devi "fare cose" solo con i pickup vicini al giocatore locale, ma ciò implicherebbe comunque che ogni fotogramma che devo controllare se qualsiasi altro oggetto pickup sia abbastanza vicino da dover iniziare ad animare.

La mia vera domanda è: in che modo altri MMO hanno risolto questo problema?

Semplicemente caricando solo quelle parti del mondo nella memoria che sono vicine al giocatore. Qualsiasi altra cosa è sospesa sul disco rigido. Quando c'è un piccolo oggetto che si trova a circa due chilometri di distanza, il giocatore non può vederlo e non può interagire con esso. Quindi non c'è motivo di aggiornarlo o inviarlo alla GPU per il rendering. Più piccolo è l'oggetto e il suo raggio di interazione, più basso è il raggio intorno al giocatore dove è necessario caricarlo.

Per quanto riguarda lo scoprire cosa c'è vicino al giocatore: ciò si riduce principalmente alla memorizzazione del mondo in una struttura di dati ottimizzata per la ricerca spaziale. I buoni candidati per questi sono hashing spaziale e alberi multidimensionali .

Hai due cose molto diverse da gestire:

1. Il server deve gestire tutto il mondo, in modo autorevole. Per questo, è necessaria la comunicazione con N clienti (dove N è "massiccio").

2. Il cliente potrebbe , in linea di principio, conoscere tutto il mondo, ma non è necessario . Per il cliente, è sufficiente sapere cosa c'è nelle vicinanze del giocatore. Supponendo ad esempio un partizionamento simile a una griglia piuttosto grossolana, dovrebbe conoscere solo la cella del giocatore e le 26 celle attorno al giocatore (o 8 celle nel caso tu abbia una griglia 2D). Una griglia un po 'più fine è migliore, ma hai l'idea.

Ora, molti pickup, cos'è "molto"? Puoi scavare forse 5 cose al secondo, ovvero due dozzine di numeri che devono essere aggiornati sul server e il server potrebbe doverli trasmettere a qualche altro giocatore la cui area di interesse si sovrappone al tuo cellulare. Per un computer, questa è una quantità di dati piuttosto ridicola e una quantità trascurabile di calcolo. Può diventare una sfida quando ci sono centinaia / migliaia di giocatori nella stessa cella (quindi il tuo partizionamento è troppo approssimativo).

Il server non ha bisogno di sapere, né di preoccuparsi della rotazione dei pickup o di tali dettagli. Perché dovrebbe?

Al cliente non importa nemmeno, dal momento che questo è solo un piacere per gli occhi che il cliente può recuperare al volo.

Ciò che è necessario dal punto di vista del server è sapere che stavi scavando in (30, 40, 50) nel nodo in cui ti trovi e decide che questo genera ad esempio tre oggetti di tipo 5 o un oggetto di tipo 7 con un conteggio di 3. Questo è tutto ciò che interessa, ed è tutto ciò che ti dice. Comprenderà inoltre che le informazioni nei dati inviati a qualcuno spostino la sua area di interesse sulla cella della griglia in seguito (supponendo che siano ancora lì per allora).

Al cliente vengono comunicati tre oggetti generati lì, blah blah. Ora, se il client visualizza una mappa di arte ASCII in cui ora c'è una 'D' o se mostra un mucchio di terra rotante, è lo stesso. Anche se le pile hanno rotazioni diverse o se solo quelle vicine al tuo giocatore ruotano è lo stesso. È solo roba che viene visualizzata sul monitor, non influisce su nessun altro.

Quindi, nel caso concreto in cui si desidera ruotare solo pile di sporcizia vicine, è possibile effettuare un controllo della portata su tutti gli oggetti che si conoscono. Poiché il set di dati non è grande, anche la forza bruta su tutto funzionerà.

Puoi (e dovresti) a seconda delle dimensioni del tuo partizionamento, eliminare banalmente le celle della griglia che sono troppo lontane.

Puoi, ovviamente, suddividere ulteriormente il tuo cellulare in sottospartizioni e usare qualcosa di super intelligente. Usa un kd-Tree se vuoi, ma non aspettarti enormi guadagni. Puoi eliminare le cose con Manhattan distace oppure puoi ordinare le tue cose in una piccola griglia di tua scelta ... ma perché?

Un controllo di distanza (distanza veramente quadrata, ma è la stessa per te) è solo due moltiplicazioni e un'aggiunta (ottimizzata per MUL, MADD, quindi in realtà solo due operazioni), seguita da una diramazione o da una mossa condizionale. È abbastanza veloce come qualsiasi altra operazione che non pota intere celle della griglia alla volta. In realtà, questo è qualcosa che si potrebbe anche fare sulla GPU ...

Vedendo come avrai qualche centinaio o al massimo qualche migliaio di controlli di distanza rispetto alla stessa posizione (la distanza al quadrato funziona bene), non hai davvero molti problemi a fare quel calcolo, anche di più in quanto è piuttosto un cache- iterazione amichevole su memoria contigua e con mosse condizionate, è sporco a buon mercato. Qualcosa di simile (pseudocodice) rot = r[i] + 1; r[i] = ((dx*dx+dy*dy) < DIST_SQ) ? rot : r[i];. Questa è un'iterazione su una matrice di poche centinaia di valori per frame. Al computer non potrebbe fregare di meno di farlo, sono carichi e archivi contigui, ALU semplice, senza rami e solo poche migliaia di iterazioni.

Questo (molti-a-uno) non è la stessa classe di problemi (molti-a-molti) del server. Davvero, il problema non è il client.

@ T.Sar scrive in un commento che dovresti esaminare il concetto di "pezzo caricato" di Minecraft per ulteriori informazioni. Se lo fai, tieni presente che questo è piuttosto complicato in Minecraft a causa delle persone che costruiscono macchine nel gioco.

Segue una versione molto semplificata:

Il mondo è diviso in regioni quadrate (blocchi). In Minecraft c'è anche una divisione in altezza ma la maggior parte dei mmos non ne ha bisogno.

Il client di gioco si preoccupa solo delle regioni vicine al giocatore. È molto più semplice che disegnare un cerchio attorno al giocatore, ma perfettamente abbastanza buono.

In Minecraft, le regioni sono 16x16 blocchi e il client conosce circa 9x9 regioni, 4 regioni in ogni direzione. (4 regioni est + regione giocatore è in + 4 regioni ovest = 9 regioni totali. Stesso nord / sud)

Non c'è nulla di magico in questi numeri, usa tutto ciò che ha senso nel tuo gioco.

Il client anima solo le cose all'interno di quest'area. Il server calcola solo cose come mostri erranti in regioni vicine ad alcuni giocatori.

Quando un giocatore cammina all'interno di una regione, non accade nulla di speciale, quando attraversa un confine di regione il "bordo dell'animazione" viene spinto sopra una regione. Il client deve quindi chiedere al server le aree che vede ora.

Non c'è nulla di sbagliato nell'avere diversi limiti di animazione nidificati. Ad esempio, gli oggetti animati cadono in un'area 3x3, i mostri erranti in un'area 5x5 e mostrano semplicemente il paesaggio in un'area 9x9.

Il server mantiene una "versione bloccata" delle regioni che nessun giocatore vede. Se ciò richiede molta memoria, è possibile scaricarli dopo un po '. Quando arriva un giocatore successivo, la regione viene ricaricata senza che l'oggetto cada. La prossima volta devi essere più veloce, Giocatore 1.