Come gestire i computer più veloci in un videogioco in tempo reale client / server

La tua terza idea sembra essere la più vicina a quella che penso come la soluzione del settore per questo tipo di problema.

Quello che stai descrivendo è comunemente definito Zecca . In ogni tick, un numero fisso di azioni verrebbe elaborato per ogni cliente in serie. Spesso, i server di gioco hanno alcune azioni parallele quando sono in grado di farlo, ma questo è un problema molto più complicato.

Un segno di spunta sarà probabilmente sotto forma di 1 / N secondi, N è il numero di tick al secondo o Tickrate. Questo tickrate potrebbe essere molto spesso o molto poco frequente, a seconda del caso d'uso. Il mio suggerimento personale sarebbe quello di evitare un tickrate superiore a 60 tick / secondo a meno che non siate sicuri di averne bisogno di più. Probabilmente no:)

Le azioni dovrebbero essere atomiche. Ad esempio, in slither.io, un'azione come lo spostamento non dovrebbe immediatamente elaborare qualcosa come rompere la catena, a meno che il giocatore che hai colpito abbia già preso la mossa. Questo può sembrare banale per qualcosa a livello di pixel, ma se hai a che fare con il movimento basato su tessere, diventa molto più ovvio e garantisce equità. Se il giocatore A si sposta per affiancare X, Y e il giocatore B è attualmente su quella tessera, devi assicurarti che entro la fine del segno di spunta, il giocatore B rimarrà su quella tessera perché qualsiasi azione si svolga tra loro.

Inoltre, direi di evitare che qualcuno dei tuoi calcoli venga eseguito sul lato client a meno che non siano fatti indipendentemente sul lato server. Questo diventa complicato e costoso con la fisica (molti giochi optano per una frequenza di tick più bassa per la fisica rispetto a molte altre azioni ed eventi a causa di ciò)

Per riferimento, ecco un buon collegamento per integrare la tua comprensione dei server di gioco e della rete multiplayer.

Infine, direi di non lasciare che l'equità rovini il tuo server. Se ci sono degli exploit che causano il tuo gioco ingiusto, aggiustali. Se si tratta di un computer migliore con un leggero vantaggio, direi che potrebbe non essere un grosso problema.

Il seguente sistema si assicura che tutti i client e il server condividano quasi lo stesso stato di gioco in qualsiasi momento.

Avere lo stato del gioco su client e server.

Quando un client tenta di utilizzare un comando (mouse, tastiera, ecc. altro input), controlla il suo stato del gioco se è valido.

Se lo è, invia il comando al server, senza eseguirlo sul client di invio.

Quando il server riceve il comando, controlla il suo stato del gioco se è valido.

Se lo è, inviare il comando a TUTTI i client con la data futura esatta dopo quello che dovrebbe essere terminato in esecuzione sul server, quindi eseguire le azioni richieste dal comando dopo un ritardo pari al tempo minimo per inviare il comando ai client. quindi registra la data, questo aiuta a fare previsioni future. Se il tempo varia troppo, rendi il tuo sistema di gioco più deterministico nel tempo.

Quando un client riceve un comando dal server, controlla il suo stato del gioco se è valido esegui immediatamente le azioni richieste dal comando, quindi guarda la data corrente e confrontala con la previsione della data ricevuta. Se non è valido, il client non è sincronizzato. (Tutti i client con una connessione simile ricevono allo stesso tempo)

Se la data è precedente, hai riscontrato un problema nel passaggio precedente, risolvilo. Se la data è leggermente dopo non fare nulla, Se la data è lunga, il client non è sincronizzato, cioè il client resta indietro troppo.

Quando un client non è sincronizzato, richiedere una copia dell'intero stato del gioco del server e utilizzarlo. Se ciò accade troppo spesso, risolvilo perché è più costoso che inviare comandi.

Sui client, visualizza i contenuti sullo schermo SOLO quando non c'è nient'altro da fare. In scenari semplici la funzione di rendering richiede solo lo stato di gioco corrente come input.

Inoltre puoi ottimizzare molto, utilizzando i sistemi predittivi, i comandi di raggruppamento, il rendering solo delle differenze ecc ...

La convalida dovrebbe essere diversa, ad esempio, è compito del server limitare le richieste di comando / unità di tempo.

Non so se questo è un problema delle librerie o dell'ambiente che stai usando, ma penso che ti stai avvicinando completamente.

Nella stragrande maggioranza dei giochi multiplayer, è solo il server a fare calcoli reali. I client sono solo stupide macchine IO in cui solo il vero problema di prestazioni è il disegno di grafica 3D. E in quel caso non importa se il client può funzionare a 20 o 200 FPS, perché questo influisce solo sulle immagini. Ciò significa che "l'aggiornamento del client" non ha assolutamente significato. Il cliente potrebbe provare a "prevedere" ciò che il server potrebbe calcolare, ma è solo per appianare la sensazione del gameplay e non ha alcun impatto effettivo sul gameplay stesso.

faster keyboard speeds

Non so nemmeno cosa significhi. La maggior parte delle persone non riesce nemmeno a tenere il passo con la velocità delle tastiere di fascia bassa, quindi come potrebbe influire sulle prestazioni dei giocatori?

Altrimenti, la domanda sembra abbastanza ampia e dovresti invece concentrarti su un singolo problema reale, invece di cercare di creare un problema "generale" che potresti non avere nemmeno.