Domanda

Come sono costruiti i giochi RPG online multigiocatore di massa?

  • Su quale infrastruttura server sono costruiti? soprattutto con così tanti client connessi e in comunicazione in tempo reale.

  • Gestiscono con script eseguiti su richieste di pagina? o servizi installati eseguiti in background e che gestiscono la comunicazione con i client connessi?

  • Usano altri protocolli? perché HTTP non consente ai server di inviare dati ai client.

  • Come funzionano i "motori" lavoro, per elaborare centralmente centinaia di eventi di gioco in conflitto?

Grazie per il tuo tempo.

È stato utile?

Soluzione

Su quale infrastruttura server sono costruiti? soprattutto con così tanti client connessi e in comunicazione in tempo reale.

Immagino che i server funzioneranno su Linux, BSD o Solaris quasi il 99% delle volte.

Gestiscono con script eseguiti su richieste di pagina? o servizi installati che funzionano in background e gestiscono la comunicazione con i client connessi?

Il server con cui parla il tuo client sarà un server che esegue un daemon o un servizio che rimane inattivo in attesa di connessioni. Per esempio (dungeon), di solito viene avviato un nuovo processo per ogni gruppo, il che significa che esiste un servizio di dispatcher da qualche parte che lo gestisce (analogo a un pool di thread)

Usano altri protocolli? perché HTTP non consente ai server di inviare dati ai client.

UDP è il protocollo utilizzato. È veloce in quanto non garantisce che il pacchetto verrà ricevuto. Non ti importa se un po 'di latenza fa perdere al cliente la sua posizione mondiale.

Come funzionano i "motori" lavoro, per elaborare centralmente centinaia di eventi di gioco contrastanti?

La maggior parte degli MMO ha zone che limitano questo a un certo numero di persone. Per quelli che hanno centinaia di persone in un'area, di solito c'è un'alta latenza. Il server ha a che fare con centinaia di incantesimi inviati, che deve calcolare gli importi dei danni per ognuno. Per i grandi cinque MMO immagino che ci siano squadre di 10-20 sviluppatori molto intelligenti e dotati di talento matematico che lavorano su questo quotidiano e non c'è un MMO là fuori che abbia capito bene, la maggior parte si rompe dopo 100 giocatori.

-

Dai un'occhiata a Wowemu (non esiste un sito ufficiale e io don non voglio collegarti a un sito pericoloso. Questo si basa su ApireCore che è un simulatore MMO o fondamentalmente un ingegnere inverso del protocollo WoW . Questo è ciò che i server WoW privati ??scappano. Da quello che ricordo Wowemu è

  • mySQL
  • Python

Tuttavia ApireCore è C ++.

