Prestazioni lato server FPS multiplayer

Ciò è correlato alle prestazioni MMO, tranne per il fatto che la domanda riguarda la larghezza di banda. Si tratta del carico della cpu.

Ho messo insieme un semplice FPS usando node.js e webGL. È estremamente semplice, molto simile al clone BuddyMaze di MIDI Maze. Sta succedendo molto poco, tutti si muovono in due dimensioni (senza altezza), sparano proiettili semplici e si imbattono in muri.

In questo momento, se faccio connessioni multiple al server in cui ogni giocatore spara rapidamente mentre gira in cerchio, posso ottenere circa 15-20 giocatori nel gioco prima che il server raggiunga il massimo e rallenti. E questo è quando si esegue a 30 fps sul server. A 10 fps, ottengo circa 25-30 connessioni. Questo è piuttosto brutto, dal momento che il gioco avrà molto altro da fare presto e dovrò adattarmi a più giocatori affinché questo sia uno sforzo fattibile.

Mio fratello ha appena indicato alcune statistiche sul server TF2 del suo collega. Il suo server ha specifiche inferiori rispetto al nostro, eppure esegue TF2, ovviamente un gioco molto più complesso, con ben 500 tick al secondo, con 36 utenti per core. Inoltre, attualmente consumiamo molta più larghezza di banda rispetto a loro, ma non abbiamo ancora provato a ridurlo.

Com'è possibile? Che tipo di trucchi ci sono per aumentare le prestazioni del server a questa portata? Alcune cose che conosco includono:

• Abbassamento del framerate sul server e interpolazione delle posizioni sul client. Ho avuto qualche vantaggio, ma chiaramente il server TF2 non si preoccupa nemmeno di questo.
• Fare cose costose come il rilevamento delle collisioni sul client e verificarlo raramente sul server. Non l'ho ancora spostato, stasera lo farò. Anche così non mi aspetto un guadagno così enorme.
• Suddividere il campo di gioco in regioni (alberi quad) per ridurre al minimo i calcoli. Non ne ho ancora avuto l'opportunità.
• Ho considerato la sfortunata possibilità che node.js sia molto più lento di qualsiasi altro TF2 stia usando e potrebbe non essere adatto a questo tipo di attività ad alta intensità.
• È tutto nella magia della configurazione del server?

Quindi quali sono gli altri trucchi del settore per fare solo il minimo richiesto sul server ma avere comunque un'esperienza di gioco impeccabile? Esiste un grande conflitto tra "differisci al client per risparmiare tempo della CPU" e "non fidarti del client", quindi forse aiuta a sapere dove viene tracciata la linea in varie situazioni?

Aggiornare

La profilazione è davvero l'unico mantra che abbia mai trovato assolutamente infallibile. Ho rapidamente avvolto alcune funzioni di temporizzazione attorno al mio codice (grazie, FP!) E ho scoperto ciò che non mi sarei mai aspettato: l'atto di trasmettere i dati agli account dei clienti per quasi tutto il tempo di esecuzione. In particolare, circa il 90% di esso. Ulteriori test hanno dimostrato che questa volta dipende sia dal numero di client che dalla dimensione dei dati, ma soprattutto da quest'ultimo. Con un carico di 20 utenti, ho ridotto il mio tempo di trasmissione del 90%, da 24 ms a poco più di 2 ms inviando solo "{}" anziché i dati completi. Ma con solo 5 utenti, la trasmissione dura circa 0,5 ms. Quindi ho chiaramente bisogno di fare un po 'di ottimizzazione qui.

Il primo miglioramento più evidente è il controllo della linea di vista. Ciò ridurrebbe sia il numero di persone che si preoccupano dei dati, sia la quantità di dati inviati alle parti interessate. Ci sono altri trucchi in questo regno che posso provare, che si concentrano sulla minimizzazione del costo della mia operazione di trasmissione?

Il tuo server non dovrebbe inviare lo stato di tutti i giocatori a tutti i giocatori ad ogni tick. Invece dovrebbe inviare un messaggio appositamente predisposto a ciascun client ogni 500 ms dicendo "questi x giocatori nella tua porta di visualizzazione dovrebbero trovarsi a queste coordinate in 500 ms". Il più delle volte questo funzionerà bene, ma se il server si rende conto che ha fornito informazioni errate, invia semplicemente un messaggio aggiuntivo.

Ciò ridurrà drasticamente il traffico di rete.

Un'altra cosa da considerare è quella di non avere tick di gioco sul server, ma piuttosto che il client invii messaggi solo quando si verifica un'azione (cambio di direzione, tiro sparato) e quindi calcola in anticipo sul server quando viene ricevuta un'azione.

Ho considerato la sfortunata possibilità che node.js sia molto più lento di qualsiasi altro TF2 stia usando e potrebbe non essere adatto a questo tipo di attività ad alta intensità.

È probabilmente questo. Il server di TF2 è scritto usando C / C ++ e quindi sarà più veloce di node.js (che, se ricordo bene, usa Javascript interpretato in Java)

Quake basato su WebGL di Google utilizza java per il server e il codice sorgente è disponibile qui: http://code.google.com/p/quake2-gwt-port/ . Potrebbe valere la pena guardarlo per vedere come è fatto. Mi chiedo anche cosa intendi quando parli di avere un framerate sul server. Non c'è motivo di rendere nulla sul server, dovrebbe essere lì solo per l'elaborazione dei comandi inviati dal client.

Infine, la regola "non fidarti del cliente" è più importante che scaricare costosi calcoli sul client nella speranza di migliorare le prestazioni. Soprattutto qualcosa di importante come il rilevamento delle collisioni. Doppiamente quando il tuo gioco è basato su Javascript, e quindi abbastanza facile da hackerare (rispetto a qualcosa come TF2 che viene compilato).

So che questa non è una grande risposta, ma spero che ti indichi in alcune direzioni che potrebbero aiutare a migliorare le prestazioni.