La migliore architettura di gioco peer-to-peer


10

Prendi in considerazione una configurazione in cui i client di gioco:

  1. avere risorse di elaborazione abbastanza piccole (dispositivi mobili, smartphone)
  2. sono tutti collegati a un router comune (LAN, hotspot ecc.)

Gli utenti vogliono giocare a una partita multiplayer, senza un server esterno.

Una soluzione è quella di ospitare un server autorevole su un telefono, che in questo caso sarebbe anche un client. Considerando il punto 1 questa soluzione non è accettabile, dal momento che le risorse informatiche del telefono non sono sufficienti.

Quindi, voglio progettare un'architettura peer-to-peer che distribuirà il carico di simulazione del gioco tra i client. A causa del punto 2 il sistema non deve essere complesso per quanto riguarda l'ottimizzazione; la latenza sarà molto bassa. Ogni cliente può essere una fonte autorevole di dati su se stesso e il suo ambiente immediato (ad esempio i punti elenco).

Quale sarebbe l'approccio migliore per progettare tale architettura? Esistono esempi noti di tale protocollo peer-to-peer a livello di LAN?

Appunti:

Alcuni dei problemi sono affrontati qui , ma i concetti elencati sono troppo alti per me.

Sicurezza

So che non avere un server autorevole è un problema di sicurezza, ma non è rilevante in questo caso poiché sono disposto a fidarmi dei clienti.

Modificare:

Ho dimenticato di menzionare: sarà un gioco piuttosto frenetico (uno sparatutto).

Inoltre, ho già letto delle architetture di rete presso Gaffer on Games .

Risposte:


10

Dai un'occhiata a questo articolo sull'architettura di rete di Age of Empires II.

Sono riusciti a creare un gioco multiplayer che funzionava alla grande su un Pentium 90 con 16 MB di RAM e una connessione modem a 28,8 kB / s. Lo hanno fatto facendo eseguire a ciascun giocatore la propria simulazione, ma sincronizzando i propri comandi.

Ci sono alcuni trucchi intelligenti, lo consiglio vivamente.


5

L'ho fatto per un gioco di corse PSP commerciale, che funzionava sia su una rete ad hoc, sia tramite un hotspot wireless. (O a un server statico su Internet, se lo si desidera)

A causa del punto 2, il sistema non deve essere complesso per quanto riguarda l'ottimizzazione

Nella mia esperienza, questo non è vero. I dispositivi wireless (specialmente quelli portatili di piccole dimensioni) non sono come i computer con connessioni di rete cablate: gli smartphone e le console di gioco wireless tendono ad avere interfacce di rete lente per scopi di gioco.

Non fraintendetemi: il loro throughput è generalmente buono (vale a dire, la quantità di dati al secondo; ottimo per lo streaming di film o ecc.), Ma la latenza alla consegna di un determinato pacchetto può essere estremamente negativa e può essere così altamente variabile che è difficile persino stimare quanto tempo impiegherà ogni singolo pacchetto a consegnare. Questa variazione peggiora ulteriormente quando più dispositivi wireless sono raggruppati in un'area generale, poiché i loro segnali iniziano a interferire tra loro. Di conseguenza, molto del mio tempo è stato impiegato per ridurre il numero di pacchetti che dovevano essere inviati, quindi avremmo meno collisioni di pacchetti. (Si noti che questo è un po 'meno un problema nel caso in cui sia coinvolto un hotspot di rete alimentato, piuttosto che avere i dispositivi che comunicano tra loro direttamente su una rete ad hoc)

Come esempio di questo tipo di ottimizzazione, il nostro gioco di corse si è svolto in un mondo con semafori. Migliaia di loro. E dovevamo assicurarci che i loro segnali fossero sincronizzati tra tutti i giocatori in una sessione di rete. Invece di provare a inviare pacchetti in giro per dire a tutti quali luci si trovavano in quale stato, abbiamo definito un programma statico per tutti i semafori e quindi ci siamo assicurati che tutti i clienti fossero d'accordo sull'attuale "tempo di gioco". Dato che sapevano tutti il ​​tempo di gioco e tutti gli stati dei semafori potevano essere determinati dal tempo di gioco, abbiamo sincronizzato tutti i dati di stato senza effettivamente inviare alcun dato speciale. Questa modifica ha fatto una grande differenza per le nostre prestazioni di rete.

Ciò detto, stabilire una sincronizzazione dell'orologio affidabile tra più dispositivi wireless (con tempi di ping molto variabili a causa in gran parte della perdita di pacchetti) è stata una grande sfida. Felice di parlarne di più se hai un interesse.