Il backend per Wowemu è incredibilmente semplice (l'ho provato nel 2005) e probabilmente una completa semplificazione eccessiva dello schema del database. Ti dà una buona idea di ciò che è coinvolto.

Altri suggerimenti

Molte strade portano a Roma e molte architetture portano a MMORPG.

Ecco alcune considerazioni generali sui tuoi punti elenco:

  • L'infrastruttura del server deve supportare la capacità di ridimensionamento ... aggiungere altri server all'aumentare del carico. A proposito, questo è molto adatto al Cloud Computing. Attualmente sto eseguendo una grande app di servizi finanziari che deve aumentare o diminuire in base all'ora del giorno e al periodo dell'anno. Usiamo Amazon AWS per aggiungere e rimuovere quasi istantaneamente server virtuali.
  • I MMORPG con cui ho familiarità probabilmente non usano i servizi web per la comunicazione (poiché sono apolidi) ma piuttosto un programma sul lato server personalizzato (ad esempio un servizio che ascolta i messaggi TCP e / o UDP).
  • Probabilmente usano un protocollo personalizzato basato su TCP e / o UDP (guarda nella comunicazione socket)
  • La maggior parte dei giochi sono segmentati in "mondi", limitando il numero di giocatori che si trovano nello stesso universo virtuale al numero di eventi di gioco che un server (probabilmente con molta CPU e molta memoria) può ragionevolmente elaborare. L'esatto meccanismo di elaborazione degli eventi dipende dai requisiti del progettista del gioco, ma generalmente mi aspetto che gli eventi in arrivo vadano in una coda prioritaria (prioritaria in base al tempo ricevuto e / o al tempo inviato e probabilmente ad altri criteri sulla falsariga di "quanto è cattivo) se ignoriamo questo evento? ").

Questo è un argomento molto ampio nel complesso. Ti suggerirei di controllare su Amazon.com i libri che trattano questo argomento.

Poiché gli MMO richiedono in generale le risorse di un'azienda per lo sviluppo e l'implementazione, a quel punto sono un valido IP aziendale, non ci sono molte informazioni disponibili pubblicamente sulle implementazioni.

Una cosa abbastanza certa è che dal momento che gli MMO usano in generale un client personalizzato e un renderer 3D non usano HTTP perché non sono browser web. I giochi online avranno i propri protocolli basati su TCP / IP o UDP.

Le stesse simulazioni di gioco saranno costruite usando le stesse tecniche di qualsiasi gioco 3D in rete, quindi puoi cercare le risorse per quel dominio problematico per saperne di più.

Per il grande papà, World of Warcraft, possiamo indovinare che il loro database è Oracle perché gli elenchi di lavoro di Blizzard citano spesso l'esperienza Oracle come un requisito / vantaggio. Usano Lua per gli script dell'interfaccia utente. C ++ e OpenGL (per Mac) e Direct3D (per PC) possono essere assunti come linguaggi di implementazione per i client di gioco perché è con questo che vengono creati i giochi.

Una società che è entusiasta di discutere della propria implementazione è CCP, i creatori di Eve online. Hanno pubblicato una serie di presentazioni e articoli sull'infrastruttura di Eva, ed è un caso particolarmente interessante perché usano Stackless Python per molta implementazione di Eva.

http://www.disinterest.org/resource/PyCon2006-StacklessInEve.wmv http://us.pycon.org/2009/conference/schedule/event / 91 /

C'era anche un recente articolo di Game Developer Magazine sull'architettura di Eva:

https : //store.cmpgame.com/product/3359/Game-Developer-June%7B47%7DJuly-2009-Issue---Digital-Edition

Il podcast della radio Software Engineering ha avuto un episodio con Jim Purbrick su Second Life che discute di server, mondi, ridimensionamento e altri interni di MMORPG.

Tradizionalmente gli MMO si basavano su applicazioni server C ++ in esecuzione su Linux che comunicavano con un database per l'archiviazione back-end e le applicazioni client fat usando OpenGL o DirectX.

In molti casi il client e il server incorporano un motore di scripting che consente di definire i comportamenti in un linguaggio di livello superiore. EVE è notevole in quanto è principalmente implementato in Python e funziona su Stackless anziché essere principalmente C ++ con alcuni script di alto livello.

Generalmente il server si trova in un ciclo di lettura delle richieste dai client connessi, elaborandole per far rispettare le meccaniche di gioco e quindi inviando aggiornamenti ai client. UDP può essere utilizzato per ridurre al minimo la latenza e la ritrasmissione di dati non aggiornati, ma poiché i giochi di ruolo generalmente non impiegano il gameplay di twitch TCP / IP è normalmente una scelta migliore. Comet o BOSH possono essere utilizzati per consentire comunicazioni bidirezionali su HTTP per MMO basati su Web e socket Web saranno presto una buona opzione lì.

Se stavo costruendo un nuovo MMO oggi probabilmente userei XMPP, BOSH e costruivo il client in JavaScript poiché ciò gli avrebbe permesso di funzionare senza un grosso download client e di interagire con messaggistica istantanea e sistemi vocali basati su XMPP (come gchat) . Una volta che WebGL è ampiamente supportato, ciò consentirebbe persino mondi virtuali 3D basati su browser.

Poiché gli ambienti sono troppo grandi per essere simulati in un singolo processo, sono normalmente suddivisi geograficamente tra processi ciascuno dei quali simula una piccola area del mondo. Spesso esiste una popolazione ottimale per un mondo, quindi vengono eseguite più copie (frammenti) che vengono utilizzate da diversi gruppi di persone.

C'è una buona presentazione sull'architettura di Second Life di Ian Wilkes che era il direttore delle operazioni qui: http://www.infoq.com/presentations/Second-Life-Ian-Wilkes

La maggior parte dei miei discorsi sulla tecnologia di Second Life sono collegati dal mio blog all'indirizzo: http://jimpurbrick.com

Dai un'occhiata a Erlang . È un linguaggio di programmazione e un sistema di runtime simultanei ed è stato progettato per supportare applicazioni distribuite, tolleranti ai guasti, soft-real-time, non-stop.

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