C# for MMO server platform?

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 communication

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

Quote:

Buffer overflow protection

Once you get to the level of bits and bytes in C#, you're going to be working with unsafe code, fixed arrays and pointers, so you could still have overflow bugs in the low-level code.

That being said, the content pipeline for XNA, for what it does, is capable of supporting AAA media. You have to write a lot of code on top to extend it, though -- by default, it doesn't even have a runtime animation library. Also, the default model is aimed towards level-based games, rather than continuous-streaming games. A lot of the support you can just buy on the C++ side (anything from Granny3D to the Unreal Engine) just doesn't exist (yet?) on the C# side, so you'd probably have to provide more of your own infrastructure.

My only concern is that a MMO server in C# will cost you a LOT more per month for hosting. That's why most servers are coded in C++/Linux, or Java/Linux. Since the OS is free, you save a couple hundred dollars per month.

Quote:

Original post by Daivuk My only concern is that a MMO server in C# will cost you a LOT more per month for hosting. That's why most servers are coded in C++/Linux, or Java/Linux. Since the OS is free, you save a couple hundred dollars per month.

One word: Mono.

Quote:

a MMO server in C# will cost you a LOT more per month for hosting

If you do your own hosting, for example in a co-lo, then the upcharge for Windows is the cost of an OEM version of Windows. If you design for the Windows Server OS, then it may be expensive per machine to get started, but if you design for the "desktop" OS, the upcharge of about $150 per box isn't all that much, compared to the cost of engineers. If your engineers already know and are comfortable with Windows, cost isn't a reason to switch to Linux.

The reason we use Linux is that our people know it, and the command-line/remote administration method for such machines is generally a better match to what we want to do than Windows.

I think we've gone off topic, this is not a case of Linux vs. Windows or .Net vs. Mono :o) In the grand scheme of things when operating a MMO the cost of Windows Server licences in negligible compared to the other monumental costs :o)

(btw yes, my personal preference is Linux, but the business case for our company favours Windows, e.g. as hplus0603 noted, in our case all our engineers are mainly Windows engineers)

There's XNA, so why do the client in C++? Do that in C# as well.

Why not? EVE is written using Python.