Differenze di stato di invio (delta) e connessioni non affidabili

8

Stiamo costruendo un gioco multiplayer in tempo reale, in cui ogni giocatore è responsabile di riportare il proprio stato su ogni iterazione del ciclo di gioco.

Gli aggiornamenti di stato vengono trasmessi utilizzando UDP inaffidabile .

Per ridurre al minimo l'invio di dati di stato, abbiamo creato un sistema che invierà solo delta (indipendentemente dai dati di stato che sono stati modificati).

Questo metodo tuttavia è imperfetto, poiché un pacchetto perso significherà che gli altri giocatori non riceveranno il delta, facendo in modo che il gioco si comporti in modo inaspettato.

Per esempio:

Supponiamo che lo stato sia composto da: {positionX, positionY, health}

Frame 1  - positionX changed --> send a packet with positionX only.
Frame 2 - health changed // lost !
Frame 3 - positionY changed --> send a packet with positionY only.

// Altri giocatori non conoscono i cambiamenti di salute.

Come si può superare questo problema allora? l'invio di tutti i dati non è sempre fattibile.

— spaceOwl
fonte

7

Anche se stai inviando dati utilizzando UDP, dovrai comunque aggiungere la tua forma di affidabilità per gestire situazioni come questa. UDP ti dà solo la flessibilità di fare quello che vuoi, piuttosto che gestire il formato affidabile ma meno flessibile della comunicazione TCP. Messaggi di conferma o pacchetti di conferma di un tipo devono essere utilizzati quando è necessaria la ricezione di informazioni, altrimenti il cliente non ha modo di sapere se i dati inviati devono essere reinviati. Ad esempio, se invii informazioni critiche e non visualizzi una risposta entro un determinato periodo di tempo a conferma della ricezione di tali dati, rispediscili.

— Evan
fonte

2

Battimi. Tuttavia, va notato che non è necessario garantire valori abbastanza volatili, come la posizione e altri dati di fisica. Anche nel caso in cui sia sbagliato su un determinato fotogramma, verrà comunque corretto il fotogramma successivo.

— jmegaffin,

1

Un buon punto, questo è visto più spesso nei giochi quando improvvisamente un personaggio si sposta in una nuova posizione molto rapidamente (o si teletrasporta lì tutti insieme). La maggior parte dei giochi lo gestisce in diversi modi, ma l'obiettivo è lo stesso. Il server ha semplicemente aggiornato la posizione dell'entità e il client sta aggiornando immediatamente o aggiornandolo con un tempo delta molto elevato in pochi frame.

— Evan,

3

Puoi anche aggirare il problema inviando un aggiornamento completo dello stato dal server ai client, ad esempio ogni secondo. Se un client non ha ricevuto un pacchetto, si comporterà in modo errato fino a quando non riceverà l'aggiornamento completo dello stato. Quindi sarà di nuovo sincronizzato.

— Matthias
fonte

3

Molti giochi utilizzano sia UDP che TCP / IP per inviare / ricevere dati e, a seconda della frequenza con cui i dati vengono inviati, viene utilizzato un protocollo diverso.

Per esempio:

UDP: aggiornamenti di posizione e qualsiasi altra cosa che potrebbe essere potenzialmente inviata / ricevuta più volte al secondo.

TCP / IP: azioni di inventario, azioni di magia / abilità (la maggior parte delle azioni eseguite dall'utente)

Dipende molto dalla quantità di traffico di ogni articolo. Se ti accorgi che stai inviando aggiornamenti HP abbastanza frequentemente, forse devono essere su UDP.

— UnderscoreZero
fonte

1

Il TCP non viene generalmente utilizzato per qualsiasi cosa che richieda precisione in tempo reale perché è in grado di causare picchi di ritardo elevati.

— TheNickmaster21

È buono se vuoi assicurarti che il tuo pacchetto arrivi lì. Roba come gli aggiornamenti posizionali non va bene per questo, ma se vuoi assicurarti che l'utente abbia premuto un pulsante in un momento specifico TCP gestisce tutti i controlli degli errori e altre cose che dovresti implementare per UDP al fine di evitare la perdita di pacchetti.

— UnderscoreZero

Punto valido; Preferirei solo modificare UDP.

— TheNickmaster21

1

Se leggi la recensione del codice sorgente di Quake 3 , spiega il modello di rete che è molto simile al tuo progetto, ma con una soluzione per i pacchetti rilasciati.

In sostanza, nel tuo modello stai inviando delta allo stato direttamente precedente. Nel modello quake3, si inviano delta contro l' ultimo stato acknolwedged dal peer.

— minism
fonte