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


22

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?


2
Vous avez raison sur le serveur Java MMO .
Ricket

Réponses:


22

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.


J'aime particulièrement l'utilisation de LINQ, cela rend le serveur tellement plus simple et plus rapide à développer.
Thomas

26

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.


5

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.


5
Le vrai risque de développement de jeux (ou de tout développement en temps réel) dans les langages gérés n'est pas que tout prenne une milliseconde ou deux de plus, mais que les trames aléatoires prennent des dizaines de millisecondes de plus parce que le GC a décidé de finaliser les choses. Il est trompeur d'encourager des comparaisons axées sur le débit avec des termes comme «goulot d'étranglement».

3

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


1

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é.


N'oubliez pas que MONO peut être utilisé pour se déployer sur d'autres plateformes. Je crois que Second Life utilise cette approche - leurs scripts de jeu internes sont en fait compilés sur .NET IL mais ils se déploient sur Linux AFAIK.
ShadowChaser
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.