Why is Microsoft not developing a Halo-like next gen title using C#? [closed]

Question

The question might look subjective but considering Microsoft:

• Owns the Xbox 360 platform
• Owns the Windows platform
• Have their own game studio (MGS)
• Own other 3rd party developers
• Is a major publisher

makes me wonder why Microsoft doesn't push their flagship language to prove that not only you can cut down significant development time, and therefore money, but also show that you can release a next gen title where the real time interactivity doesn't suffer.

If Microsoft were to do this once, I am sure many AAA developers would jump on that wagon too.

Answer 1

You need to ask a slightly different question.

Why doesn't Microsoft rewrite it's existing highly tuned gaming engines in a completely different language.

This is hopefully a more self explanatory question.

I know virtually nothing about the gaming system code base but I certainly don't imagine it to be small. Converting anything other than a trivial application from C++ to any other managed language is a huge undertaking.

Forgetting all of the syntax differences and C++ features / hacks that can't be done in C#, with a gaming application one issue at the front of the conversation will be perf. C# is not slow but it has vastly different performance characteristics. It's almost certain that highly tuned C++ gaming code will not perform nearly as well if it's directly ported to C#. A whole new round of performance tuning would have to happen and would not be cheap.

Answer 2

First, XNA wouldn't be an option. It is made with the goal of abstracting away the differences between the PC and 360. A high-performance game can't do that. It has to exploit the differences. Where the 360 shines, the performance has to be leveraged. Where it sucks, workarounds have to be developed. And vice versa for the PC.

That's also why other DirectX wrappers exist (SlimDX comes to mind as a much more direct D3D wrapper).

As for managed code in general, several problems come to mind:

• They have a large codebase already that they'd like to keep using. The way to cut down on development time is not to throw everything out the window and start over from scratch in another language.
• Most game studios still have some autonomy, even if they're owned by Microsoft. If they prefer to write their game in C++, can Microsoft overrule it? Would it be a good idea to do so? It would certainly piss off the developers, and pissed off developers aren't usually a good thing.
• Performance: Yes, C# and .NET performs very well on PC, but on consoles, it's a different story. It uses the .NET CF which, among other things, has a terribly primitive garbage collector. Its JIT compiler frankly sucks. .NETCF is not designed to outperform well-tuned native code.
• Control: The way you usually write AAA console games is to exploit everything the console has to offer. Every byte of memory should be more or less accounted for, every CPU cycle used. Managed code is simply less predictable. When does the GC run? How much memory is in use at any given time? We don't know. Consoles only have very limited amounts of memory. (The 360 has 512MB iirc. That's not much for a modern game, and it is only possible to make games like Halo 3 if you know exactly who's using how much of that memory).
• Most features on the 360 are simply not exposed to .NET. Many hardware features require either C++ interop or assembler to exploit.

When that is said, using .NET for a high-profile PC game would work a lot better. The full .NET framework has much better performance characteristics, and the available hardware on a PC is going to vary anyway, so tight control over the exact memory usage is less critical.

But ultimately, why would they do this? It'd be a big risk, it'd require a lot of code rewriting, and what exactly are they trying to prove? Most studios make cross-platform games, and for them, .NET is not an option no matter how awesome it is. They want to be able to run their code on the PS3 as well, or the Wii, or....

Answer 3

Quite simply, for real-time-like performance problems such as is presented by First Person Shooters, C# isn't up for the task. Not that it's not a good language, I use it and like working with it, but the fact is that the indeterminacy introduced by the Garbage Collection in C# makes it inappropriate for games which have high performance requirements. The same would be true of Java. Only when you get to a point where you have a certain amount of excess performance available can you really do something like this; the problem really is that somebody else is going to take that extra performance, and instead of sinking it into the runtime requirements of C# (or Java, which would have similar issues), they will just make a better-looking game. Since the consumer doesn't really care what technology the game was developed with, they'll usually go with the better-looking game, which puts any games developed with C# (or Java, like I said) at a significant disadvantage.