Question

Je fais un jeu multijoueur. Maintenant, j'essaie de choisir la technologie pour connecter les périphériques Android au serveur. Les clients fonctionnent sur Android et le jeu est MMORPG. Je voudrais écrire le serveur en Java. À l'heure actuelle, je n'ai que 3 idées pour cela:

1) Création d'un environnement multithreading avec java et sockets simples. De cette manière, il sera plus facile d'effectuer une connexion complète duplex entre le client de jeu et le serveur. Mais j'ai les préoccupations suivantes:

1.1) Le jeu est MMORPG avec un grand nombre d'objets, et je ne sais pas comment de telles solutions sont échouées en cas d'exemple 5000 personnes jouant en même temps. Combien de threads vais-je pouvoir courir sur la machine Java? Comment puis-je calculer approximativement cela? Dans le cas de la lecture, le thread est la lecture pour chaque prise et 1 thread écrit sur la prise (donc 2 filets pour 1 joueur).

1.2) Lorsque le nombre de joueurs augmente, comment puis-je accomplir mon jar-archive auto-écrit pour distribuer sur plusieurs serveurs? Peut-être y a-t-il une astuce spéciale pour faire ça?

1.3) Beaucoup de programmes de programmation - Sockets API est un niveau assez bas.

2) Création d'une interface de servlet pour servir des demandes HTTP.

2.1) Sessions (et autorisation) faciles à contrôler tant que chaque joueur a sa propre session.

2.2) Peut se connecter à Java EE EJB ou autre chose - Beaucoup de complications avec la programmation au niveau du système sont supprimées. Donc, je peux me concentrer sur la logique commerciale d'écriture.

2.3) Peut servir tous les types de clients avec http - appareils mobiles + navigateurs.

2.4) Haute vitesse - Même 1 conteneur de servlet peut servir quelques milliers de demandes par seconde, ce qui sera vraiment rapide.

2.4) Mais cette approche ne peut pas fournir une communication complète duplex. Je devrai envoyer des demandes toutes les 1 seconde pour vérifier les mises à jour. 1 Deuxième retard ne fait pas beaucoup de différence pour le jeu tel qu'il est basé sur le tour, mais il génère toujours beaucoup de trafic. Est-ce réalisable quand il y a beaucoup de joueurs jouant? J'ai entendu parler de la technologie de la comète, mais cela semble être si le serveur doit pousser de nombreux messages dans la ligne, je devrai encore envoyer des demandes à chaque fois + cette technologie n'est pas encore bien établie.

3) créer des sockets et les connecter à JMS au serveur Java EE.

3.1) COOL car permet une communication recto verso complète entre les clients et le serveur + fournit toutes les fonctionnalités froides de Java EE. Plus tard peut être étendu au navigateur via une interface de servlet.

3.2) Cela semble être une sorte de surmenage. Est-ce vraiment comment les gens feraient cela? Je veux dire, c'est même la bonne façon? Est-ce que tout développeur sain d'esprit le fait comme ça?

J'aimerais que vous m'aidez avec le choix s'il vous plaît. Je n'ai pas beaucoup d'expérience pour faire du travail comme ça. Et voudrait coller aux meilleures pratiques.

Était-ce utile?

La solution

Pourquoi vous réécrire ce que vous pouvez sortir de l'étagère?

Pourquoi ne pas utiliser serveur Reddwarf (anciennement projet DarkStar )?

Reddwarf Server est une solution de middleware open source pour développer le côté serveur des jeux en ligne massivement multijoueurs. C'est la fourchette de la communauté officielle du projet Darkstar, un projet open source soutenu et géré par Sun Microsystems. - de Article Wikipedia de Reddwarf

Le domaine de Reddwarf semble en baisse aujourd'hui (2013-06-12), mais il y a encore un wiki , et ils sont Migration vers un Github Repo .

Reddward présente sa philosophie et ses objectifs comme:

  • Faites du code de jeu côté serveur fiable, évolutif, persistant et tolérant à une faute de manière transparente pour le développeur de jeu.
  • Présentez un modèle de programmation simple à un événement unique à un événement unique au développeur. Le développeur ne devrait jamais avoir son code ou son code en raison d'interactions entre les manipulations de code différents événements. (du Didacticiel Reddwarf )

Non pas que cela ne signifie pas que le code serveur est un seul fileté, mais qu'il est résumé du point de vue du développeur de jeu. Didacticiel Reddwarf offre beaucoup plus d'informations sur ce que REDDWARF peut Faire et clarifie de nombreuses décisions de conception.

Un point de préoccupation pour vous, cependant, était que la capacité multi-nœuds n'était pas complètement mise en œuvre de la dernière fois que je vérifie la dernière fois que je vérifie (Ca. 2011).

de zéro

Cela ne devrait pas vous empêcher de tenter de faire la plupart de ces choses à partir de zéro, si vous valorisez l'expérience d'apprentissage. Cependant, il s'agit d'un effort majeur et sera plutôt fusion, et comme vous l'avez noté dans votre question, certaines de ces questions sont plutôt de faible niveau dans la pile technique pour traiter et augmenteront considérablement la complexité du code que vous "ll doit maintenir.

Mais de toute façon, en ce qui concerne vos 3 options, votre premier me semble le mieux pour moi, si vous deviez passer une mise en œuvre faite maison. L'option 2 (en utilisant les servlets HTTP) semble uniquement adaptée à certains jeux, bien que je suppose que cela pourrait être une alternative relativement décente à la mise en œuvre de quelque chose, tout en déléguant toujours à la middleware, et vous pourriez bénéficier de nombreux ajouts de serveur Web pour la manipulation de la charge ( Modules de cache, etc ...). Option 3 (à l'aide de JMS + Jee) semble vraiment surgiré, mais il est difficile de savoir sans certitude sans savoir ce que vous avez à l'esprit.

Et si vous êtes ici pour essayer d'apprendre, alors évidemment l'option 1 couvrira beaucoup de terrain. Mais ça va être une bataille plutôt en montée.

Autres conseils

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.

Licencié sous: CC-BY-SA avec attribution
scroll top