Domanda

Sto facendo un gioco multiplayer. Ora sto cercando di scegliere la tecnologia per collegare i dispositivi Android al server. I clienti corrono su Android e il gioco è MMORPG. Vorrei scrivere il server in Java. In questo momento ho solo 3 idee per questo:

1) Creazione di un ambiente multithreading con java e prese semplici. In questo modo sarà più facile eseguire la connessione full-duplex tra il client di gioco e il server. Ma ho le seguenti preoccupazioni:

1.1) Il gioco è MMORPG con un gran numero di oggetti e non sono sicuro di come tali soluzioni sono ridimensionate se ci sono per esempio 5000 persone che giocano allo stesso tempo. Quanti fili potrà correre su Java Machine? Come posso calcolarlo approssimativamente? Nel caso in cui 1 fili è la lettura per ciascuna presa e 1 thread è scrivere sulla presa (quindi 2 thread per 1 lettore).

1.2) Quando cresce il numero di giocatori, come potrò ridimensionare il mio jar-archivio auto-scritto per distribuire su diversi server? Forse c'è qualche trucco speciale per farlo?

1.3) Un sacco di programmazione in testa - gli API dei socket sono piuttosto bassi.

2) Creazione di un'interfaccia servlet per la serving delle richieste HTTP.

2.1) Sessioni facili da controllare (e autorizzazione) Finché ogni giocatore ha la propria sessione.

2.2) Può collegarsi a Java EE EJB o qualsiasi altra cosa - molte complicazioni con la programmazione a livello di sistema sono portati via. Quindi posso concentrarmi sulla scrittura della logica aziendale.

2.3) può servire tutti i tipi di client con http - dispositivi mobili + browser.

2.4) ad alta velocità - anche 1 contenitore del servlet può servire alcune migliaia di richieste al secondo modo, quindi sarà davvero veloce.

2.4) Ma questo approccio non può fornire una comunicazione full-duplex. Dovrò inviare richieste ogni 1 secondo per verificare gli aggiornamenti. 1 secondo ritardo non ha molte differenze per il gioco in quanto è a turno, ma ancora genera un sacco di traffico. È fattibile quando ci sono molti giocatori che giocano? Ho sentito parlare di una tecnologia cometa, ma sembra che il server debba spingere molti messaggi in fila, dovrò comunque inviare richieste ogni volta + questa tecnologia non è ancora ben consolidata.

3) Creazione di prese e collegarli tramite JMS al server Java EE.

3.1) Cool perché consente la comunicazione full duplex tra client e server + fornisce tutte le caratteristiche interessanti di Java EE. Più tardi può essere esteso al browser tramite interfaccia servlet.

3.2) Sembra una specie di eccessivo eccessiva. È davvero il modo in cui la gente lo farebbe? Voglio dire è anche il modo corretto? Qualche sane sviluppatore lo farà così?

Vorrei che tu mi aiutino con la scelta per favore. Non ho molta esperienza con un po 'di lavoro così. E vorrebbe attenersi alle migliori pratiche.

È stato utile?

Soluzione

Perché riscrivere ciò che puoi scendere dallo scaffale?

Perché non usare Reddwarf Server (precedentemente Project Darkstar )?

.

RedDwarf Server è una soluzione middleware open source per lo sviluppo del lato server dei giochi online multiplayer massicci. È la forcella ufficiale della comunità del progetto Darkstar, un progetto open source supportato e gestito da Sun Microsystems. - da Articolo di wikipedia di Reddwarf

Il dominio di reddwarf sembra oggi (2013-06-12), ma c'è ancora un wiki , e lo sono Migrazione verso un github repo .

redward presenta la sua filosofia e obiettivi come:

.
    .
  • Effettua il codice del gioco lato server affidabile, scalabile, persistente e tollerante in modo da tollerante in un modo trasparente allo sviluppatore di giochi.
  • Presenta un semplice modello di programmazione guidato per eventi a filettato singolo allo sviluppatore. Lo sviluppatore non dovrebbe mai avere il suo codice fallire a causa di interazioni tra il codice che gestisce eventi diversi. (da REDDWARF Tutorial )

Non significa che questo non significa che il codice del server sia filettato single, ma che è astratto dal punto di vista dello sviluppatore del gioco. The REDDWARF Tutorial Fornisce molte più informazioni su quale reddwarf Fai e chiarisce molte delle sue decisioni di progettazione.

Un punto di preoccupazione per te, tuttavia, era che la capacità multi-nodo non è stata pienamente implementata l'ultima volta che ho controllato (ca. 2011).

da zero

che non dovrebbe impedirti di tentare di fare la maggior parte di queste cose da zero, se apprezzi l'esperienza di apprendimento. Tuttavia, questo è uno sforzo importante e sarà piuttosto che richiede molto tempo, e, come hai notato nella tua domanda, alcuni di questi problemi sono piuttosto livelli di basso livello nello stack tech da affrontare e aumenteranno notevolmente la complessità del codice dovrai mantenere.

Ma comunque, per quanto riguarda le tue 3 opzioni, il tuo primo sembra il meglio per me, se dovessi andare a un'implementazione fatta in casa. L'opzione 2 (utilizzando i servlet http) sembra adattarsi solo per alcuni giochi, anche se immagino che potrebbe essere un'alternativa relativamente decente per implementare qualcosa da solo mentre si sta ancora delegando verso il middleware, e potresti beneficiare di molte aggiunte del server Web per gestire il carico ( Moduli della cache, ecc ...). L'opzione 3 (usando JMS + Jee) sembra effettivamente eccessivamente eccessivamente, ma è difficile saperlo per certo senza sapere cosa hai in mente.

E se sei qui per cercare di imparare, quindi ovviamente l'opzione 1 coprirà un sacco di terreno. Ma sarà una battaglia piuttosto in salita.

Altri suggerimenti

1.1) you can't think in term of one Thread by user. Depending of machine configuration but you could load thousands of threads but it will not scale and lose a lot of time in Thread context switch. Better think NIO Netty like framework with few incoming and outcoming Thread pool executor that perform incoming messages under milli second execution.

1.2) You can simply scale by putting in front of you game server a loadbalancer component that can forward incoming player to right server according their load

1.3) NIO can handle thousands to to millions connection on a single box. Don't worry with this.

2.1) Manage your player sessions and 2.2) be away of EJB architecture. It will eat all your box power instead of allocating power to your game which is your goal.

2.3) HTTP can serve all clients but if you run realtime game i encourage to use binary socket and keep HTTP only for loadbalancing , login , stats and fallback when can't establish a socket connection.

2.4) Socket based server can handle hundred thousands incoming message per second. This is the property of low latency system

While it's very interesting to dive in building such system. What is your goal? Learn to build such system or succeed your game?

Many java multiplayer game server technology framework already exist. SmartFox Server, ElectroTank...

We have our own java high load Nuggeta multiplayer crossplatform java game server that addresses all points discussed above and much more. If you wanna try it it's free.

If your goal is to write a game server it's awesome venture that can takes long time but very exciting. If your goal is to succeed your game. Pick up among Java game server SDK already existing.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
scroll top