Question

Comment sont construits les jeux de RPG en ligne massivement multijoueurs?

  • Sur quelle infrastructure de serveur reposent-ils? surtout avec autant de clients connectés et communiquant en temps réel.

  • Est-ce qu'ils gèrent avec des scripts qui s'exécutent sur des requêtes de page? ou des services installés fonctionnant en arrière-plan et gérant la communication avec les clients connectés?

  • Utilisent-ils d'autres protocoles? car HTTP n'autorise pas les serveurs à transmettre des données aux clients.

  • Comment fonctionnent les "moteurs"? travailler, pour traiter de manière centralisée des centaines d’événements de jeu en conflit?

Merci de votre temps.

Était-ce utile?

La solution

Sur quelle infrastructure de serveur reposent-ils? surtout avec autant de clients connectés et communiquant en temps réel.

Je suppose que les serveurs fonctionneront sous Linux, BSD ou Solaris près de 99% du temps.

Est-ce qu'ils gèrent avec des scripts qui exécutent des requêtes de page? ou des services installés fonctionnant en arrière-plan et gérant la communication avec les clients connectés?

Le serveur avec lequel votre client parle sera un serveur exécutant un démon ou un service inactif en attente de connexion. Pour les instances (donjons), un nouveau processus est généralement lancé pour chaque groupe, ce qui signifierait qu’il existe un service de dispatching gérant quelque chose (analogue à un pool de threads)

Est-ce qu'ils utilisent d'autres protocoles? car HTTP n'autorise pas les serveurs à transmettre des données aux clients.

UDP est le protocole utilisé. C'est rapide car rien ne garantit que le paquet sera reçu. Peu importe si un peu de latence fait perdre au client sa position dans le monde.

Comment fonctionnent les "moteurs"? travailler, pour traiter de manière centralisée des centaines d’événements de jeu en conflit?

La plupart des MMO ont des zones qui limitent cela à un certain nombre de personnes. Pour ceux qui ont des centaines de personnes dans une zone, la latence est généralement élevée. Le serveur doit faire face à des centaines de sortilèges et calculer le montant des dégâts pour chacun d'eux. Pour les cinq grands MMO, j’imagine qu’il ya des équipes de 10 à 20 développeurs très intelligents et mathématiquement doués qui travaillent sur ce quotidien et qu’aucun MMO n’a réussi à le faire, la plupart des groupes dépassent les 100 joueurs.

-

Consultez Wowemu (il n'y a pas de site officiel et je ne ne voulez pas créer un lien vers un site louche). Ceci est basé sur ApireCore , qui est un simulateur MMO ou, en gros, un reverse engineering du protocole WoW. . C’est ce que les serveurs privés de WoW utilisent. De ce que je me souviens de Wowemu est

  • mySQL
  • Python

Cependant, ApireCore est en C ++.

Le backend de Wowemu est incroyablement simple (je l’ai essayé cependant en 2005) et probablement une simplification excessive du schéma de base de données. Cela vous donne une bonne idée de ce qui est impliqué.

Autres conseils

De nombreuses routes mènent à Rome et de nombreuses architectures conduisent aux MMORPG.

Voici quelques réflexions générales sur vos points centraux:

  • L'infrastructure de serveur doit prendre en charge la possibilité d'évoluer ... ajoutez des serveurs supplémentaires à mesure que la charge augmente. Soit dit en passant, cela convient bien au Cloud Computing. J'utilise actuellement une grande application de services financiers qui doit être modifiée en fonction de l'heure et de la période de l'année. Nous utilisons Amazon AWS pour ajouter et supprimer presque instantanément des serveurs virtuels.
  • Les MMORPG que je connais bien n'utilisent probablement pas les services Web pour la communication (car ils sont sans état), mais plutôt un programme personnalisé côté serveur (par exemple, un service qui écoute les messages TCP et / ou UDP).
  • Ils utilisent probablement un protocole personnalisé basé sur TCP et / ou UDP (regardez dans la communication socket)
  • La plupart des jeux sont segmentés en "mondes", ce qui limite le nombre de joueurs qui se trouvent dans le même univers virtuel au nombre d'événements de jeux qu'un serveur (probablement avec beaucoup de ressources processeur et de mémoire) peut traiter de manière raisonnable. Le mécanisme exact de traitement des événements dépend des exigences du concepteur de jeu, mais en général, je suppose que les événements entrants entrent dans une file d'attente prioritaire (hiérarchisée en fonction du temps reçu et / ou du temps envoyé, et probablement d'autres critères du type "comment est-il mauvais si nous ignorons cet événement? ").

