Architecture de serveur pour un jeu multijoueur?

Question

Je prévois de créer une petite partie multijoueur qui pourrait être exécutée sous la forme d'une applet java ou d'un fichier flash dans le navigateur Web. Je n'ai jamais fait de programmation serveur auparavant, donc je me demande quel type d'architecture de serveur je devrais avoir.

Ce sera facile pour moi de créer des fichiers perl/php sur le serveur, que le code java/flash contacte pour mettre à jour la position/les actions du lecteur, etc. Mais je réfléchis si je devrais avoir un web dédié hôte, quel système d'exploitation utiliser, quelle base de données, etc. En outre, la quantité de bande passante utilisée et l'évolutivité est une considération.

Une autre option pourrait utiliser un système d'hébergement de nuage (par opposition à un serveur dédié), de sorte qu'ils prendraient soin d'ajouter des machines supplémentaires que le jeu se développe. Tant que chaque serveur a exécuté les fichiers perl/php de base pour la mise à jour de la base de données, cela devrait fonctionner correctement.

Encore une autre option pourrait être d'utiliser le moteur de l'application Google. Toute idée concernant l'architecture du serveur, le choix du système d'exploitation/de la base de données, et si ma méthode d'utilisation des scripts perl/php/python pour la programmation côté serveur est bonne, je vous en serai reconnaissant!

Answer 1

Vous devez clarifier davantage le jeu et penser davantage à l'architecture qu'à des détails d'implémentation spécifiques.

La principale question est de savoir si votre jeu va être en temps réel, tour par tour, ou à long délai base (par exemple, échecs par courriel). Une autre question est de savoir si vous allez geler l'état pour des rechargements ultérieurs.

Je vous recommande fortement de déterminer à l'avance si tous les joueurs du même jeu vont être hébergés sur le même serveur (par exemple, 1000 matchs sur 4 joueurs contre 4 matchs de 1000 joueurs chacun). Si possible, aller avec le premier et coller tout le monde qui est dans le même jeu sous le même serveur. Vous aurez du mal à synchroniser plusieurs clients sur un même serveur, plutôt que d'avoir plusieurs serveurs avec lesquels les lecteurs sont synchronisés. Sinon, la définition de la cohérence est problématique.

Si possible, demandez à chaque client de communiquer avec le serveur, puis le serveur distribuant les mises à jour aux clients. De cette façon, vous avez un "état officiel", et vous pouvez faire une variété de résolutions de conflits, fantômes, etc. Le pair-à-pair donne de meilleures performances dans les jeux plus rapides (par exemple, FPS) mais introduit de nombreux problèmes.

Je ne peux pas pour la vie de moi voir une raison convaincante de le faire et perl ou PHP. Votre jeu n'est pas basé sur le web, pourquoi l'écrire dans une langue orientée web? Utilisez le bon vieux J2EE pour le serveur et échangez des données avec vos clients via XML et AJAX. Si possible, exécutez une véritable application Java sur les clients plutôt que sur les servlets. Vous pouvez alors bénéficier de l'utilisation de JMS qui vous enlèvera une grande partie de vos ressources en faisant abstraction de beaucoup de détails de communication pour vous.

Answer 2

Pour l'architecture de votre serveur, vous pouvez jeter un oeil à Three Rings' code. Ils ont écrit un certain nombre de jeux très évolutifs en Java (côté client et serveur).

Answer 3

Je déconseillerais également d'utiliser PHP, aussi HTTP n'est pas la meilleure idée car il est apatride et bavard. Je travaillais depuis quelque temps dans une entreprise développant actuellement un jeu multijoueur vraiment massif. Le back-end est simple JVM (étant connecté via Tomcat par plusieurs clients et de mobiles un par client). Donc, je sais que moins de données vous transférez les plus petits tampons dont vous avez besoin sur le serveur -> plus de clients sur une machine et aussi des réponses un peu plus rapides. Considérons également la sécurité, https est assez cher, surtout si vous avez besoin de transférer des graphiques et des sons.Le protocole Binnary de votre choix avec un conteneur client non-navigateur ferait le mieux (un bon choix est un protocole commutable pour le temps de développement-débogage). Peut-être que cela semble compliqué mais ce n'est pas le cas.

@Sarah bel indice, merci aussi;)