O C # é viável para um servidor de jogos em tempo real? [fechadas]


22

A maior parte da pergunta está no título.

Basicamente, estou começando a desenvolver um jogo de ação multiplayer em 2D. O cliente (provavelmente) estará no XNA, e eu pensei em perguntar aqui se é uma boa ideia usar o C # para o desenvolvimento no servidor também.

Eu acho que o fato de a linguagem ser gerenciada não é algo problemático, já que o Java está sendo usado mesmo em servidores de jogos MMO (me corrija se eu estiver errado), então existem razões para evitar o C # para esse fim? Eu preciso que ele seja rápido e responsivo, se comunique por TCP, converse com um servidor SQL. E se não há razão para evitar o C #, como implantaria um servidor da Web, seria um .NET EXE em execução na máquina do servidor?


2
Você está correto sobre o servidor Java MMO .
Ricket 24/03

Respostas:


22

Não apenas viável, mas muito bom, na minha experiência. Desenvolvi vários servidores MMO usando C # e devo dizer que nunca me arrependi da escolha de idioma e plataforma.

Existem muitas ótimas bibliotecas e ferramentas para C # e .NET em geral - rede, registro, mapeamento de O / R, etc. E, comparado ao Java C #, é mais expressivo e menos detalhado (algumas pessoas podem argumentar sobre isso. )

A "sobrecarga" do GC que assusta algumas pessoas não é realmente um problema, a menos que você o abuse com bilhões de alocações por segundo. Como exemplo, nosso servidor atual aloca até 50 mb / segundo sob carga pesada, e o GC não apresenta nenhum atraso perceptível. Porém, tivemos que usar o pool de objetos em locais estratégicos - o mais importante é que os objetos que representam pacotes de rede são agrupados e não coletados pelo lixo. Mesmo assim, mesmo com o pool desativado, o GC não é o maior problema.

Como um exemplo de quão legal é o C #, foi isso que implementamos recentemente. Nosso servidor executa vários serviços WCF, que o cliente do jogo usa para tarefas que não são críticas em termos de tempo, e também os usamos para administração do servidor. Acontece que é muito fácil criar um serviço WCF para simplesmente devolver nossos objetos de jogo ao chamador. Fizemos exatamente isso e criamos um pequeno plugin para o LINQPad que se conecta ao nosso servidor - e agora podemos executar consultas como

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

Em um servidor ativo, nada menos! Eu não acho que você pode fazer isso com qualquer outra plataforma. Não no trabalho de dois dias, pelo menos.


Eu gosto especialmente do uso do LINQ, isso torna o servidor muito mais simples e rápido de desenvolver.
2727 Thomas

26

Claro, você pode usar C #.

Um dos maiores problemas a serem observados em termos de desempenho em C # ou em outros ecossistemas .NET é o GC - a estrutura .NET fornece vários tipos de GC , incluindo um GC "servidor", que vale a pena aprender. O gerenciamento inteligente de memória (por exemplo, por pool) ainda é uma boa técnica, mesmo em um ambiente gerenciado.

Existem várias APIs robustas para interagir com o SQL, comunicando-se via TCP, etc. em C #, como parte da estrutura base ou por meio de terceiros; portanto, você não deve ter problemas.

Você pode utilizar o ASP.NET ou similar se realmente deseja que seu servidor seja baseado na Web; se você quiser apenas executar um processo e escutar conexões TCP, basta implantar um .exe e as dependências apropriadas na máquina do servidor, abrir as portas apropriadas e executar o .exe.


5

Eu penso que é uma grande ideia. O idioma certamente é capaz disso, e especialmente se é o que você sabe, não gaste muito tempo aprendendo um novo idioma apenas porque é "mais rápido". O verdadeiro gargalo do seu servidor será a latência da rede; um milissegundo extra ou dois porque você usou C # em vez de C ++ não fará diferença.


5
O risco real do desenvolvimento de jogos (ou qualquer desenvolvimento em tempo real) em idiomas gerenciados não é que tudo demore um milissegundo ou dois mais, mas que os quadros aleatórios levem dezenas de milissegundos porque o GC decidiu finalizar as coisas. Incentivar comparações focadas na taxa de transferência com termos como "gargalo" é enganoso.

3

Se você pode implantar no Windows, é recomendável recomendá-lo, principalmente porque seu cliente é C #.

Não subestime o desenvolvimento de servidores de jogos. Mesmo criar um servidor simultâneo apenas para bate-papo não é uma tarefa trivial, e em breve você terá muitas perguntas sobre simultaneidade, bloqueio, desempenho etc.

Apenas como ponto de partida, gostaria que você desse uma olhada nesta página que explica amplamente como fazer a programação de soquete simultânea em várias plataformas:

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

Se você é realmente sério sobre isso, eu recomendo que você estude completamente a programação de rede Unix de Stevens. É focado nos soquetes C no Unix, mas os princípios são os mesmos para todas as outras plataformas, incluindo .net.

Editar: este é outro ótimo recurso, focado na escalabilidade e desempenho de servidores simultâneos em .net. Ele não está mais disponível, mas nossos amigos na máquina de recuperação têm uma cópia dela.

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


1

Uma 'desvantagem' seria que, com o C #, se você quiser usá-lo em várias plataformas, precisará ter muito cuidado para garantir que seu código funcione em mono. Se tudo o que importa é executá-lo em uma única plataforma e o Windows for essa plataforma, você não deverá ter problemas, como os outros mencionaram.


Não esqueça que o MONO pode ser usado para implantar em outras plataformas. Acredito que o Second Life use essa abordagem - seus scripts internos de jogos são realmente compilados para o .NET IL, mas são implantados no Linux AFAIK.
ShadowChaser
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.