Quelle est la meilleure architecture pour plusieurs serveurs de jeux ayant besoin de se parler?

Question

Le jeu est un jeu stratégique à faible graphique (SVG). Chaque serveur représente un domaine de jeu avec ses joueurs. Tous les serveurs doivent pouvoir se parler, car les joueurs peuvent se déplacer (dans le jeu) d'un domaine à l'autre / envoyer des "messagers diplomatiques". etc ..

Nous avons choisi cette idée car elle nous permet d’agrandir indéfiniment la carte du monde, elle permet aux tiers de nous connecter leurs serveurs de jeux et d’élargir encore plus le monde. Si un serveur (et ses sauvegardes) échoue, le jeu continuera de fonctionner (un véritable environnement distribué).

Nous ne sommes qu'au début. Quelles sont les plateformes sur lesquelles nous devrions nous pencher pour nous aider à développer un tel monde?

Answer 1

XMPP, anciennement Jabber, pourrait être un bon point de départ.

Answer 2

Cela dépend en grande partie de la quantité de données que vous souhaitez partager entre les serveurs. Vous voulez que chaque serveur gère son propre domaine, mais qu'en est-il de la base de données de comptes, des données sur qui détient quelles informations, la topographie des domaines, ces données vont-elles être centrales et / ou distribuées et comment les maintenir synchronisées? Donc, en dehors du fonctionnement du jeu, il existe un autre ensemble de métadonnées sur lequel les serveurs doivent communiquer. En ce qui concerne les données du jeu, vous allez probablement transmettre des événements, des objets de données et des informations sur la propriété et le contrôle des données. En plus de cela, il doit y avoir quelques métadonnées d'horloge dans le jeu pour que les domaines soient synchronisés.

J'utiliserais probablement un système de files d'attente asynchrones avec des priorités différentes pour les métadonnées, les requêtes et les messages de réponse. Un protocole comme XMPP en plus de l'échange de messages peut vous apporter des informations de présence, une authentification, un cryptage et d'autres avantages. Mais au début, le protocole de livraison n’est pas aussi important que la structure des messages et l’échange des données. Les protocoles de livraison sont essentiellement interchangeables.

Exemple : Un joueur envoie une unité de jeu X du domaine A au domaine B. Domaine Un serveur envoie un message avec événement au serveur du domaine B. Pendant le traitement de la file d’événements, B reçoit un message et envoie une requête à une file de requêtes sur A pour obtenir des données sur l’unité X et l’autorisation de contrôler / modifier les données de l’unité X. La file d’attente a une priorité plus élevée et sera traitée avant les autres événements du domaine A Le domaine A envoie les données demandées et le jeton de contrôle à la file de réponses du domaine B avec la priorité la plus élevée. Pendant ce temps, le serveur du domaine B a déjà traité 3 autres événements, sans attendre en session.

• Remarque: A devrait être obsolète, mettre à jour ou supprimer les données relatives à l'unité X à ce stade. Si une demande vient pour des données du domaine C, elle devra désormais la transmettre au serveur B.
• Remarque: L'exemple ci-dessus peut être optimisé pour envoyer des données sur l'unité X directement avec l'événement correspondant, mais je souhaitais illustrer un exemple simple.

L'important est que vous deviez concevoir le protocole d'encapsulation des données, probablement un schéma XML. Le protocole de gestion des événements. Liste des événements, réponses autorisées, messages d'erreur, récupération. Ce sont tous des jeux spécifiques.

Answer 3

Je réfléchirais sérieusement à Erlang et CouchDB, ou à son implémentation sous Google AppEngine.

Answer 4

Si c'est vraiment distribué, je suppose qu'il n'y a pas de projet de serveur central. Cela signifie que vous recherchez réellement un mécanisme de communication entre les différents serveurs. REST et XML-RPC sont deux mécanismes très simples permettant aux serveurs de se parler et de communiquer le fait qu'un utilisateur doit passer d'un serveur à un autre.

Vous pouvez également utiliser quelque chose comme XMPP, comme l'a dit Daniel, mais cela signifie que vous devez ajouter un ensemble de logiciels serveur dans le mix, en plus de tout ce que vous avez en train d'exécuter le jeu lui-même (ce que je suppose d'après votre description probablement un serveur d’applications Web).

Du point de vue du développement, tout langage / framework fort pour le développement d'applications Web devrait fonctionner. Ruby on Rails, Python sur Django, de nombreux frameworks plus Java, ou même Cake avec PHP (ick) fonctionneraient pour le travail de développement.

J'ai déjà envisagé quelque chose de ce genre dans le passé, mais uniquement en ce qui concerne la vérification des serveurs (c.-à-d. comment gérer un serveur brisé ou malveillant et laisser un joueur déplacer simultanément le même élément sur deux ou trois autres serveurs ), gérer les serveurs abandonnés (ce qui arrive aux derniers joueurs qui y existaient), etc. semblait très difficile.

Answer 5

Je pense que la première question à laquelle il faut répondre est de savoir si le jeu est en temps réel ou en fonction d'événements, et si le client est le navigateur ou non. Cela ressemble à une stratégie événementielle, mais rappelez-vous que le serveur ne peut pas transférer efficacement les résultats vers un client HTML ordinaire, mais uniquement vers un applet Java, une animation Flash intégrée, etc. Si vous avez un client personnalisé, vous n'avez pas besoin d'utiliser HTTP. -système de style sur le serveur, ce qui signifie que les communications entre serveurs peuvent être effectuées de la même manière.

Answer 6

Vous devriez jeter un oeil à "Gestion des intérêts". documents sur les jeux p2p, vous ferez face à des approches vraiment intéressantes. Google Schoolar vous présentera de très bons papiers.

Mais soyez averti, le développement d'applications distribuées est beaucoup plus complexe que de simples approches à serveur unique.