C # est-il viable pour un serveur de jeu en temps réel? [fermé]

La plupart de la question est dans le titre.

En gros, je commence à développer un jeu d'action multijoueur 2D. Le client va (probablement) être dans XNA, et j'ai pensé demander ici si c'était une bonne idée d'utiliser C # pour le développement côté serveur également.

Je suppose que le fait que le langage soit géré n'est pas quelque chose de problématique car Java est utilisé dans même les serveurs de jeux MMO (corrigez-moi si je me trompe), alors y a-t-il des raisons d'éviter C # à cet effet? J'en ai besoin pour être rapide et réactif, pour communiquer sur TCP, pour discuter avec un serveur SQL. Et s'il n'y a aucune raison d'éviter C #, comment pourrais-je déployer un tel serveur Web, serait-ce un EXE .NET s'exécutant sur la machine serveur?

Non seulement viable, mais vraiment bon, selon mon expérience. J'ai développé plusieurs serveurs MMO en C #, et je dois dire que je n'ai jamais regretté le choix de la langue et de la plateforme.

Il existe de nombreuses bibliothèques et outils pour C # et .NET en général - réseau, journalisation, mappage O / R, etc. )

Le "surcoût" du GC qui fait peur à certaines personnes n'est pas vraiment un problème, sauf si vous en abusez avec des milliards d'allocations par seconde. Par exemple, notre serveur actuel alloue jusqu'à 50 Mo / seconde sous une charge élevée, et GC n'introduit aucun décalage notable. Nous avons cependant dû utiliser la mise en commun des objets dans des endroits stratégiques, mais surtout, les objets représentant les paquets réseau sont regroupés et non récupérés. Pourtant, même avec la mise en commun désactivée, GC n'est pas le plus gros problème.

Comme exemple de la fraîcheur de C #, c'est ce que nous avons récemment implémenté. Notre serveur exécute plusieurs services WCF, que le client du jeu utilise pour des tâches non urgentes, et nous les utilisons également pour l'administration du serveur. Il s'avère que c'est très facile de faire un service WCF pour simplement retourner nos objets de jeu à l'appelant. Nous avons donc fait exactement cela, puis créé un petit plugin pour LINQPad qui se connecte à notre serveur - et maintenant nous pouvons exécuter des requêtes comme

from character in Service.GetOnlineCharacters()
where character.LocationManager.LocationId==5 && character.Attributes.Level<10
select new { character.Id, character.Nick }

Sur un serveur live, rien de moins! Je ne pense pas que vous puissiez le faire avec une autre plate-forme. Pas au moins deux jours de travail.

Bien sûr, vous pouvez utiliser C #.

L'un des problèmes les plus importants à prendre en compte en termes de performances en C # ou dans d'autres écosystèmes .NET est le GC - le framework .NET fournit plusieurs versions de GC , y compris un GC "serveur", qui méritent d'être étudiées. La gestion intelligente de la mémoire (par exemple, par regroupement) est toujours une bonne technique, même dans un environnement géré.

Il existe plusieurs API robustes pour interagir avec SQL, communiquer via TCP, et cetera en C #, soit dans le cadre du framework de base ou via des tiers, donc vous ne devriez avoir aucun problème là-bas.

Vous pouvez utiliser ASP.NET ou similaire si vous voulez vraiment que votre serveur soit basé sur le Web; si vous souhaitez simplement exécuter un processus et écouter les connexions TCP, vous pouvez simplement déployer un .exe et les dépendances appropriées sur la machine serveur, ouvrir les ports appropriés et exécuter le .exe.

Je pense que c'est une excellente idée. La langue en est certainement capable, et surtout si c'est ce que vous savez, ne passez pas beaucoup de temps à apprendre une nouvelle langue simplement parce qu'elle est "plus rapide". Le véritable goulot d'étranglement de votre serveur sera la latence du réseau; une milliseconde supplémentaire ou deux parce que vous avez utilisé C # au lieu de C ++ ne fera aucune différence.

Si vous pouvez déployer sur Windows, je le recommande fortement, d'autant plus que votre client est C #.

Ne sous-estimez pas le développement du serveur de jeu. Même la création d'un serveur simultané simple de chat n'est pas une tâche triviale, et vous aurez bientôt beaucoup de questions concernant la concurrence, le verrouillage, les performances, etc.

Juste comme point de départ, j'aimerais que vous jetiez un coup d'œil à cette page qui explique en gros comment faire une programmation de socket simultanée sur plusieurs plates-formes:

http://geekswithblogs.net/quension/archive/2006/06/30/83760.aspx

Si vous êtes vraiment sérieux à ce sujet, je vous recommande d'étudier à fond la programmation réseau Unix de Stevens. Il est axé sur les sockets C sous Unix, mais les principes sont les mêmes pour toutes les autres plates-formes, y compris .net.

Modifier: Il s'agit d'une autre excellente ressource, axée sur l'évolutivité et les performances des serveurs simultanés en .net. Il n'est plus disponible, mais nos amis de la machine de retour en ont une copie.

http://replay.waybackmachine.org/20080405220143/http://www.coversant.net/dotnetnuke/Coversant/Blogs/tabid/88/EntryID/10/Default.aspx

Un 'inconvénient' serait qu'avec C # si vous voulez l'utiliser sur plusieurs plateformes, vous devez être très prudent pour vous assurer que votre code fonctionnera en mono. Si tout ce qui vous intéresse est de l'exécuter sur une seule plate-forme et que Windows est cette plate-forme, vous ne devriez pas avoir de problèmes comme d'autres l'ont mentionné.