Attualmente sto pianificando un semplice gioco multiplayer online. Ed ecco la domanda. Ha senso rendere l'intera logica di gioco sul server e inviare l'input dal client al server? Quali sono i pro e i contro o ci sono dei motivi per cui non dovrei farlo?
Risposte:
Non si desidera inviare l'input del giocatore al server. Quello che probabilmente vuoi fare è inviare una rappresentazione astratta di ciò che il giocatore vuole fare al server, e quindi eseguire la logica lì.
Allo stesso modo non devi necessariamente rispedire tutto ciò che il cliente deve fare. Ad esempio, è possibile inviare una sorta di messaggio che dice "NPC X morto" e il client determina quale animazione / suono riprodurre. Roba del genere.
Il trucco è trovare la linea in cui la larghezza di banda e la potenza di elaborazione (sul server) sono trionfate impedendo alle persone di barare. Di solito prendi qualsiasi tipo di decisione autorevole che cambia il gioco solo sul server e lasci tutto il materiale visivo accessorio al client.
Ci sono molte domande più specifiche su questo argomento in tutto il sito. Per esempio:
Chi esegue i calcoli AI in un MMO?
L'host del gioco dovrebbe essere l'autorità o un altro client stupido?
Bene, hai delle risposte, ma la tua vera risposta è "provare te stesso". Le cose differiscono da gioco a gioco.
Ho fatto un paio di giochi multiplayer per alcuni corsi di progettazione di giochi di rete distribuiti. Il più impegnativo è stato fare un gioco d'azione in tempo reale in cui molti giocatori coinvolti e inviare input come l'inferno. Quando si arriva a quel punto, tutto diventa un problema. Come vedi il primo link inviato da Tetrat, anche determinare una collusione diventa un problema. E ascolterai termini come ritardo, interpolazione, estrapolazione, previsione ... Ma se non hai mai provato a scrivere codice da zero, accetteresti queste parole e non sapresti cosa significano realmente.
La mia raccomandazione è:
Passaggio 1 Per ora
basta iniziare con una progettazione basata su server completamente autorizzata. Come hai detto, basta inviare gli input dell'utente al server e lasciare che il server faccia tutto e i client ottengano i risultati. Il tuo gioco funzionerà in modo coerente. Ma quando guardi i tuoi clienti, noterai alcuni ritardi, alcuni problemi di teletrasporto, non movimenti fluidi ... ect.
Passaggio 2
Inizia a risolvere i problemi sul lato client. I problemi di teletrasporto, ad esempio. Il tuo personaggio era a (0,0) e il server ha detto che ora sei a (100.100). Il tuo personaggio si teletrasporterà a (100.100), il che non è carino. Arriva l'interpolazione. Dovresti avere un codice sul lato client che farà scorrere il carattere da (0,0) a (100, 100) in modo uniforme. Sì, sposterai il tuo personaggio da (0,0) a (100.100) ma quanto velocemente? Per ora puoi semplicemente usare la differenza di orario tra ogni aggiornamento del server. Se il tuo server invia 10 pacchetti in un secondo, il che significa un ritardo di 100 ms tra ciascun pacchetto.
Passaggio 3
Ora il tuo gioco è già buono per le reti veloci in cui c'è un ritardo di (1-50) ms. Ma è condannato in caso di perdita di pacchetti, latenza elevata o calcolo impiega molto tempo nel server ... ect. In quelle situazioni che noterai quando premi la freccia sinistra, vedrai il tuo personaggio muoversi a sinistra con un ritardo di 200 ms. Il ritardo tra il tuo pacchetto va al server, il tempo di calcolo e ti viene restituito con la tua ultima posizione. Questo è negativo, il peggior svantaggio della progettazione autorizzata dal server. Il giocatore vuole che il suo personaggio si muova a sinistra non appena preme a sinistra, non puoi farlo aspettare. Fortunatamente il client ha anche lo stesso codice del server, quindi perché non eseguirlo immediatamente sul client e correggere il risultato finale con la risposta dal server? Ecco cosa è sostanzialmente la previsione di input. Il cliente preme a sinistra, il codice al suo fianco lo sposta a sinistra, dopo qualche tempo diciamo 200 ms, la posizione reale viene dal server e il client corregge la sua posizione con esso. Se tutto è andato bene, il cliente non noterà nulla, anche il "passaggio 2" ci aiuterà in questo.
Bene, net ha molti tutorial e cose su questo argomento. Ma ci sono 2 che mi piacciono molto:
Davvero buono, copre i punti oscuri: Networking multiplayer Valve-Source Engine
Tipo di storia, divertente da leggere e vale la pena: 1500 arcieri il 28.8 ,
Professionisti:
Contro:
La logica lato server crea anche problemi di scalabilità - devi fare tutto il lavoro per tutti i client sul tuo server - versi che consentono a ciascun client di fare la propria parte del lavoro totale.
Dipende dal gioco che si desidera creare e dalla parte del gioco. Se si sviluppa un RTS (o qualsiasi gioco con un modello bloccato), allora si dovrebbe assolutamente inviare solo l'input e quale fase di simulazione l'input è stato ricevuto.
Se vuoi fare uno sparatutto puoi usare sia le funzioni di input che quelle astratte. Se prendi Unreal Tournament 3 come caso, hanno creato il multiplayer principalmente tramite chiamate di funzione replicate.
Per il movimento prendono l'input del giocatore (compresso in un singolo bit per ogni azione) rotazione delta, accelerazione e timestamp e lo inviano al server.
Per altri scopi come l'arma si sincronizzano quando spari (AFAIK, non hai ancora approfondito questa parte).
Per valori più statici / meno spesso modificati come integrità, inviano la variabile al client o al server a seconda di ciò che il programmatore ha specificato.
E per i giochi non RTS, ricorda la previsione del cliente.