Come posso creare un gioco multiplayer p2p? Vorrei un gioco multiplayer senza server. Ma allora, come si conoscono tutti i clienti?
Perché il protocollo p2p è così famoso nel trasferimento di file ma non nei giochi multiplayer?
Come posso creare un gioco multiplayer p2p? Vorrei un gioco multiplayer senza server. Ma allora, come si conoscono tutti i clienti?
Perché il protocollo p2p è così famoso nel trasferimento di file ma non nei giochi multiplayer?
Risposte:
I giochi peer to peer generalmente hanno ancora un host di giochi. È l'host di gioco che pubblica il gioco nell'elenco dei giochi principali e accetta nuove connessioni. Ogni volta che l'host del gioco accetta un nuovo client nel gioco, avvisa tutti i client esistenti del nuovo client in modo che possano assicurarsi di connettersi al nuovo client.
Il modo più semplice per implementare p2p è con una lobby. Tutti i client si connettono all'host in una lobby (o chat room). Quando l'host è pronto, il giocatore preme start e tutti entrano nel gioco contemporaneamente (comunemente usato nei giochi di strategia). Un approccio più complesso consiste nell'utilizzare il "drop-in drop-out" in cui i giocatori possono unirsi e abbandonare la metà del gioco, tuttavia questo è molto più complesso da implementare in un gioco p2p e richiede una funzionalità chiamata migrazione dell'host.
Un buon numero di giochi utilizza reti peer to peer, inclusa la maggior parte dei titoli di strategia, sport e guida. Quasi tutti i giochi Xbox360 e PS3 utilizzano la rete p2p. L'architettura client-server viene utilizzata principalmente negli sparatutto in prima persona o nei giochi MMO.
Il client-server è generalmente più facile da implementare poiché solo 1 macchina non conosce l'intero stato del gioco, i client sono fondamentalmente solo renderizzatori con alcune previsioni per rendere le cose più fluide.
Quando costruisci un motore p2p, tutti i client hanno bisogno di uno stato completo del mondo di gioco e sono tutti tenuti a rimanere sincronizzati.
Per maggiori dettagli su p2p e architetture client-server, ti suggerisco di leggere il seguente articolo: Che cosa deve sapere ogni programmatore sulla rete di giochi .
E se non conosci la rete in generale, controlla gli altri fantastici articoli su quel sito. Glenn è un genio del networking.
Ci sono molte ragioni per cui p2p non è popolare nei giochi, principalmente a causa del ritardo. Ognuno è lento come il giocatore più lento. Non stiamo parlando della larghezza di banda qui, ma del tempo di ping.
p2p può trasferire tonnellate di dati, ma lo fa con un ping abbastanza alto, i giochi devono trasmettere quantità molto piccole di dati, con un tempo di ping minimo.
Ci sono alcuni aspetti interessanti sui sistemi peer-to-peer e sui giochi d'azione. Ho provato a postarli come commento sul blog di Glenn Fiedler, ma a quanto pare non gli piace essere smentito e ho invece tirato fuori l'intero articolo. È su Internet Archive, nel caso tu voglia leggerlo.
Non ha lasciato andare il commento online, quindi lo citerò qui:
Il suggerimento peer-to-peer del primo post è in realtà un interessante punto di partenza, anche se a volte è un po 'ingenuo: la prima possibilità sarebbe quella di combinare il sistema con un modello client / server standard con la previsione come indicato nel tuo post sulla rete di gioco. Il ping P2P inferiore ridurrebbe drasticamente il ritardo di previsione tra i giocatori a seconda della loro posizione: l'effetto probabilmente non sarebbe visibile per la maggior parte dei giocatori statunitensi, ma qui in Europa i ping di 200+ sono normali sulla maggior parte dei server e una connessione diretta ridurrebbe il ritardo di previsione a quello di un server europeo.
Un vero approccio P2P senza server è un po 'più complesso: una delle preoccupazioni principali delle reti decentralizzate è garantire la coerenza, soprattutto se la simulazione potrebbe soffrire di effetti farfalla a causa di tempi leggermente diversi dei comandi inviati sulla rete o problemi in virgola mobile. Ciò è possibile collegando in rete lo stato di ciascun oggetto (giocatori, NPC, ...) almeno periodicamente. Non sarebbe nemmeno necessario farlo per tutti gli oggetti contemporaneamente, e ogni client potrebbe prendere possesso di determinati oggetti. Il collegamento in rete di oggetti sufficienti in un determinato momento dovrebbe smorzare la differenza che si accumula tra ogni sincronizzazione di un oggetto abbastanza da diventare irrilevante anche per intervalli di sincronizzazione di un secondo o più.
Il secondo problema con i sistemi P2P è la sicurezza, ma in questo caso può essere risolto con una correzione relativamente piccola: i client possono utilizzare le loro simulazioni fisiche per raccogliere informazioni sul livello di errore su ciascun oggetto fisico. La fisica manipolata provoca sempre un errore più grande, quindi i client semplicemente "votano" per disconnettersi dal peer che controlla un oggetto sospetto. Inoltre, i messaggi di controllo per oggetti non fisici vengono inoltrati tra i client in base alla loro importanza: gli aggiornamenti dei giocatori possono essere inoltrati in modo casuale, gli aggiornamenti importanti e poco frequenti devono sempre essere inviati, ma sempre a un giocatore casuale. In questo modo un giocatore dovrebbe controllare una larga parte dei client connessi per poter imbrogliare in modo evidente.
[...]
Puoi trovare la discussione a cui sto facendo riferimento su http://www.devmaster.net/forums/showthread.php?t=14640 .
Penso che qualcuno abbia menzionato i problemi del firewall peer-to-peer in uno dei thread dell'articolo. Una possibile soluzione sarebbe un NAT-Punchthrough:
- Panoramica NAT Punchthrough
- Comunicazione peer-to-peer attraverso i traduttori di indirizzi di rete
Non esiste un tasso di successo del 100%, quindi dovresti dire ai giocatori di aprire una porta comunque.
Un buon esempio di gameplay "peer-to-peer" sarebbe un gioco di strategia in tempo reale come Starcraft.
In un gioco con centinaia di unità / proiettili in movimento, non è pratico inviare ripetutamente posizioni / stati delle unità sulla rete a tutti gli altri giocatori, quindi una soluzione qui è per tutti i giocatori di eseguire la (esatta stessa) simulazione in sincronia.
Quando un giocatore esegue un'azione, il comando / ordine ('sposta zergling su X, Y') può essere inviato a tutti gli altri giocatori, per essere eseguito da tutte le istanze della simulazione una frazione di secondo dopo.
In questa situazione, se un giocatore si disconnette, il gioco può continuare - poiché non è necessario che un server / host esegua il gioco, i giocatori rimanenti possono continuare.
Tuttavia, mantenere i giochi sincronizzati non è banale, devi usare un timestep fisso per gli aggiornamenti della logica di gioco e devi stare molto attento con l'uso e il seeding di generatori di numeri casuali, per assicurarti che le simulazioni non divergano!
Sarebbe un po 'disonesto affermare che non è famoso per i giochi quando la usano la maggior parte dei giochi di strategia in tempo reale (serie Star Craft, serie Command e Conquer) e molti giochi FPS (Call of Duty: Modern Warfare 2).
Detto questo, il modo in cui si impara a conoscere il gioco dipende dal servizio di matchmaking / lobbying che si utilizza o si crea. Ma anche dopo aver appreso del gioco, potrebbero esserci ancora uno o più colleghi che sono più uguali degli altri. Si consideri il caso di 3 clienti che desiderano giocare, uno dietro un nat aperto, 2 dietro un nat rigoroso (chiuso). Il peer nat aperto può prendere connessioni dagli altri due. Ma i 2 rigorosi non possono connettersi direttamente tra loro, richiederanno la nat aperta per inoltrare i pacchetti. Se il peer nat aperto cade dal gioco, allora sarebbe necessario trovare un altro relè o il gioco verrà interrotto.
Probabilmente vuoi correre con un solo giocatore (lo chiameremo "Host") come server non autorevole. Avrai tutti gli altri giocatori a comunicare ciò che stanno facendo alla loro fine con il nostro host, e l'host trasmetterà i messaggi agli altri giocatori.
Probabilmente vuoi anche passare un elenco di quali computer sono collegati al player di hosting in modo che se cadono un nuovo host può essere scelto in qualche modo e iniziare a comunicare con i giocatori rimanenti.
La documentazione per smartfoxserver può aiutarti e / o potresti voler utilizzare anche per il tuo gioco. Lo avresti semplicemente incorporato nel tuo gioco client invece di avere un programma client e server separato.
Sono un po 'interessato a questo argomento. Stai dicendo che ci sono molti problemi con la creazione di un gioco p2p invece di un classico modello client-server. Ma sono abbastanza sicuro che p2p sia come client-server ma ogni peer ha la possibilità di diventare un server. A proposito del GAL se si aggiunge un'altra macchina come server, ci sono più probabilità che molti client siano più lontani dal server, ma usando p2p non ci sono macchine extra nella lobby, è possibile gestire i test di latenza e creare gruppi con un ping minimo. Per quanto riguarda la generazione di traffico, come ho appreso, devi chiedere ai clienti di trasmettere meno che meno, intendo che i clienti devono capire che tutti gli altri clienti sono disposti a voler dire.
Se stai realizzando un mmorpg dall'aspetto relativamente semplice con requisiti di sistema bassi, ti suggerirei di creare un programma interno che crei una "frequenza" basata sul contenuto della cartella del gioco e in cosa consistano i file. Questo farà suonare le persone con la stessa "frequenza" sugli stessi canali. I client modificati, manipolati o normali verranno separati. Funzionerà solo con hack o mod nativi, ma sono sicuro che questo copre tutti gli imbroglioni "stupidi". In combinazione con il metodo di controllo degli errori che una persona menzionata significa poca o nessuna moderazione richiesta. Per quanto riguarda le porte, basta che copra la porta 52225 con un processo in background che la mantenga collegata ai router senza porte trigger.