Cosa comporta la creazione di un gioco platform multiplayer in tempo reale?

Sto creando un gioco platform con una funzione "cooperativa" che mi piacerebbe lavorare su reti / Internet.

Ora ho letto la programmazione dei giochi di rete includendo articoli come ciò che ogni programmatore deve sapere sulla rete di giochi e quindi capisco la differenza tra tecniche come il blocco del peer-to-peer e le architetture di previsione Server-Client:

Ho concluso che per qualsiasi gioco in tempo reale che verrà riprodotto su Internet, il blocco del peer-to-peer semplicemente non è un'opzione.
Sono anche preoccupato che anche per un platform una semplice architettura client-server (senza una sorta di previsione del client) provocherebbe un gameplay degradato a causa del ritardo tra azione e reazione causato da un round-trip a un server. (Detto questo, voglio eliminare la necessità di un server centrale e quindi solo uno dei giocatori, il client, sperimenterà effettivamente questo ritardo).

Questo lascia la previsione del cliente, ma anche per un gioco semplice come un platform sembra ancora piuttosto complesso.

Come farei per creare un sistema predittivo client funzionante per un gioco platform multiplayer?

networking multiplayer platformer

— Justin
fonte

Una cosa di cui dovrai preoccuparti molto meno in una partita cooperativa è imbrogliare;)

— Jonathan Connell,

L'ho contrassegnato come non costruttivo. Le domande poste ("Quanto lavoro è necessario per scrivere un gioco in rete che utilizza la previsione del cliente? Finirò con metà della mia base di codice composta da codice di rete?") Sono troppo vaste e per nulla problematiche. La risposta sarebbe sostanzialmente "dipende", che non è una buona risposta.

— TravisG,

-1, "Quanto lavoro" è soggettivo.

— Tetrad,

Quanto lavoro, non è soggettivo in quanto è solo, ma dipende da alcuni fattori (dimensioni del gioco, requisiti di precisione, ecc.) Che tali fattori possono influenzare se è un sacco di lavoro, un piccolo lavoro o un punto intermedio (sebbene che tipo di lavoro è una domanda migliore); tuttavia, penso che l'OP stia davvero chiedendo quanto impegno è necessario e quanto grande sarebbe parte del codice di questo tipo di codice. Come indicato, potrebbe essere troppo ampio. Ho scelto un'interpretazione più ristretta e ho risposto. Penso che l'OP dovrebbe fare un po 'più di sforzo per restringere le domande ad alcuni punti molto specifici.

— Nate,

@Tetrad Siamo spiacenti, ho cercato di rendere questa domanda il più obiettiva possibile, ma la mia domanda si riduce a "è difficile creare un sistema predittivo client funzionante per un gioco di tipo Y" - in caso contrario, imparerò come vado, ma il mio tempo è limitato, quindi l'apprendimento che è troppo lavoro dopo X giorni di gioco è troppo tardi. Proverei a fornire maggiori dettagli su Y, ma non voglio rendere la domanda "troppo localizzata". Il problema principale qui è il movimento, che è comune a tutti i platform (voglio che altri trovino utile questa domanda). Se riesco a migliorare questa domanda, i suggerimenti sono apprezzati.

— Giustino,

Risposte:

Non penso che metà della tua base di codice si trasformerà in codice di rete se decidi di implementare una funzionalità come questa.

A mio avviso, il modo più semplice per farlo è configurare un server "centrale" (anche se ciò significa che un giocatore "ospita" il gioco e quindi si collega al proprio server) che accetta tutti gli input dell'utente il più velocemente possibile e lo restituisce a ciascun client.

Sul client, lo implementi in modo non diverso rispetto a quando stavi facendo un gioco cooperativo per due giocatori localmente, tranne che per leggere P1 dalla tastiera e P2 dalla rete.

Occorrerà che il server invii uno stato di gioco completo di tanto in tanto ed entrambi i client possono agganciarsi al nuovo stato di autorizzazione dal server oppure possono scorrere nel nuovo stato (per alcuni secondi). A meno che non si verifichino perdite orribili di pacchetti o tonnellate di client per server, questo approccio dovrebbe essere sufficiente per la situazione descritta.

— Nate
fonte

Il che è semplice come un approccio Server Client (tranne che un client ospita il server -> non hai bisogno di un server dedicato ma devi andare con qualcosa UDP + NAT Punchthrough che ha comunque bisogno di un server dedotto). In secondo luogo, proponi il metodo lockstep (mentre stai parlando di inviare gamestati completi), questo non è, IMHO, il metodo migliore se il gioco funziona su Internet (probabilmente è su LAN) dove client-server è molto più facile implementare.

— Valmond,

No, sto suggerendo di inviare occasionalmente stati di gioco completi, quindi il cliente può assicurarsi che non sia troppo lontano.

— Nate,

Ho un gioco in stile mMORPG completamente funzionale con previsione del client (il gioco è tutt'altro che finito ma funziona "OK") e ho qualcosa lungo 40.000 righe di codice per il server e il doppio per il client (aggiungi lo stesso importo per gli strumenti, ecc. .). La previsione non è probabilmente più di qualche centinaio di righe (se anche quello) e l'intera rete fa parte di un paio di migliaia di righe ma non più di 5.000 (dipende un po 'da dove si disegna la linea).

Domanda fuzzy risposta fuzzy ;-)

— Valmond
fonte

Una parte significativa del codice di rete può essere indipendente dal gioco a cui stai giocando. Per questo motivo e perché non hai familiarità con la rete, la prima cosa che ti suggerisco di fare è trovare librerie che funzionino per te. RakNet per esempio.

Una cosa che vorrai nel tuo codice di gioco è la capacità di gestire più stati di gioco diversi, che puoi utilizzare per l'interpolazione e la previsione. È abbastanza semplice da progettare in anticipo, ma può essere una notevole quantità di lavoro se stai modificando un gioco per giocatore singolo esistente.

Nota anche che se vuoi che estranei giochino un gioco peer to peer su Internet, probabilmente avrai bisogno di almeno un server da qualche parte che gestisca la lobby / il matchmaking.

— Adamo
fonte