Sincronizzazione multiplayer e pathfinding

Ho un'interfaccia di tipo punta e clicca su un client, che esegue un A * sul server, per la ricerca del percorso.

Il gioco è controllato come un RTS, ma il mondo è persistente, quindi i giocatori dovrebbero essere in grado di unirsi / partire in qualsiasi momento e sullo schermo ci saranno solo una trentina di unità al massimo.

Qual è il modo migliore per sincronizzare i movimenti del giocatore tra il server e il client, una volta calcolati i percorsi?

Il server deve sincronizzare i client in ogni fase / frame di animazione? o può semplicemente dire al client "vai in posizione X, Y" per ciascun nodo sul percorso e per ogni giocatore in movimento? O è meglio semplicemente eseguire i timer di animazione sia su client che su server e sincronizzarli implicitamente in quel modo?

Come sarebbe lo scambio di dati tipico per il movimento basato sul percorso?

MODIFICARE:

Alcuni di voi hanno suggerito lockstep, perché ho detto "RTS", ma il gioco non è un RTS, ha solo lo stesso tipo di interfaccia. La grande differenza è che devo essere in grado di far partecipare i giocatori e lasciarli in qualsiasi momento . Scusa per non essere più specifico.

Un'alternativa è fare il pathfinding sul client proprietario dell'unità. Questo ha il vantaggio di distribuire il lavoro in modo più uniforme. Uno svantaggio di fare tutto il pathfinding sul server è che il server deve fare tutto ciò; uno svantaggio di inviare ai client solo comandi 'sposta su X, Y' è che ogni cliente deve trovare ogni singolo percorso. Invece, ogni 'tick' nel ciclo di blocco-passo, ogni client dice al server, letteralmente, ogni passo successivo della propria unità. Il server si assicura che l'unità possa effettivamente spostarsi lì e sposta l'unità. Poiché il client non ha tutte le informazioni (in particolare, cosa stanno facendo le unità dell'altro client), un comando di movimento non valido non viene trattato come un errore. Questo sta cedendo un po 'di larghezza di banda per guadagnare più tempo per il calcolo dei percorsi.

Sostituisci server con peer; questo metodo funziona anche per i giochi peer-to-peer, purché si assicuri che l'ordine in cui vengono considerati i movimenti delle unità sia lo stesso su tutte le macchine.

I giochi RTS in genere hanno lockstep-sync (la sincronizzazione avviene in ogni frame). Raccontare qualsiasi percorso al client consentirebbe ai client compromessi di abusare delle informazioni aggiuntive.

Nessuno dei due. L'unica cosa che dovresti inviare sono i comandi. Esempio: queste 20 unità dovrebbero spostarsi su (X, Y) e quindi consentire a ciascun giocatore di capire come ci si arriva. La parte difficile è assicurarsi che facciano esattamente la stessa cosa. Per raggiungere questo obiettivo viene utilizzato un modello lockstep, i collegamenti sottostanti dovrebbero spiegarlo in dettaglio. Inoltre, dovresti sincronizzare solo i pezzi importanti. Tutto ciò che non cambia il gameplay non dovrebbe essere sincronizzato. Le animazioni nei giochi RTS sono generalmente solo per il lato visivo.

Un'altra cosa, i giochi RTS di solito non sono client-server, ma P2P. In questo modo uno dei giocatori non può imbrogliare perché quando viene rilevata un'incoerenza, ti disconnetti semplicemente.

Ecco qualcosa per aiutarti: http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php http://altdevblogaday.com/2011/07/09/synchronous-rts-engines-and- a-tale-of-desyncs / http://altdevblogaday.com/2011/07/24/synchronous-rts-engines-2-sync-harder/

Una volta calcolato il percorso, il server utilizza semplicemente quel percorso per controllare il personaggio. La presenza di un percorso non fa differenza per questo problema: si inviano comunque gli stessi dati, che si tratti di regolari aggiornamenti di posizione o altro. Di solito va bene inviare posizioni regolari (interpolate sul client per lisciarle) e un messaggio separato quando l'unità si ferma.

Nel mio gioco (un gioco di tipo RPG multiplayer) invio parti del percorso al client (per NPC nelle vicinanze), vale a dire. le 3 posizioni successive e l'ora in cui l'NPC dovrebbe essere lì. Per i giocatori invio solo l'ultima posizione valida + il suo timestamp in modo che sul cliente posso fare i conti morti (o qualcosa di più elaborato se lo si desidera).

Funziona completamente bene soprattutto perché non ci sono collisioni tra giocatori / NPC (con un ritardo basso non si nota davvero nulla, con un, diciamo 250+ msec si nota la differenza se si possono vedere le due schermate (di due giocatori ) allo stesso tempo, ma non è ancora realmente rilevabile su "una schermata").

Quindi direi: vai con la creazione di server (posizioni di validazione + timestamp dei giocatori e anche per l'IA all'inizio, puoi creare un sistema più elaborato per l'NPC in seguito senza grossi problemi) + previsione del client.

ps. Uso una precisione di millisecondi che funziona perfettamente, tranne per il fatto che un int firmato vale solo per circa 3 settimane prima di dover riavviare il server.

Potresti anche voler controllare la previsione del tempo (ad es. Cercare di sincronizzarti il ​​più strettamente possibile con il server).