   C# for MMO server platform?
  Ok, so I’ve been using C# and various .NET technologies recently as part of my day job and it has got me thinking seriously about how C# and .NET may be a good choice for writing the server side portion of an MMO.(client may still be primarily C++?)Pros..C# has excellent database access thanks to ADO.NET providers for Microsoft SQL, MySQL etc.C#/.NET makes it easy to call web services (e.g. billing systems, customer support systems)C#/.NET makes error handling less painful, less chance of the game server blowing up due to an unhandled exception.Microsoft's 'Velocity' Project integrates natively with C# so we get nice serializing of objects to cache (think Memcached, but a Microsoft Technology)Cons...Not cross platform (unless you consider Mono on Linux)A large farm of servers will require Windows and associated licensing costs.Interoperability between C++ client and C# server requires careful thought, less code can be shared between client and server.Integration with 3rd party middleware that is not managed code will require some work (PInvoke?)Speed? I've personally not had any speed issues with C# yet.I was wondering what other professionals think? Am I insane, or is this not as crazy as it may seem :o)   
  There's absolutely no reason you can't use C# on the server.  See RunUO, etc.It'll be harder to share types and code (eg a shared "Entity" base class, or packet id enums) though.  You'll also need to be very careful with your serialization/deserialization.  I used BinaryReader/BinaryWriter in .NET, and made sure my C code matched it (see .NET Reflector).Also, WCF is awesome for cross-server communication.[Edited by - CadetUmfer on April 25, 2009 4:50:01 AM];Quote:WPF is awesome for cross-server communicationAre you sure you didn't mean WCF?;  Thanks for the info, I've had a look at RunUO and its source, its interesting stuff, certainly proves its viable to use C#So you created your structures/classes in C# serialized them with BinararyWriter and then using .NET reflector examined them and created C++ structs/classes to match there layout, is that correct? sounds good.I've also been thinking, from an indie developer perspective, there's nothing wrong really with even using XNA for the client, makes sharing code and structures easier.XNA for a commercial AAA game though?I can't believe I'm saying all this, I've been a C++ developer all my life, but using C# recently has really got me thinking :o)   ;Quote:XNA for a commercial AAA game though?First: Are you actually writing a commercial AAA game, funded by a publisher, with several concept artists and an outsourcing team roaring to go to make the work of your design team become a reality? The concerns of those kinds of games area actually different from those of an indie, not for quality, but more for how the technology lets you split development into many parallel tasks, and then in how it lets you manage lots of separate little pieces of development. If that's not what you're doing, you simply don't need to worry about it -- just like you don't need to worry about commercial restaurant plumbing codes when you're remodeling your own living room. The needs simply are different.Second: On Windows, yes, you could ship a AAA title on XNA. It's just a C# wrapper for certain parts of DirectX/native XNA. On Windows, the performance of the CLR that runs the C# code is good, and you can always use P/Invoke to call into a native library for whatever you're missing. On Xbox, however, you have to watch out. First, the Xbox CLR is a lot slower than the the desktop CLR (by as much as 10x!). Second, there's no way to run native code, so if there's some specific capability you need but that's not in XNA, you'll have to implement it in C# (for things like animation, say), or you can't do it at all (for real-time generated audio).I agree that C# is very nice and productive for games, and even more so for higher-level applications. However, if you think C# is good, how about trying something even higher level, like Python? The trade-off is that you lose control of the bits and bytes as you rise in layering, but sometimes that's exactly what you need.   ;  Let’s assume I work for a developer/publisher of AAA MMO games ;)However, my questions relate more to my own 'indie' intentions, it’s just nice though if sometimes what you work on professionally is useful in your own indie projects or vice versa.I've only glanced at XNA, and have seen people fall into the trap of developing a game blindly on PC assuming it would just work on Xbox, only to find it performs terribly, so hopefully being aware of this I can take this into consideration from the outset and test from the beginning with Xbox. ;  I think for a long-running server C# is a great choice! Even if I wrote my client in C++, I think I'd choose C# for the server.- I've got no stability concerns. At first, I had the expectation that .NET, being relatively new and all, would be good for desktop applications but might prove not stable or major enough for applications running for weeks or months, but after seeing a particularly resource-intensive .NET 2.0 application perform its duty nearly half a year straight, I'm convinced :)- No memory fragmentation. The garbage collection will automatically compact memory, so even if your server is managing a million tiny objects in its online world, you won't end up with 50% memory waste due to fragmentation.- Buffer overflow protection. It's still one of the most common attacks, but with .NET, this is one less problem you need to take care of.;  Some very good points there.I'd forgot C# does bounds/buffer checking, and i didnt know about automatic memory compaction.   ;Quote:Original post by Cygon- No memory fragmentation. The garbage collection will automatically compact memory, so even if your server is managing a million tiny objects in its online world, you won't end up with 50% memory waste due to fragmentation.Garbage collection is definitely something that comes handy server-side. But when it comes to tiny objects, it still helps to think how and why those objects come to be. Not just because of performance (which may not be relevant), but because it's possible to avoid GC altogether. See here for example.IMHO, it's the servers where it pays to spend some time trying to reduce allocations and potentially memory use in general (applies to C# and Java).Just like manual memory management isn't always needed or desirable, GC isn't a silver bullet either.Quote:I'd forgot C# does bounds/buffer checking, and i didnt know about automatic memory compaction.Compaction is side-effect of garbage collection.   ;  I haven't used the XNA content pipeline much, but from what I've seen it's more suitable to indie than large scale development. Maybe someone can confirm?If you're going for a AAA on Windows (and only want the DX wrapper part) you may also want to consider SlimDX; XNA is somewhat hampered by the fact everything needs to work on both 360 and PC; it doesn't support DX10 or 64 bit binaries for example.   