L'host del gioco dovrebbe essere l'autorità o un altro client stupido?

Quando si progetta un gioco multiplayer in rete in cui un giocatore ospita e altri si connettono, ci sono due strategie di cui sono a conoscenza:

• Fai in modo che il gioco del giocatore ospitante sia l'autorità , con tutti gli altri giocatori come clienti stupidi che cercano di raggiungere l'attuale stato del gioco. Nel codice, ci dovranno essere molti casi speciali, a seconda che il giocatore attuale sia l'host o meno.
• Trasforma l'host in un client stupido come tutti gli altri eseguendo un server dedicato nascosto su un altro thread. Il server dedicato sarà l'autorità e l'host si connetterà ad esso come tutti gli altri (tramite localhost).

Quali sono i vantaggi / gli svantaggi di ciascuno di questi? Quale viene utilizzato più spesso (o varia in base al tipo / dimensione del gioco)?

L'approccio muto-cliente è il migliore dal punto di vista del design puro: limita fortemente la quantità di codice diverso necessario tra host e client e consente al server di funzionare in modo asincrono. Il rovescio della medaglia è che la macchina dell'host richiede risorse extra, ma immagino lo abbia sempre fatto.

Tra queste due opzioni l'approccio muto-cliente è sicuramente il migliore per le ragioni menzionate da DeadMG.

C'è un'altra opzione che rende ogni client un'autorità, ha il vantaggio del muto client che tutti i peer condividono lo stesso codice. L'altro vantaggio è che potrebbe essere molto più giusto se si impostano le regole giuste perché nessuno ha il vantaggio di 0-lag-to-server.

Questo può ovviamente essere piuttosto complicato da implementare a seconda del tipo di gioco. Il tuo protocollo dovrà occuparsi della risoluzione dei conflitti tra pari, probabilmente utilizzando un qualche tipo di schema di proprietà. Lasciando solo i conflitti in cui 2 peer rivendicano la proprietà dello stesso oggetto di gioco.

I protocolli multiplayer di Google Peer-2-Peer potrebbero fornirti ulteriori dettagli su questo approccio.