¿C # es viable para un servidor de juegos en tiempo real? [cerrado]

22

La mayor parte de la pregunta está en el título.

Básicamente, estoy empezando a desarrollar un juego de acción multijugador en 2D. El cliente (probablemente) estará en XNA, y pensé en preguntar aquí si es una buena idea usar C # también para el desarrollo del lado del servidor.

Supongo que el hecho de que el lenguaje se administre no es algo problemático, ya que Java se está utilizando incluso en servidores de juegos MMO (corrígeme si me equivoco), entonces, ¿hay alguna razón para evitar C # para este propósito? Necesito que sea rápido y receptivo, para comunicarme a través de TCP, para chatear con un servidor SQL. Y si no hay razón para evitar C #, ¿cómo desplegaría un servidor web de este tipo, sería un .NET EXE ejecutándose en la máquina del servidor?

Zaky German
fuente
2
Tiene razón sobre el servidor Java MMO .
Ricket

Respuestas:

22

No solo viable, sino realmente bueno, en mi experiencia. He desarrollado varios servidores MMO con C #, y debo decir que nunca me arrepentí de la elección del idioma y la plataforma.

Hay muchas bibliotecas y herramientas excelentes para C # y .NET en general: redes, registros, mapeo O / R, etc. Y, en comparación con Java, C # es más expresivo y menos detallado (algunas personas podrían discutir sobre esto, sin embargo ... )

La "sobrecarga" de GC que asusta a algunas personas no es realmente un problema, a menos que usted lo maltrate con miles de millones de asignaciones por segundo. Como ejemplo, nuestro servidor actual asigna hasta 50 mb / segundo bajo una carga pesada, y GC no introduce ningún retraso notable. Sin embargo, tuvimos que usar la agrupación de objetos en lugares estratégicos; lo más importante, los objetos que representan los paquetes de red se agrupan y no se recolectan basura. Aún así, incluso con la agrupación desactivada, GC no es el mayor problema.

Como ejemplo de lo genial que es C #, esto es lo que implementamos recientemente. Nuestro servidor ejecuta varios servicios WCF, que el cliente del juego usa para tareas que no son críticas para el tiempo, y también los usamos para la administración del servidor. Resulta que es muy fácil hacer un servicio WCF para simplemente devolver nuestros objetos del juego a la persona que llama. Así que hicimos eso, luego creamos un pequeño complemento para LINQPad que se conecta a nuestro servidor, y ahora podemos ejecutar consultas como

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

¡En un servidor en vivo, nada menos! No creo que puedas hacer esto con ninguna otra plataforma. No en el trabajo de un par de días, al menos.

No importa
fuente
Me gusta especialmente el uso de LINQ, esto hace que el servidor sea mucho más simple y rápido de desarrollar.
Thomas
26

Claro, puedes usar C #.

Una de las cuestiones más importantes a tener en cuenta en términos de rendimiento en C # u otros ecosistemas .NET es el GC: el marco .NET proporciona varios sabores de GC , incluido un GC "servidor", del que vale la pena aprender. La administración inteligente de la memoria (por ejemplo, mediante agrupación) sigue siendo una buena técnica incluso en un entorno administrado.

Hay varias API robustas para interactuar con SQL, comunicarse a través de TCP, etc., en C #, ya sea como parte del marco base o a través de terceros, por lo que no debería tener problemas allí.

Puede utilizar ASP.NET o similar si realmente desea que su servidor esté basado en la web; Si solo desea ejecutar un proceso y escuchar las conexiones TCP, puede implementar un .exe y las dependencias apropiadas en la máquina del servidor, abrir los puertos apropiados y ejecutar el .exe.


fuente
5

Pienso que es una idea genial. El lenguaje es ciertamente capaz de hacerlo, y especialmente si es lo que sabes, no pases mucho tiempo aprendiendo un nuevo idioma solo porque es "más rápido". El verdadero cuello de botella de su servidor será la latencia de la red; un milisegundo adicional o dos porque usó C # en lugar de C ++ no hará la diferencia.

Ricket
fuente
55
El riesgo real del desarrollo del juego (o cualquier desarrollo en tiempo real) en los lenguajes administrados no es que todo tome un milisegundo o dos más, sino que los marcos aleatorios demorarán decenas de milisegundos más porque el GC decidió finalizar las cosas. Alentar las comparaciones centradas en el rendimiento con términos como "cuello de botella" es engañoso.
3

Si está bien que implemente en Windows, lo recomendaría encarecidamente, especialmente porque su cliente es C #.

Sin embargo, no subestimes el desarrollo del servidor de juegos. Incluso hacer un servidor concurrente simple solo por chat no es una tarea trivial, y pronto tendrá muchas preguntas sobre concurrencia, bloqueo, rendimiento, etc.

Solo como punto de partida, me gustaría que eche un vistazo a esta página que explica ampliamente cómo hacer programación de socket concurrente en varias plataformas:

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

Si realmente lo toma en serio, le recomiendo que estudie a fondo la Programación de redes Unix de Stevens. Se centra en los sockets C en Unix, pero los principios son los mismos para todas las demás plataformas, incluida .net.

Editar: este es otro gran recurso, centrado en la escalabilidad y el rendimiento para servidores concurrentes en .net. Ya no está disponible, pero nuestros amigos en la máquina del camino tienen una copia.

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


fuente
1

Una 'desventaja' sería que con C # si desea usarlo en múltiples plataformas, debe tener mucho cuidado para asegurarse de que su código funcione con mono. Si lo único que le importa es ejecutarlo en una sola plataforma y Windows es esa plataforma, entonces no debería tener problemas como otros han mencionado.

Kyle C
fuente
No olvide que MONO se puede usar para implementar en otras plataformas. Creo que Second Life utiliza este enfoque: sus scripts de juego internos se compilan en realidad a .NET IL pero se implementan en Linux AFAIK.
ShadowChaser