Architettura server per un gioco multiplayer?

Question

Sto pianificando la creazione di un piccolo gioco multiplayer che può essere eseguito come applet java o flash nel browser web. Non ho mai fatto alcuna programmazione server, quindi mi chiedo quale tipo di architettura server dovrei avere.

Sarà facile per me creare file perl/php sul server, che il codice java/flash contatta per aggiornare la posizione/le azioni del giocatore, ecc. Ma sto considerando se dovrei ottenere un web dedicato host, quale sistema operativo utilizzare, quale database, ecc. Inoltre, la quantità di larghezza di banda utilizzata e la scalabilità sono una considerazione.

Un'altra opzione potrebbe essere l'utilizzo di un sistema di cloud hosting (al contrario di un server dedicato), quindi si prenderanno cura di aggiungere ulteriori macchine man mano che il gioco cresce. Finché ogni server ha eseguito i file core perl/php per l'aggiornamento del database, dovrebbe funzionare correttamente.

Un'altra opzione potrebbe essere l'utilizzo del motore di app di Google.

Qualsiasi idea riguardante l'architettura del server, la scelta del database/del sistema operativo e se il mio metodo di utilizzo degli script perl/php/python per la programmazione lato server è buono, sarà apprezzato!

Answer 1

È necessario chiarire di più sul gioco e pensare più all'architettura piuttosto che a specifici dettagli di implementazione.

La domanda principale è se il gioco sarà in tempo reale, basato su turni o basato su tempi lunghi (ad esempio, scacchi via e-mail). Un'altra domanda è se non si sta andando a congelare lo stato per ricariche successive.

Consiglio vivamente di capire in anticipo se tutti i giocatori nello stesso gioco saranno ospitati sullo stesso server (ad es., 1000 di partite a 4 giocatori rispetto a 4 partite di 1000 giocatori ciascuna). Se possibile, vai col primo e metti tutti coloro che sono nella stessa partita sotto lo stesso server. Avrai abbastanza tempo per sincronizzare più client su un server, piuttosto che avere più server rispetto ai quali i giocatori sono sincronizzati. Altrimenti, la definizione di coerenza è problematica.

Se possibile, chiedere a ciascun client di comunicare con il server e quindi il server che distribuisce gli aggiornamenti ai client. In questo modo hai uno "stato ufficiale" e puoi fare una serie di risoluzioni di conflitto, fantasmi, ecc. Il peer to peer offre migliori prestazioni nei giochi più veloci (ad es. FPS) ma introduce un sacco di problemi.

Non posso per la vita di me vedere alcun motivo convincente per fare questo e PHP o PHP. Il tuo gioco non è basato sul Web, perché scrivere in un linguaggio orientato al web? Usa il buon vecchio J2EE per il server e scambia dati con i tuoi clienti tramite XML e AJAX. Se possibile, esegui un'applicazione Java reale sui client anziché sui servlet. È quindi possibile trarre vantaggio dall'utilizzo di JMS, che si prenderà un carico enorme dalle spalle estraendo molti dei dettagli di comunicazione per voi.

Answer 2

Per l'architettura del server, è possibile dare un'occhiata a Three Rings' code. Hanno scritto una serie di giochi molto scalabili in Java (sia lato client che server).

Answer 3

Vorrei anche scoraggiare dall'uso di PHP, anche HTTP non è la migliore idea in quanto è apolidi e loquace. Stavo lavorando da un po 'di tempo in una compagnia che attualmente sta sviluppando un gioco multiplayer davvero enorme. Il back-end è semplice JVM (essendo connesso tramite tomcat da più client e da dispositivi mobili uno per client). Quindi conosco meno dati trasferisci i buffer più piccoli di cui hai bisogno sul server -> più client su una macchina e anche risposte un po 'più veloci. Considerate anche la sicurezza, https è piuttosto costoso, specialmente se avete bisogno di trasferire grafica e suoni.Il protocollo Binnary con il contenitore del client non-browser farebbe il meglio (la buona scelta è il protocollo commutabile per il tempo di debug dello sviluppo). Forse sembra complicato ma non lo è.

@Sarah bel suggerimento, anche grazie;)