Is C++ being replaced by C# in industry games?

Question

In industry games I mean like Quake, CoD etc.

Answer 1

In a sense, C++ is really being replaced - not only by C#, but by a slew of other languages. But if you ask, is it going to by replaced completely - then the answer is definitely no.

That's because C++ is traditionally used in two capacities. First, to create the game engine: the low-level components that load resources, push polygons to screen and crunch numbers in physics simulations. Second, to code the game logic: the actual rules that make gameplay.

This second capacity does not require C++'s strong points (such as complete control over low-level details), but suffers from its weaknesses (such as bug-prone hand-coded memory management). And in this second capacity C++ is being replaced by different scripting languages. A lot of developers use Lua; some use Python. But if a CLI platform is available, in form of either .NET or Mono, it presents a great scripting host candidate. These platforms are quite fast, reliable, offer a widely known language (C#) and a comprehensive base class library. Let's not forget tools: MS Visual studio and SharpDevelop/MonoDevelop might not be the very best IDEs in the world, but they're quite good.

That said, the game engine is not going to be written in C# (or Lua, or Python for that matter). Why? Because they're just not fast enough.

Contrary to many popular beliefs, the single biggest performance hit today is due to memory latency. This means that accessing memory is serious business. And managed languages don't allow user to control memory access - that's precisely why they're "managed" in the first place. So, no managed language will allow to write a really fast game engine. Actually, all big "C#" engines I can think of - XNA, MOGRE, Unity - are based on native C++ code; but allow to write game logic in C#.

To sum it up: C# is going to be used in place of C++ or other languages. But it will never replace C++, at least until someone invents latency-free, instant-access memory.

Answer 2

Language choice heavily depends on platform. Right now it seems really unlikely that anything but a Microsoft platform would actually require .NET as an implementation.

Conventional wisdom would say that a small platform would need to be close to the metal to be performant, but on the other hand, managed platforms are safer. That's probably the reason Windows Phone 7 forces you to use .NET.

It would certainly be interesting if the a new Xbox required a managed platform. If a phone's hardware can handle it (and it does), I could certainly see them using it on a full sized console. It would stir up the console ecosystem quite a bit as it would be harder to write cross-platform games without writing all your game code in a scripting language. If that's the case, then C# wouldn't replace C++, but it would go hand-in-hand.

Right now you could use Mono as a scripting back end (similar to what Unity does), but I would imagine that most engine makers would either want to roll their own, or use something more compact like Lua or Python than C#.

Either way, it's all about the right tool for the right job. You really should learn both languages anyway, since C# makes it easier to do certain things (tools development, server development probably, etc), and you can't use anything but C++ in some cases.

Answer 3

It's not likely. C++ has the benefit of being low level so that developers can actually tweak the tiniest detail to gain the best performance possible.

With C# and .NET you have garbage collection which is very useful, but when working with platforms with limited memory and resouces (portable consoles and to some extent home consoles) you need to have as much control over memory as possible to make the best use of the resources. Allowing managed languages to allocate and free up memory for you would most likely cause you lots of problems.

The speed is also an issue (although probably less so). Over time, I'm sure that managed languages could be made to perform comparably to C++ compilers.

Overall, in my experience anyway, game developers tend to be control freaks when it comes to memory, CPU times and resources (to squeeze out as much performance as they can), which is why C/C++ are the mainly used languages.

Answer 4

AFAIK .NET GC still suffers from stop the world style algorithm. While this can be appropriate for a wide variety of applications -- it's unacceptable for real-time apps like games.

In fact, it is very difficult to use managed languages effectively for real-time programs until we have some breakthroughs in GC.

Answer 5

No. Depending on .NET would imply massive re-writes for platforms with no available Framework, like the PS3, and the performance disadvantages may be perfectly acceptable on the PC or for Live Arcade games, but larger games are going to need every scrap of performance from their consoles to run quickly enough. More than that, there are huge existing code-bases in C++ that nobody could afford to upgrade, even if they wanted to. C++ is in the game industry and it's going to stay there for a long time.

Answer 6

At the times where computer power where scarce, everything needed to be programmed in C or C++, simply because garbage collected languages take memory control away from the programmer, and thus, performance can drop.

Nowadays, computers are faster, but as Knuth says and to put it short, optimization can be evil:

• it's obvious that low level core functionalities need to be optimized, because computing 3D geometry, physics, collisions, lighting, can quickly bloat the best processor available. You can easily tell that rising visual quality on a machine almost always significantly kills performance.

• Now, there are other functionalities, such as game states, AI, sound, input, network, which are still important in a game, but which will hardly never take as much computer resource. Those functionalities, most of the time, have not to be optimized. That's the goal of scripting language and garbage collected languages: you don't have to think about your memory coherence and your application organization, because the code you will write with these languages, if you are not coding low level stuff, will never be a bottleneck.

Example with 2 cases

• Ship 500kg of furniture with a truck.
• Ship 30 tons of material with a boat.

both are at 500 kms distance.

In both cases does it matter to make the loading/unloading process faster to make the whole transport time smaller, knowing you CANT make the boat nor the truck move faster ?

Answer is: it mattered with the truck, but not with the boat anymore, because you already did a lot by moving the stock with the boat.

I don't know if you understand this metaphor, but in a way, it can make you imagine the mathematical problem, which is more important than understanding the answer.

Scripting languages allows to make games faster if you already have an engine programmed in C/C++: the 3D engine solves the low-level problems, now you have to make the game with your scripts.

But remember: you absolutely never will be able to replace low level compiled language, EVER. Statically typed, compiled languages are the core of performance and you CAN'T rule them out, would it be a kernel, a 3D engine or a graphic card driver.

But of course, if your game is graphically simple and doesn't require a lot of vector computation, you can focus on the gameplay and forget about optimisation, because in this case you will never have to deal with optimisation since your machine are really fast for that

Except if you plan to port ir on the DS. But I'll stop there.

Answer 7

Look, I know this is a rant but i am not just splitting hairs. I feel most programmers don't really put this together. A language itself has nothing to do with run speed/performance. It's the compiler/framework. You could better argue gcc against cl (microsoft compiler pre 2010) or msbuild (current c++ compiler for 2010). Every release these compilers get better so you also have to compare them to previous versions of themselves. I am very impressed with .net and it does perform well but even if it was slightly better performing i don't see it taking over, one reason: portability.

AAA games want to be on Windows, Linux, Mac, XBox, PS3, Nintendo, etc.