Ogni cliente può essere una fonte autorevole di dati su se stesso e il suo ambiente immediato (ad esempio i punti elenco).

Questo è quello che abbiamo fatto e ha funzionato bene per noi nella nostra situazione (macchine). La parte problematica, ovviamente, è quando un oggetto smette di essere più vicino al giocatore 'a' che al giocatore 'b', e quindi la sua proprietà si trasferisce da un giocatore all'altro.

Questa è in realtà una negoziazione sorprendentemente complessa tra i giocatori, in cui il gioco 'a' propone di giocare 'b': "Penso che questo oggetto sia più vicino a te. Dovresti prenderne il controllo." E poi il gioco 'b' può accettare o può declinare in base alla propria visione della situazione. Le differenze nello stato di gioco percepito tra 'a' e 'b', e il cambiamento nel tempo tra quando la richiesta e la risposta sono inviate e ricevute rende questa trattativa particolarmente cattiva per diventare affidabile, e può facilmente degenerare in un gioco di "patata bollente", con la proprietà dell'oggetto che rimbalza continuamente tra più giocatori. E anche quando funziona correttamente, se visto dal punto di vista del gioco 'c', lì '

La mia intuizione è che questo tipo di approccio alla "proprietà dell'oggetto" è probabilmente troppo ingombrante per oggetti piccoli e di breve durata come proiettili. Lo abbiamo usato per le macchine del traffico e per i corridori di intelligenza artificiale, che tendevano a vivere nella simulazione per un tempo relativamente lungo. Sembra un approccio più performante, se sei disposto a fidarti dei clienti, sarebbe quello di far sì che il gioco di ogni giocatore possieda la propria posizione e i propri proiettili e dichiarare quando quel giocatore è stato colpito dal proiettile di qualcun altro. (Così come "gioco A", sono responsabile di dire dove sono i proiettili del giocatore A e del giocatore A, ma il giocatore B è responsabile di dire se ho colpito il giocatore B). Con una buona resa dei conti, dovresti essere in grado di ottenere un comportamento abbastanza ragionevole da un sistema come questo.


1

Si consiglia di utilizzare l'architettura peer step lock to peer.

Si inizia contando i frame di gioco dopo l'inizio del gioco. Un client esegue il rendering del 1 ° frame, quindi invia il messaggio pronto ad altri client e attende di ricevere il messaggio pronto da altri client.

Ora tutti i client possono scegliere il 2 ° frame. Renderizza il frame, invia e ricevi comandi, aggiorna mondo, aggiorna fisica e ... dopo che si sono scambiati messaggi pronti.

Questa soluzione è ottima per i giochi LAN e tutti i tuoi client saranno sincronizzati.

con questo tipo di rete puoi essere sicuro che tutti i tuoi clienti siano sincronizzati in modo da poter testare il modo migliore adatto alle tue esigenze.

Il 1 ° modo è solo inviare gli input ad altri e ogni client simula la corsa, il fuoco, il rilevamento delle collisioni e così via. Il 2 ° modo è ogni client invia le informazioni sul suo personaggio ad altri come posizione, rotazione, stato, frame di animazione ecc. calcola le loro cose e le invia sulla rete, ma il primo modo è più sicuro.


1
Questa risposta sembra riguardare il loop del gioco. Penso che l'OP stia chiedendo del sistema di distribuzione del carico; in particolare, chi simula cosa e come comunicano i clienti. Potresti approfondire qualche dettaglio? Sono interessato anche a questo problema.
Wackidev,

@Wackidev con questo tipo di rete puoi essere sicuro che tutti i tuoi clienti siano sincronizzati in modo da poter testare il modo migliore che si adatta alle tue esigenze. Il 1 ° modo è solo inviare gli input ad altri e ogni client simula la corsa, il fuoco, il rilevamento delle collisioni e così via. Il 2 ° modo è ogni client invia le informazioni sul suo personaggio ad altri come posizione, rotazione, stato, frame di animazione ecc. calcola le loro cose e le invia sulla rete ma il primo modo è più sicuro.
kochol,

Quindi, per favore, inseriscilo nella tua risposta. In questo momento non penso che risponda alla domanda. Inoltre, si prega di eliminare il primo commento duplicato. Grazie. Per quanto riguarda l'idea stessa, la prima opzione che hai elencato non richiede che la simulazione sia deterministica?
Wackidev,
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.