côté serveur pour un jeu de silverlight tour par tour multijoueur

Question

Je suis actuellement dans les premières étapes de la conception d'un jeu basé sur navigateur en utilisant silverlight. Le jeu va avoir beaucoup de matchs de 2-4 joueurs (peut-être même jusqu'à 8) et sera basé au tour.

L'extrémité avant est Silverlight 3.0 depuis que j'ai une certaine expérience là-bas. J'essaie de comprendre ce que l'arrière devrait être. Puisque le jeu est basé sur le tour, il n'aura pas besoin d'interroger le serveur aussi souvent qu'un jeu en temps réel. La fin du serveur comprendra une sorte de couche intermédiaire qui communiquera entre le client et l'arrière-plan. L'extrémité arrière va être un C# basé service Windows qui effectue la validation et des calculs basés sur les actions des utilisateurs (attaque, défense, mouvement, compétences, nivellement etc etc).

Quels sont les avantages et les inconvénients de ce qui suit pour la couche de communication intermédiaire entre le client Silverlight 3.0 et c fenêtres # service sur le serveur.

1. Prises
2. WCF/WCF Duplex service
3. .Net RIA Services

Actuellement, je ne sais rien sur les trois options ci-dessus, mais j'ai dans le passé créé ASP. Net Web services et à l'université j'ai fait de la programmation de socket que j'ai surtout oublié.

Answer 1

Voici ma vision des choses:

Sockets: côté positif est que cela peut faire très bien. L'inconvénient est qu'il est quelque peu fragile et compliqué à mettre en œuvre à la fois sur le client et sur le serveur. J'éviterais cela à moins qu'il n'y ait pas d'autre moyen (par exemple vous avez besoin de très hautes performances). WCF/WCF Duplex: WCF est très facile à mettre en œuvre si vous prenez juste dix minutes pour réfléchir à ce que vous voulez envoyer en arrière. La performance est bonne et le déploiement est facile. Ce serait mon premier choix pour un jeu en ligne.

WCF Duplex est un peu plus complexe. Il y a quelques bons tutoriels sur la façon de faire fonctionner ça, mais je trouve qu'il y a des pièges qui ne valent pas le coup. Si vous n'avez pas besoin d'intervalles d'interrogation élevés, je m'en tiens à un WCF normal. Autant que je sache, WCF Duplex fait aussi des sondages, donc ce n'est pas vraiment un duplex.

. Service RIA .NET: Je ne suis pas sûr de celui-ci, mais je pense que l'overhead n'est pas ce dont vous avez besoin quand vous avez de gros volumes de trafic. Aussi à partir des questions du forum, j'apprends que celui-ci n'est pas si facile à personnaliser, alors que WCF est plus flexible.

Conclusion: À moins qu'il y ait une raison impérieuse de ne pas, je tiendrais à WCF.