C # è praticabile per un server di gioco in tempo reale? [chiuso]


22

Gran parte della domanda è nel titolo.

Fondamentalmente, sto iniziando a sviluppare un gioco d'azione multiplayer in 2D. Il client sarà (probabilmente) in XNA, e ho pensato di chiedere qui se è una buona idea usare C # anche per lo sviluppo lato server.

Immagino che il fatto che il linguaggio sia gestito non sia problematico in quanto Java viene utilizzato anche nei server di gioco MMO (correggimi se sbaglio), quindi ci sono ragioni per evitare C # a questo scopo? Ho bisogno che sia veloce e reattivo, per comunicare su TCP, per chattare con un server SQL. E se non vi è alcun motivo per evitare C #, come dovrei distribuire un tale server Web, sarebbe un EXE .NET in esecuzione sul computer server?


2
Hai ragione sul server MMO Java .
Ricket,

Risposte:


22

Non solo fattibile, ma davvero buono, nella mia esperienza. Ho sviluppato diversi server MMO usando C # e devo dire che non mi sono mai pentito della scelta della lingua e della piattaforma.

Ci sono molte grandi librerie e strumenti per C # e .NET in generale - rete, registrazione, mappatura O / R, ecc. E, rispetto a Java C # è più espressivo e meno dettagliato (alcune persone potrebbero discuterne, però ... )

Il "sovraccarico" GC che spaventa alcune persone non è davvero un problema, a meno che non vi capiti di abusarne con miliardi di allocazioni al secondo. Ad esempio, il nostro server attuale alloca fino a 50 mb / secondo sotto carico pesante e GC non introduce alcun ritardo evidente. Abbiamo dovuto utilizzare il pooling di oggetti in luoghi strategici, ma soprattutto, gli oggetti che rappresentano i pacchetti di rete sono raggruppati e non raccolti in modo inutile. Tuttavia, anche con il pooling disattivato, GC non è il problema più grande.

Come esempio di quanto sia bello C #, questo è ciò che abbiamo implementato di recente. Il nostro server esegue diversi servizi WCF, che il client di gioco utilizza per attività non temporali e li usiamo anche per l'amministrazione del server. Si scopre che è molto semplice creare un servizio WCF per restituire semplicemente i nostri oggetti di gioco al chiamante. Quindi abbiamo fatto proprio questo, poi abbiamo creato un piccolo plugin per LINQPad che si collega al nostro server - e ora possiamo eseguire query come

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

Su un server live, niente di meno! Non penso che tu possa farlo con qualsiasi altra piattaforma. Almeno non nel lavoro di due giorni.


Mi piace particolarmente l'uso di LINQ, questo rende il server molto più semplice e veloce da sviluppare.
Thomas,

26

Certo, puoi usare C #.

Uno dei maggiori problemi di cui tenere conto in termini di prestazioni in C # o in altri ecosistemi .NET è il GC: il framework .NET offre diversi tipi di GC , incluso un GC "server", che vale la pena conoscere. La gestione intelligente della memoria (ad esempio, mediante pooling) è ancora una buona tecnica anche in un ambiente gestito.

Esistono diverse API robuste per interagire con SQL, comunicare via TCP, eccetera in C #, sia come parte del framework di base o tramite terze parti, quindi non dovresti avere problemi lì.

Puoi utilizzare ASP.NET o simili se vuoi davvero che il tuo server sia basato sul web; se si desidera solo eseguire un processo e ascoltare le connessioni TCP, è possibile distribuire un file .exe e le dipendenze appropriate sul computer server, aprire le porte appropriate ed eseguire il file .exe.


5

Penso sia un'ottima idea. La lingua è sicuramente in grado di farlo, e soprattutto se è quello che sai, non perdere un sacco di tempo a imparare una nuova lingua solo perché è "più veloce". Il vero collo di bottiglia del tuo server sarà la latenza di rete; un millesimo di secondo in più perché hai usato C # invece di C ++ non farà differenza.


5
Il vero rischio di sviluppo del gioco (o di qualsiasi sviluppo in tempo reale) nelle lingue gestite non è che tutto impieghi un millisecondo o due in più, ma che i frame casuali impiegheranno decine di millisecondi in più perché il GC ha deciso di finalizzare le cose. Incoraggiare confronti focalizzati sulla produttività con termini come "collo di bottiglia" è fuorviante.

3

Se va bene per te distribuire su Windows, lo consiglio vivamente, soprattutto perché il tuo client è C #.

Tuttavia, non sottovalutare lo sviluppo del server di gioco. Anche creare un semplice server simultaneo solo chat non è un compito banale e presto avrai molte domande su concorrenza, blocco, prestazioni, ecc.

Proprio come punto di partenza, vorrei che tu dessi un'occhiata a questa pagina che spiega ampiamente come eseguire la programmazione simultanea di socket su diverse piattaforme:

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

Se sei davvero serio, ti consiglio di studiare a fondo la programmazione di rete Unix di Stevens. È focalizzato sui socket C su Unix, ma i principi sono gli stessi per ogni altra piattaforma, incluso .net.

Modifica: questa è un'altra grande risorsa, focalizzata sulla scalabilità e le prestazioni per i server simultanei in .net. Non è più disponibile, ma i nostri amici della macchina del ritorno ne hanno una copia.

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


1

Uno "svantaggio" sarebbe che con C # se si desidera utilizzarlo su più piattaforme, è necessario fare molta attenzione per assicurarsi che il codice funzioni con mono. Se tutto ciò che ti interessa è eseguirlo su un'unica piattaforma e Windows è quella piattaforma, allora non dovresti avere problemi come altri hanno già detto.


Non dimenticare che MONO può essere utilizzato per distribuire su altre piattaforme. Credo che Second Life utilizzi questo approccio: i loro script di gioco interni sono in realtà compilati in .NET IL eppure vengono distribuiti su Linux AFAIK.
ShadowChaser,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.