(Unity) Soluzione di rete ottimizzata per molti oggetti in movimento


8

Attualmente sto intraprendendo un progetto piuttosto ambizioso. In breve, è un gioco di strategia multiplayer in tempo reale che ha una meccanica batterica.

In sostanza, ho due giocatori remoti nell'ambiente e possono generare unità simili a batteri che si attaccano e si moltiplicano, duplicandosi fino a quando non viene raggiunto un limite di risorse. Ciò comporta spesso il rendering sullo schermo di oltre 200 oggetti di gioco, ognuno con il proprio stato e movimento. Questo suona male, ma il gameplay locale contro un bot è in realtà molto buono, e sono riuscito a renderlo abbastanza performante.

Tuttavia, il problema si presenta quando provo a collegare in rete questo gioco. Ho già provato a seguire questa guida per implementare questa funzionalità: http://www.paladinstudios.com/2013/07/10/how-to-create-an-online-multiplayer-game-with-unity/

Questo produce un'esperienza di gioco piuttosto lenta e spiacevole anche con la migliore latenza. Ciò è probabilmente dovuto alla necessità di trasmettere dati di movimento per centinaia di unità.

La domanda che sto ponendo:

Come posso ottimizzare la rete e la sincronizzazione di molte unità mobili tra due client?

Ho già pensato a un modo per farlo. Dopo aver generato un'unità, viaggeranno solo in una direzione fino a quando non colpiscono qualcosa - forse posso sincronizzarmi solo quando le unità vengono generate e quando interagiscono con un altro oggetto? Questo avrebbe molti benefici? Qual è il modo ideale per implementarlo?

Grazie in anticipo per le risposte!


È probabile che un modello lockstep sia quello di cui ho bisogno? clintonbrennan.com/2013/12/lockstep-implementation-in-unity3d
Rachel Cabot

Sono dietro un firewall e non riesco ad accedere all'esempio che hai collegato, ma hai provato a serializzare solo l'ID oggetto, la posizione e i vettori di velocità per ogni frame? A seconda di quanto sia intelligente con l'algoritmo di serializzazione, è possibile ridurre le informazioni sullo stato a 7 byte per oggetto. Se ti assicuri che il client assume un ID mancante dall'aggiornamento come un decesso e quelli nuovi come spawn, non dovresti avere problemi.
Stephan,

Risposte:


1

Per oltre 200 oggetti in movimento, vorrai sicuramente fare il passo del gioco. Con lockstep, arriva la necessità di determinismo, ma ciò non dovrebbe essere troppo difficile per i batteri (che possono essere simulati con collisioni cerchio-cerchio).

Se non ti dispiace per la mia spudorata auto-spina e vuoi un esempio con la rete e la logica di simulazione di un gioco lockstep, dai un'occhiata a questa risorsa gratuitamente: https://www.assetstore.unity3d.com/en/#!/ contenuto / 36206 . Sfortunatamente, quella versione non include tutto il codice sorgente, ma sentiti libero di hackerarlo con la mia benedizione;). Ecco un video di un primo test di DPhysics: https://www.youtube.com/watch?v=NEzOghxfMdU .

L'essenza di lockstep sta sincronizzando l'input anziché l'output. Questo perché con una simulazione sincrona, l'unica cosa che tutti i client non conoscono sono gli input di altri client. L'articolo che hai collegato nel tuo commento lo spiega abbastanza bene. Non sono sicuro di quanto mi piacerebbe che io spiegassi la sequenza di blocco, quindi la interrompo qui ed espanderò questa risposta se hai altre domande.

Aggiornamento: pensalo come un server autorevole, tranne per il fatto che il server invia input anziché lo stato del gioco. Dal momento che ogni giocatore può produrre lo stato del gioco per se stesso dall'input, non è necessario che il server distribuisca il gamestate.


1
Questo approccio può potenzialmente portare alla de-sincronizzazione, anche se tutto è deterministico, proprio a causa della latenza tra gli input condivisi. Ad esempio, prendi un gioco in cui i giocatori cercano di bloccare il movimento di un oggetto posizionando i muri. Sullo schermo di un giocatore potrebbe aver cronometrato il posizionamento correttamente e l'oggetto è bloccato. Ma la replica di ciò sull'altro client potrebbe arrivare in ritardo e, una volta posizionato il muro, l'oggetto ha già superato quella posizione. A seconda delle meccaniche di gioco, potrebbe essere necessario inviare periodicamente aggiornamenti "big picture" per risincronizzare i client.
Acidictadpole,

Buon punto. Vi è 0 potenziale di desincronizzazione se questo viene fatto correttamente. Se un pacchetto viene perso o arriva molto tardi, il client non può avanzare al frame successivo: dovrà attendere fino all'arrivo del pacchetto per eseguire il frame corrente. I frame possono essere rappresentati con numeri interi. Il server distribuisce i pacchetti contrassegnati con un numero intero per ciascun frame.
JPtheK9,

Controlla tu stesso la rete e la logica dei frame.
JPtheK9,

1
@ JPtheK9 "dovrà aspettare fino all'arrivo del pacchetto per eseguire il frame corrente" E se il pacchetto non arrivasse mai?
Stephan,

Richiedine uno nuovo.
JPtheK9,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.