Quelle plateforme serveur choisir [fermé]


8

Je vais écrire un serveur pour un multijoueur en ligne avec ces exigences:

  • Jeu au tour par tour assez simple (pensez à un jeu de cartes) qui se joue entièrement sur le serveur (raisons de sécurité)
  • Doit pouvoir exécuter plusieurs jeux (tables) avec 4 joueurs par table, mais aucun système de lobby requis (un autre serveur s'en charge)
  • Peut supporter autant de joueurs à la fois que possible; Pourrait avoir besoin de plusieurs serveurs
  • Discuter entre joueurs
  • Connexion socket à un client Flash / AIR
  • Doit pouvoir communiquer avec d'autres serveurs (pour les comptes de joueurs et autres)

Maintenant, j'envisage deux options:

  • Smartfox (ou équivalent)
  • Une solution Java personnalisée dans quelque chose comme Tomcat

Pourquoi Smartfox?

  • Il gère plusieurs salles et chat en natif
  • Il a probablement des solutions pour les problèmes de jeu multijoueurs bien connus

Pourquoi personnalisé?

  • Smartfox a de nombreuses fonctions inutiles, mauvaises pour les performances
  • Smartfox communique avec un format basé sur XML, je pourrais utiliser un format binaire plus efficace.
  • Je ne sais pas si l'exécution du modèle de jeu complet sur le serveur est pratique avec le mécanisme d'extension de Smartfox
  • Plusieurs salles et chat sont faciles à réimplémenter
  • Tomcat ou un conteneur léger est plus facile à déployer que Smartfox
  • Meilleur support IDE pour le développement sur Tomcat (déploiement automatique, etc.)

Qu'est-ce que tu penses? Mes hypothèses sont-elles correctes? Avez-vous quelque chose à ajouter? Quelle option dois-je choisir (ou peut-être une autre complètement)?


Peut-être que quelque chose me manque, mais un "jeu de cartes" est si simple que vous pourriez l'écrire à partir de zéro en un temps insignifiant, et les performances ne devraient jamais être un problème.
o0 '.

Réponses:


3

J'irais certainement avec une solution personnalisée: même si vous perdez du temps à court terme, elle évoluera certainement mieux si vous en avez besoin, et l'expérience que vous gagnerez sera massivement réutilisable pour vos prochains jeux. BlazeDs semble être un excellent outil pour vos besoins, mais réécrire un serveur de jeux Java à partir de zéro n'est pas si compliqué, en utilisant par exemple Netty et Protobuf :)


Qu'est-ce que «Netty et Protobuf»?
Quazi Irfan


5

Concernant vos points à l'appui d'une solution personnalisée:

Smartfox a de nombreuses fonctions inutiles, mauvaises pour les performances

Puisqu'il s'agit d'un jeu "simple, au tour par tour", il est peu probable que les performances soient un problème.

Smartfox communique avec un format basé sur XML, je pourrais utiliser un format binaire plus efficace.

Encore une fois, pour les jeux simples au tour par tour, la facilité de développement peut facilement prendre le pas sur l'efficacité du format, donc à moins que vous ne souhaitiez développer un format binaire efficace - ne le faites pas.

Plusieurs salles et chat sont faciles à réimplémenter

Ce n'est pas une bonne raison pour choisir d'implémenter cette fonctionnalité vous-même. C'est juste quelque chose de réconfortant à savoir, si vous décidez de suivre cette voie.

Tomcat ou un conteneur léger est plus facile à déployer que Smartfox. Meilleur support IDE pour le développement sur Tomcat (déploiement automatique, etc.)

Vous devez évaluer le temps que vous gagnez en développant une solution personnalisée et en la déployant rapidement, par rapport à l'utilisation d'une solution existante et éventuellement à un déploiement plus long. Les chances sont que le temps de développement compensera le peu d'avantages que procure un déploiement plus rapide / plus facile.

Pour résumer - je recommande d'utiliser une solution existante, si possible. Cela vous fera gagner beaucoup de temps. Quant à laquelle une solution pré-existante, qui est à vous.


Concernant votre point de performance: Oui, le jeu est simple, mais il devra prendre en charge un demi-million de joueurs sur le moins de serveurs possible (si le client le souhaite)
Bart van Heukelom

Un demi-million de joueurs simultanés? On dirait que le commentaire Google App Engine mérite une réflexion supplémentaire. Cela pourra évoluer du prototype au déploiement complet avec rien d'autre qu'une facture plus importante.
drxzcl

@drxzcl a raison. Le moteur Google App est idéal pour les jeux au tour par tour pour des raisons d'évolutivité.
AturSams

3

Ayant utilisé à la fois SmartFox et ElectroServer assez largement, je recommande toujours ElectroServer. Il fait tout la même chose que SmartFox, mais est juste un peu plus solide et inclut un support binaire.


1
qu'entendez-vous par support binaire?
user3689

2

Je recommanderais fortement de regarder le projet Google App Engine .

A la fois pour des raisons d'hébergement et techniques. Si votre jeu n'est pas rapide, cela devrait être un bon endroit pour commencer et être opérationnel, et avoir la portée à l'échelle.

Le code peut être en Python ou Java.

La fierté de Neptune est sur Google App Engine. Voir une interview avec le développeur ici .


3
Il ne semble pas qu'il supporte les sockets, mais seulement HTTP
Bart van Heukelom

2

Jetez un œil au serveur de jeu netty suivant . Il prend en charge un protocole binaire. Remarque: écrit par moi! Prend en charge TCP et UDP, utilise jetlang pour une messagerie extrêmement rapide dans vm.


2

Vous devriez vraiment vous pencher sur Firebase, un serveur de jeu multijoueur Java open source.

Par rapport à Smartfox, Firebase utilise un protocole binaire, n'est pas rempli de fonctionnalités et est très performant.

Si vous lancez votre propre système, vous devrez vous occuper de tout, de la gestion des sockets à la gestion de la concurrence. Avec Firebase, vous êtes assuré d'une action à la fois, par pièce.

Remarque : Firebase acquis par Google et il n'a plus d'option open source.

Découvrez-le: http://www.cubeia.org/

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.