C’est un sujet très vaste dans l’ensemble. Je vous suggérerais de vérifier sur Amazon.com les livres traitant de ce sujet.

Etant donné que les MMO nécessitent généralement les ressources d’une entreprise pour se développer et se déployer, et qu’ils constituent dès lors une IP précieuse, ils ne disposent pas d’une tonne d’informations accessibles au public sur les implémentations.

Une chose à peu près certaine, c’est que puisque les MMO utilisent généralement un client personnalisé et un rendu 3D, ils n’utilisent pas HTTP car ils ne sont pas des navigateurs Web. Les jeux en ligne vont avoir leurs propres protocoles construits sur TCP / IP ou UDP.

Les simulations de jeu elles-mêmes seront construites en utilisant les mêmes techniques que n'importe quel jeu 3D en réseau. Vous pourrez ainsi consulter les ressources de ce domaine problématique pour en savoir plus.

Pour le grand papa World of Warcraft, on peut supposer que leur base de données est Oracle, car les offres d’emploi de Blizzard citent fréquemment l’expérience Oracle comme une exigence / plus. Ils utilisent Lua pour les scripts d'interface utilisateur. C ++ et OpenGL (pour Mac) et Direct3D (pour PC) peuvent être considérés comme les langages d’implémentation pour les clients de jeux, car c’est avec eux que sont conçus les jeux.

CCP, les créateurs d’Eve en ligne, est une société qui a du mal à discuter de leur mise en œuvre. Ils ont publié un certain nombre de présentations et d'articles sur l'infrastructure d'Eve. Il s'agit d'un cas particulièrement intéressant car ils utilisent Stackless Python pour une grande partie de la mise en œuvre d'Eve.

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

Il y a eu également un article récent de Game Developer Magazine sur l'architecture d'Eve:

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

Le podcast radio Software Engineering avait un Épisode avec Jim Purbrick sur Second Life , qui traite des serveurs, des mondes, de la mise à l'échelle et d'autres éléments internes du MMORPG.

Traditionnellement, les MMO reposaient sur des applications serveur C ++ s'exécutant sous Linux communiquant avec une base de données pour les applications de stockage back-end et client lourd utilisant OpenGL ou DirectX.

Dans de nombreux cas, le client et le serveur intègrent un moteur de script qui permet de définir les comportements dans un langage de niveau supérieur. EVE est remarquable en ce sens qu’il est principalement implémenté en Python et s’exécute sur Stackless au lieu d’être principalement en C ++ avec des scripts de haut niveau.

Généralement, le serveur est assis dans une boucle et lit les demandes des clients connectés, les traite pour appliquer les mécanismes du jeu, puis envoie des mises à jour aux clients. UDP peut être utilisé pour réduire au minimum le temps de latence et la retransmission de données obsolètes, mais comme les RPG n’utilisent généralement pas de jeu à deux, le TCP / IP est normalement un meilleur choix. Comet ou BOSH peuvent être utilisés pour permettre des communications bidirectionnelles sur HTTP pour les MMO Web et les sockets Web seront bientôt une bonne option.

Si je construisais un nouveau MMO aujourd'hui, j'utiliserais probablement XMPP, BOSH et créerais le client en JavaScript, car cela lui permettrait de fonctionner sans téléchargement client lourd et d'interopérer avec les systèmes de messagerie instantanée et vocaux basés sur XMPP (comme gchat). . Une fois que WebGL sera largement pris en charge, cela permettrait même aux mondes virtuels 3D basés sur un navigateur.

Les environnements étant trop volumineux pour être simulés dans un processus unique, ils sont normalement répartis géographiquement entre des processus simulant chacun une petite partie du monde. Il existe souvent une population optimale pour un monde. Par conséquent, plusieurs copies (fragments) sont utilisées par différents groupes de personnes.

Ian Wilkes, qui était directeur des opérations ici, présente un bon exposé sur l'architecture Second Life: http://www.infoq.com/presentations/Second-Life-Ian-Wilkes

La plupart de mes discussions sur la technologie Second Life sont liées à mon blog à l'adresse suivante: http://jimpurbrick.com

Consultez Erlang . Il s’agit d’un langage de programmation et d’un système d’exécution simultanés. Il a été conçu pour prendre en charge des applications distribuées, tolérantes aux pannes, en temps réel et non-stop.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top