Le cadre XNA est-il approprié pour la programmation côté serveur?

Je cherche à créer une MUD basée sur du texte, donc beaucoup d'éléments du cadre XNA semblent appropriés à ce dont j'ai besoin. Surtout des choses comme la boucle de jeu générale, la mise en réseau, etc. Il semble que XNA soit étroitement couplé à un environnement interactif avec interface utilisateur et audio, donc je ne suis pas sûr que ce soit la bonne façon de procéder.

Serait-il plus facile de recréer ces types d'aspects moi-même, de tenter de plier le framework XNA à ce dont j'ai besoin, ou existe-t-il un meilleur framework pour ce type de travail?

Je ne pense pas que le framework XNA vous offrirait beaucoup d'utilisation pour le côté serveur d'un jeu basé sur du texte, non. Vous devez consulter les bibliothèques de classes du framework .NET standard pour ce cas d'utilisation.

Mais en élargissant un peu la question, bien que les frameworks XNA soient vraiment destinés au développement de jeux 2D et 3D côté client, il peut y avoir lieu d'en utiliser certaines parties côté serveur d'un jeu 2D ou 3D. Il est courant de réutiliser des parties du moteur graphique sur le serveur car le serveur a autant besoin de faire des tests de visibilité et de collision que le client. Dans ce scénario, si votre moteur a utilisé la bibliothèque mathématique de XNA, vous devrez également le lier dans votre code serveur.

Si vous utilisez C #, vous devriez simplement envisager d'utiliser WCF pour éliminer la couche réseau. Un MUD n'aurait pas beaucoup de trafic réseau, relativement parlant, donc suivre cette route pourrait vous faciliter la tâche. J'utilise WCF pour un jeu de stratégie au tour par tour, et cela a très bien fonctionné pour moi.

Vous pouvez suivre la voie XNA et utiliser simplement les éléments particuliers que vous désirez (audio, réseau, etc.); mais cela augmente la complexité de votre projet et diminue votre "compréhension immédiate" de la base de code.

Fondamentalement, à mesure que vous ajoutez plus de middleware, votre connaissance de la façon dont votre code fonctionne réellement diminue - à moins que vous ne vous plongiez dans l'implémentation du middleware. En vous éloignant, vous perdez en efficacité, en capacité et en compréhension.

Ainsi, comme indiqué ci-dessus, il serait beaucoup plus avantageux pour vous d'utiliser C # et les bibliothèques non XNA appropriées.

Si vous faites cela pour votre propre édification, vous pourriez tout aussi bien rouler le vôtre là où vous êtes intéressé par la zone - vous en apprendrez plus de cette façon.

Fonce! S'amuser!

Cela dépend largement de vos besoins.

Si vous êtes intéressé à soutenir l'audio, un ami vous invite, et cetera que je pense que XNA est la voie à suivre.

La principale limitation que vous rencontrez avec l'utilisation de XNA pour la mise en réseau est la limite de 32 joueurs par partie.

Lorsque vous développez un jeu avec le framework XNA, il n'est pas absolument nécessaire d'être couplé à toutes les différentes API. De nombreuses personnes utilisent le framework XNA mais s'appuient sur d'autres frameworks pour la mise en réseau.

Ma suggestion est de physiquement (les écrire dans le bloc-notes ou quelque chose) énumérer vos besoins et désirs pour l'aspect réseau. Ensuite, comparez et contrastez les différents cadres.

Je penche pour dire "créer à partir de zéro", mais ce n'est qu'un sentiment instinctif basé sur le fait d'avoir travaillé séparément avec le code C # et MUD. Vous aurez plus de contrôle et en apprendrez plus en déployant vos propres versions de tout ce que vous pourriez utiliser à partir de XNA, de toute façon.

Une raison pour laquelle vous n'utilisez pas un moteur MUD existant, au moins pour référence?