In industry games I mean like Quake, CoD etc.

  • 7
    \$\begingroup\$ It would help if you explained briefly what gave you the idea, since it’s a very odd idea to say the least. \$\endgroup\$ Feb 5, 2011 at 12:24
  • 2
    \$\begingroup\$ Considering Quake is done in C.. ;-) \$\endgroup\$ Feb 5, 2011 at 18:35
  • \$\begingroup\$ I was just wondering this question myself! \$\endgroup\$
    – Jeff
    Feb 5, 2011 at 20:42
  • 2
    \$\begingroup\$ It sounds like by "industry games" you mean what is usually called "AAA titles". \$\endgroup\$
    – chaos
    Feb 6, 2011 at 3:18

7 Answers 7


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.

  • 16
    \$\begingroup\$ +1 Visual Studio is a very good IDE. Even if it is the dark side... \$\endgroup\$ Feb 5, 2011 at 16:52
  • 1
    \$\begingroup\$ Bah, in my experience C# isn't fast enough for the simulation either, but that doesn't stop people from trying. \$\endgroup\$ Feb 9, 2011 at 6:59
  • \$\begingroup\$ @Nevermind What is "Managed languages"? \$\endgroup\$ Jan 16, 2012 at 12:03
  • 3
    \$\begingroup\$ @iamcreasy In broad sense, by "Managed languages" I mean languages that run under virtual machine that includes some form of garbage collection and/or memory management. More strictly, managed languages are languages that target (some implementation of) Common Language Runtime, but my answer applies not only to them. \$\endgroup\$
    – Nevermind
    Jan 16, 2012 at 12:26
  • \$\begingroup\$ In your opinion, do reference-counted GC schemes fall under this category a la Vala? \$\endgroup\$
    – weberc2
    May 8, 2013 at 21:21

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.

  • \$\begingroup\$ As of now, 3 years later the state of C# for game development is much more evolved. Mono-Project picked up XNA Game Studio and rebranded it MonoGame. SharpDX, SlimDX, and OpenTK are all very decent opengl/directx wrappers. Even a few physics engines in c# have emerged. Mono/MonoGame allows you to build a game once and auto port it to android, linux, mac os, ios, xbox 360, ps3, ps4, and wii. \$\endgroup\$
    – Ryan Mann
    Dec 13, 2014 at 7:19

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.


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.


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.

  • \$\begingroup\$ While inertia exists, the C++ codebases are not themselves that old - perhaps 10 years at most. Almost all code in them has undergone replacement during that period - for 3D accelerators, programmable pipelines, data-driven architectures, and scripting support. If a AAA developer wanted to do a full migration to C#, they could probably accomplish it for minimal cost within the space of three games - first use it as a tool and scripting host, second move the game logic layers to it, and third port the renderer to use a managed DX/GL wrapper. \$\endgroup\$
    – user744
    Feb 5, 2011 at 17:38
  • 1
    \$\begingroup\$ Mono does have a commercial .NET solution for PS3. \$\endgroup\$
    – Dan Olson
    Feb 6, 2011 at 8:02
  • \$\begingroup\$ Seconded, if you build your game in c# against mono or with monogame (xna replacement), you can port it to ps3/ps4, wii, xbox 360, android, max os, etc built in. \$\endgroup\$
    – Ryan Mann
    Dec 13, 2014 at 7:21

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.

  • 1
    \$\begingroup\$ "optimization can be evil" is by far the most uselessly mutated version of his statement I've read. \$\endgroup\$
    – user744
    Feb 8, 2011 at 11:16
  • \$\begingroup\$ well I'm explaining it, that's why I found useless to quote his entire statement, which is a quite long sentence and isn't really explained... On top of that, we are talking about games, which isn't the same broader software Knuth wanted to speak about. \$\endgroup\$
    – jokoon
    Feb 8, 2011 at 11:20
  • \$\begingroup\$ You mention that input hardly ever takes up many computer resources. I would like to point out that as the player becomes more physically connected to the game, this becomes less true. For example, the kinect. It's a form of input, but requires lots of computing resources to make use of. \$\endgroup\$ Feb 26, 2011 at 0:13

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.

  • \$\begingroup\$ Certainly the compiler implementation plays a role, but different languages provide different affordances for compiler-driven optimization, and different affordances for programmers to circumvent the usual language rules and talk to the hardware directly. The language and target per se have plenty to do with performance. \$\endgroup\$
    – user744
    Feb 25, 2011 at 18:14
  • \$\begingroup\$ A language can have a lot to do with run speed/performance because the syntax and standard libraries will favour different approaches. For example, a language where it is hard to use arrays of contiguous memory due to all their objects being pointers will tend to thrash the cache a lot more than one where you can use arrays or vectors effectively. \$\endgroup\$
    – Kylotan
    Feb 26, 2011 at 14:59
  • \$\begingroup\$ +1 very good point, which you could have made without insulting the stupid people, they know not who they are. \$\endgroup\$
    – Fire Crow
    Mar 25, 2011 at 19:57
  • \$\begingroup\$ Except, as of today, You can build against mono and it ports to just about everything. E.g. it's now highly portable. \$\endgroup\$
    – Ryan Mann
    Dec 13, 2014 at 7:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .