Architecture du jeu sur navigateur social multijoueur (choix du backend + choix du frontend [flash / silverlight]) [fermé]

Question

Je songe à développer un jeu social multijoueur en ligne. La situation partagée dans le monde nécessiterait quelque chose de rapide sur le serveur, de sorte que les solutions potentielles semblent être les suivantes:

1. moteur de jeu rapide sur le serveur (par exemple, c ++) et certains langages frontaux (php / python / ruby) + flash

2. toute la pile en python (avec du python torsadé ou sans pile) + flash

3. .NET (asp.net ou asp.net mvc) + flash

4. .NET + silverlight

La première peut être exagérée du point de vue de la productivité (3 couches hétérogènes)

Nr. 4 est peut-être le paradis du programmeur (environnement commun à toutes les couches), mais:

• Rien de tel n’a jamais été construit avec Silverlight, il y a peut-être des révélateurs cachés au coin de la rue
• Il peut être difficile de trouver des concepteurs Silverlight
• Bien que le modèle de séquence / clip Flash soit critiqué par rapport à l'architecture complète OO de SL, n'est-il pas un avantage lorsqu'il s'agit de concevoir des parties supplémentaires du monde virtuel par des concepteurs externes? Ils peuvent juste préparer. Swf avec par exemple. 4 perspectives d'un élément sur 4 images - ne serait-il pas plus difficile avec SL?
• Il manque apparemment certaines fonctionnalités de jeu à Silvelight (comme la détection de collision)

qu'en pensez-vous?

[EDIT] Le jeu lui-même ferait partie d’un plus grand portail. Il serait donc intéressant d’intégrer le moteur dans un cadre Web.

Answer 1

Eve Online utilise l'option 2 - utiliser Python sans pile -.

http://support.eve-online.com /Pages/KB/Article.aspx?id=128

Modifier

Jusqu'à ce que vous ayez un logiciel réel, bien sûr, il est impossible de créer une architecture assez performante. Donc, tout jugement ici n’est que pure spéculation.

Cependant, tenez compte de ce qui suit.

1. Le contenu statique (fichiers .js, .css, .png, etc.) a tendance à dominer la bande passante de votre réseau. Pour ce faire, vous devrez utiliser un serveur proxy inverse (squid, par exemple).

2. Squid doit obtenir le contenu de quelque part. Vous voulez un serveur de fichiers léger fournissant du contenu statique à squid. Nginx ou lighttpd ou quelque chose. Apache travaillera pour cela, mais dans une certaine mesure, cela pourrait être excessif.

3. Votre contenu dynamique, semble-t-il, se présentera sous deux formes.

   • JSON pour supporter le jeu.

   • HTML pour prendre en charge le portail.

   Pour cela, vous seriez plus heureux avec un moteur mod_wsgi. Apache fait certainement cela; ngingnx et lighttpd pourraient également fonctionner.

   • Vos données JSON doivent être un ensemble d’URI. REST est un bon modèle de conception. Grâce à mod_wsgi, ceux-ci se connectent au serveur orienté jeu en utilisant - si nécessaire - Python sans pile. Votre serveur frontal (Apache, par exemple) a un emplacement, un répertoire ou un hôte virtuel pour filtrer ces URI et les acheminer vers un démon mod_wsgi qui sert le jeu. Regardez Wekzeug pour le construire.

   • Votre contenu HTML est un autre ensemble d'URI. À travers mod_wsgi, ceux-ci se connectent à un serveur Django exécutant Python conventionnel. Votre serveur frontal (Apache, par exemple) a un emplacement, un répertoire ou un hôte virtuel pour filtrer ces URI et les acheminer vers un démon mod_wsgi.

Answer 2

J'ai travaillé pendant un an sur un jeu en ligne massivement multijoueur utilisant Silverlight pour le front-end et Python pour le back-end (j'ai utilisé IronPython dans Silverlight afin de simplifier le développement)

Silverlight est très bien adapté à cela, je ne ferais pas un jeu en ligne sérieux en quoi que ce soit d'autre. Il a déjà 35% du marché. Une fois que vous avez terminé, il devrait être suffisamment important pour ne plus avoir beaucoup d’importance. Pour les jeux sérieux, la plupart des gens n’auront aucun problème à installer un plugin de navigateur de 4MB. Si vous voulez juste un petit clone d’astéroïdes, utilisez flash.

Si je devais le refaire, je pense que je garderais Python pour le serveur, car c'est la technologie de serveur avec laquelle je suis le plus doué, mais je pense que j'utiliserais le C # sur le front-end et le JSON pour transmettre des données .

Le meilleur conseil que je puisse vous donner est:

1. Utilisez autant que possible les bibliothèques et le code existants
2. Ne pensez pas aux performances prématurément

La partie la plus difficile sera de terminer le jeu, d’utiliser la technologie que vous connaissez bien et d’optimiser pour votre temps, pas le code. J'espère que vous pourrez faire ce que je n'ai pas pu - terminer ce foutu jeu:)

Modifier

Concernant la raison pour laquelle j'utiliserais le C # si je devais le refaire:

IronPython présentait des avantages et des inconvénients. C'était génial de pouvoir partager des fichiers de code (constantes, modèles, etc.) sur le serveur et le client. Faire un changement et rafraîchir le navigateur pour le voir était génial. Le débogage n’était pas aussi convivial que C #.

Mais, à certains égards, il s’agit d’un citoyen de deuxième classe, la liaison de données n’a pas fonctionné et vous ne pouvez pas utiliser les classes IronPython dans xaml. Le temps de chargement posait problème, aussi ai-je déployé beaucoup d'efforts pour configurer l'importation en parallèle sur les threads d'arrière-plan afin de l'accélérer. En raison du second statut de citoyen en ce qui concerne xaml, j’ai utilisé un langage de modèle pour générer le xaml comme si c’était du code HTML, qui fonctionnait mieux que la liaison de données, mais aucun langage de modèle python ne fonctionnait dans IronPython; j’ai donc écrit le mien ( une autre fois couler.)

Pour activer les modèles de partage, je devais écrire mon propre ORM. C'était assez facile. Mais pour les transférer, j'ai transmis JSON et créé un format binaire optimisé qui fonctionnait entre IronPython et Python. Ce fut une autre fois couler.

Avec le recul, je n'aurais pas dû être distrait par toutes ces traînées de lapins.

Answer 3

Twisted a été utilisé à cette fin avec succès. Basé sur des appels asynchrones, il est très efficace pour les applications nécessitant des connexions persistantes. En outre, il a une belle implémentation RTMP pour une utilisation avec flash. Vérifiez chesspark, il est construit avec Twisted:

http://www.chesspark.com/

De plus, le moteur de jeu ne doit pas nécessairement être en c / c ++. Cela dépend de la complexité et du type de jeu. Mais il y a aussi la bibliothèque pygame qui est très bonne.

Personnellement, je vous découragerais d’utiliser Silverlight. Le plugin flash est beaucoup mieux adopté et continuera à l’être dans un avenir prévisible, en particulier sur les systèmes d’exploitation non ms. Ne prenez pas cela à cœur mais je n’installerais pas Silverlight uniquement pour voir votre jeu.