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!

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.