C++ vs C#: has the time come to develop games in a managed language?
(level : easy)
In December 2006, Microsoft released the first version of the
XNA framework and tools,
designed to allow programmers of all levels to develop games for both Windows
and the Xbox360. Initially, the only language supported is C#, and if others
(like Visual Basic) are added in the next versions of XNA, they will all belong
to the .NET family, meaning they will all be managed languages. This makes
sense for Microsoft, since they need some way of controlling what is executed
on the Xbox360 especially, to prevent people from creating viruses, cheating on
Xbox Live, or running pirated games. But from a developer's point of view, how
adequate is it to use C# to write games, what are the advantages and drawbacks
of the managed language compared to the good old native C++? (in this article,
"C++" always refers to "native C++", and not "managed C++" of course).
C++ is the language of choice to develop console games, isn't it?
Yes it is, if we're talking about game engines and middlewares only. But creating a game
requires tools, lots of them, some you buy and some you develop yourself. A
quick survey during a Tools Roundtable at GDC 2006 showed most game companies
use C# and the Windows Forms to write new internal software, and sometimes even
try to progressively migrate their old C++ / MFC applications to the .NET
framework. They don't do it purely for fun of course, but because they found
their teams work faster and can accomplish more when using .NET (and the
programs eventually end up being more reliable - more on that later). At Alias'
Maya API developer's conference in June 2006, people from
Secret Level gave a talk
about using C# to develop Maya plugins, despite the fact the SDK is 100% C++
based, and reported their productivity was multiplied by a factor of around 3.
What about the game code itself, responsible for
everything happening in the universe presented to the players? Most of the time
it is written in some scripting language, like Lua or UnrealScript. Initially,
it used to be like that because technical designers were the ones creating
behaviors for the different entities of the game world, and they needed
something they could modify and test without recompiling / debugging the whole
project in Visual Studio or something equivalent. Guess what: game programmers
have the same problem now, at High Moon Studios
they don't implement features requested by the designers in C++ anymore, they
use scripts, and the explanation for that is iteration time.
 The views and opinions expressed in
this article are strictly mine, and don't necessarily reflect those of High
Moon Studios (my current employer) or Vivendi Games.
As everybody knows, on average projects keep getting bigger in the game industry,
with more programmers writing more code and using more middlewares (I'm not
even talking about content). This results in tens of thousands of lines to
compile, and even the best compilers are having a hard time dealing with that
amount of C++ code. One problem here is header files: parsing them takes a lot
of time, and if precompiled headers are helpful for external libraries such as
the STL, they don't solve anything regarding code that is frequently modified.
The issue is actually so big, that some people use the
Single Compilation Unit method
to work around it: the basic idea is to have a new .cpp file that includes all
your original .cpp files (you read that correctly) and nothing else, and to
compile this single unit instead of all the separate files. This technique has
some drawbacks (no more incremental builds, potential naming conflicts, some
definitions are now visible from everywhere, see
for details), but I tried it for myself, and got a 4.6x speed improvement on
some not so big (about 100k lines) code base!
C# doesn't have header files. When you think about it, this is pretty cool, since this
basically divides by 2 the number of files in your solution, and you don't have
to repeat prototypes of functions you're going to implement somewhere anyway.
In addition to that, your code is only compiled to some platform independent
intermediate language (MSIL), which simplifies the job of the compiler, and
doesn't have to be linked since C# uses DLLs rather than static libraries. Of
course this has some implications regarding performance when you launch your
program, but the bottom line is: compiling is very fast.
To me, the biggest advantage of using C# (or another managed language) is not the huge
number of classes provided by the .NET framework, or the fact that it handles
the destruction of unused objects for us through garbage collection, or how much
easier it is to do some things with Forms rather than MFC; it is iteration
time, i.e. the time it takes to modify, compile, and test some piece of code.
If this time is too long, and you have to wait a few minutes before you can see
the effect of each little change you make to your program, your productivity
drops dramatically as you end up spending more time waiting than typing. Like I
mentioned before, the programmers working on gameplay features at High Moon
Studios exclusively use scripting, because it allows them to try many more
things very quickly, without having to go through the long C++ compiling and
linking process. The idea is the same when using C#: compiling is fast, and you
can get a lot more done than if you constantly have to wait for feedback.
Don't get me wrong though: I'm not saying it's
impossible to have a C++ code base made of loosely coupled classes, where
inter-dependencies are kept to a minimum, and concepts such as
and the Pimpl idiom
are put to good use to improve compilation speed. But the truth is: the C++
language doesn't do anything to help you in this area, getting things right
requires constant attention, and we all know unnecessary headers always end up
being included in other headers at some point (this is actually the most common
mistake I find when reviewing code samples from job candidates).
Iteration time is one thing, but the productivity of programmers is certainly also
greatly affected by bugs: the more time we spend debugging, the less time we
have left to implement new features or extend existing ones. Everybody makes
mistakes, but some of the characteristics of C# help preventing very common
I only listed a few
things here that, in my opinion, make it a bit easier to avoid very common bugs
when using C# rather than C++. This list is not exhaustive, I didn't talk about
type safety and delegates for example (delegates is the C# way of having type
safe function pointers basically). And this is not a summary of differences
between C++ and C# either, there would be many more (C# has 'properties',
'generics', 'reflection', but C++ has 'templates', etc).
In C++, you can create variables without giving
them any initial value. Even worse, your program may still work in debug mode,
because the compiler will assign the NULL value to pointers, and this case is
tested in your code, for example. It's only in release mode that your
application will start crashing, maybe not in a very reproducible way if you're
unlucky, and who wants to debug in release mode?
In C#, every variable has a defined value. Most
of the time you'll have to assign one when creating a variable, or the the
default one corresponding to the type of the variable will be assigned (members
of a class, for example), or the compiler will report an error as soon as you
try to use the variable (local Int32 variable in a function, for example).
The managed languages of .NET support "garbage
collection", which basically means they take care of releasing the memory
occupied by objects that are not used anymore. Be careful however: if your program
keeps a reference to the root of a big tree of nodes, for the whole lifetime of
the application, the tree will not go away magically; it still is your
responsibility in this case to say you don't need it anymore. When is garbage
collection useful then, if we keep having to indicate what we want to get rid
of? There are two main cases I can think of:
- when a reference goes out of scope, the object it represents will be deleted (some
time in the future, not necessarily immediately), provided it is not used in
any other place (it is more or less like using smart pointers without knowing
- when a reference is assigned a new value - in C++, you would get a memory leak if you
forget to delete the object that was previously pointed to by a pointer, before
assigning a new address to that pointer.
The bottom line is: in C#, you don't have to write
'delete', or 'delete' for arrays (another potential source of error in C++!).
Strings are a mess in C++, aren't they? We can
choose to use char*, TCHAR*, std::string, our own custom class, you name it. In
different code bases I've seen, several of these types are actually combined,
and converted back and forth all the time.
Nothing prevents you from writing your own string
class in C#, but it's easier to just use System.String (or 'string' for short),
which has a pretty good interface. One thing to note is that C# strings are
reference counted, meaning you will only have one instance of a given string in
memory, even if you create it 10 times in different places. That's why
functions allowing you to manipulate strings don't actually modify them: they
return an instance of the new string, without changing the original one.
There are no pointers in C#, only references. How does that help writing less bugs? The answer is
pointer arithmetic: in C++, it is way too easy to add any value to a pointer,
and end up with an address corresponding to some random memory you may even not
be allowed to access. Or to overwrite something just before or just after the
object you wanted to touch. This is the source of many many bugs, usually quite
difficult to locate, and surprisingly enough, coding without pointer arithmetic
is not annoying or difficult; it is much less difficult than learning about
C/C++ pointers in the first place!
Everybody knows multiple inheritance is
dangerous, and should be avoided except in very special cases (see More
Exceptional C++ from Herb Sutter, for example). Guess what: in C#, a class can
only inherit from one base class, there is no choice. But it can also implement
as many interfaces as you want, or you would only be able to write quite simple
programs. Basically, this means a class can only inherit member variables from
one other class, since interfaces don't have any. Of course, the same design
can be implemented in C++ with pure virtual classes, it is just more convenient
and less error prone in C# since there is an 'interface' keyword to:
1) force all the functions to be public and pure (= not implemented in the interface itself)
2) ensure there is no data member in the interface
3) verify every function is supported by the class implementing the interface
And once more, there is simply no multiple inheritance in C#.
Exceptions do exist in
C++, they are just not used very often in game development, because they're
known to be quite expensive performance-wise. But they are mandatory in C#:
this is how functions from the framework will let you know when they
encountered a problem (for example, trying to delete a read only file throws an
exception). And you are encouraged to do the same with your own classes,
instead of propagating error codes through the call stack, until some function
decides what to do with them... or not. There are several reasons why exceptions
should be prefered to error codes, like the fact that you won't be able to
ignore them (no "or not" here), and that you won't have to modify the
prototypes of your functions to add error handling. But basically all I'm
saying here is: if like me you never used exceptions in C++, you'll become used
to them quickly with C#, and should get convinced this is a better approach
than error codes propagation. Obviously, exceptions should stay exceptional in
anything but tools, but this doesn't mean you shouldn't be ready (= have some
code) to handle them, as long as they're not thrown they shouldn't cost you too
much with C# (see
There are tons of
settings in a C++ project, and making different libraries or middlewares work
together can sometimes turn into a nightmare. Changing a few settings in
several configurations of all your projects can also be time consuming and
error prone, even if you can write a script for that task. C# simplifies things
a lot, since it does not have that many settings; some people might complain
about the loss of flexibility this implies, I personally won't!
Macros are evil, every serious book about C++
will tell you that. They're easy to get wrong, impossible to debug, and can
most of the time be replaced (in C++) with constants, inline functions, and
templates. No macros in C#, period.
things you don't want the compiler to guess
The C++ compiler is
usually your friend, and it will try to do its best with the information you provide
it through your code. Sometimes, that means it will perform some operations
under the hood, like implicit conversions for example, when it thinks that's
what you intended to do. On the opposite, the C# compiler is not that
forgiving: you have to tell it exactly what you want to do, all the time, or it
will complain. You want to make all your member variables public? You have to
use the 'public' keyword for each of them, you can not just change the access
rights of a whole block like in C++ (and everything is private by default). You
want to override a virtual function in your derived class? Use the 'override'
keyword. You want to pass an integer parameter by reference when calling a
function, so that you can get a modified value after the call? Obviously this
function needs to have such a reference in its signature, but you also have to
specify you really want to use a reference when making the call [by writing
something like: result = MyFunction(ref someInteger); ]. Sure, this is a bit
more typing; but having the compiler force you to describe very clearly what
you're doing is actually a good thing, after all you're the programmer and you
don't want the compiler to try to guess what you meant.
So far in this article, I've said that C++ is not the only language used in game
development, that iteration time is critical and C# does very well in this
area, and that managed code should also require less debugging. But if you want
to go beyond tools programming, and develop a full game engine in C#,
performance is a topic of utmost importance.
The first thing people seem to worry about is garbage collection (GC): is it not too time
consuming, is the framerate going to drop if you do a GC each frame, or if you
don't call it that often and let dead objects accumulate, then will the game
stop for 1 or 2 seconds when the cleanup finally happens? I didn't do any big
experimentation myself, but here are a few interesting facts:
Another issue is Just In
Time (JIT) compilation, and the speed of the generated code. JIT compilation
means a big part of your code is going to be translated from the Microsoft
intermediate language (MSIL) into native code for the local machine at startup,
when you launch your application. This works pretty fast, but some other
assembly that is not needed immediately could also be compiled while your
program is running, in the middle of the action, right before the code it
contains gets executed. I haven't tried it on the xbox360, but on PC there is a
tool called NGen
that should take care of this potential problem, by allowing you to compile
everything on the target computer once and for all, when installing the game
Unreal Engine implements GC,
and Tim Sweeney from Epic thinks "garbage collection should be the only option"
for the next mainstream programming language
(page 57). The engine is written in C++, and the fact that it uses GC doesn't
mean this kind of technology has no CPU cost, but many many games have been and
are using Epic's middleware, and I can not say they're especially slow because
of the GC system.
GC is not a new idea, it
has been researched for a long time, and the people who created the .NET
framework are aware of the concerns programmers always have about performance.
In particular, they know it could be a deal breaker regarding running C#/XNA
applications on the xbox360, so they wrote
to explain how to reduce
the overhead of GC.
Even in native C++,
allocating and deallocating many objects each frame is pretty bad practice,
that can lead to memory fragmentation if these objects have very different
sizes. What is usually prefered is to allocate all the static objects (the
ones that don't get destroyed for the whole lifetime of a level, for example)
first, if possible in some contiguous block of memory, and to try to recycle
entities stored in various memory pools for dynamic objects (such as streaming
textures, particles, etc). The more you do this, the less GC is a problem.
January 2007 issue of the Game Developer magazine,
Mick West described how he recompiled a blob simulation with the /clr option of
Visual Studio, to compare the size and speed of a native application with a
corresponding managed one. He found the framerate dropped from 160fps to 60fps,
which sounds terrible even though he admitted this sample was more of a worst
case than a best case scenario for the .NET framework. Still, what I don't like
about this test (I like the article though, since it encourages people to try
managed code) is it doesn't take the specifics of the target language into
account: even if native and managed C++ look quite similar in a text editor,
the way they operate and use resources is very different, and I'm not sure
using the STL in managed code is a great idea for example. When I wrote my
first C#/XNA application, I started manually converting some C++ code I had;
but since it was full of pointers and unsafe casts, this was tricky, and I
quickly ended up rewriting the same function in a different, C# friendly way.
The point I'm trying to make here is: you can not count on the compiler to do
everything for you, that would be too easy, like for any other language
programmers interested in real time performance will have to learn the do's and
Fortunately, there are examples to prove writing games in C# is possible, and I mean fast 3D
games, not just puzzles or that kind of thing. The German company exDream
Entertainment has developed a racing game (see pictures
that should become one of the starter kits of XNA, and a few PC games in C#
before that .
The blog of their lead programmer Benjamin Nitschke
contains some very interesting information about game development using .NET, and so does the beginning of
(the rest is more XNA oriented).
GarageGames also wrote a non optimized C#
version of their xbox360 Live Arcade game Marble Blast Ultra, and were
apparently quite pleased with
Sure, these games may not have tons of objects affected by the laws of physics,
or a complex path finding, or any other CPU intensive algorithm you want to
insert here; but it doesn't mean it's impossible, it's probably only a question
of time before somebody does it.
Other performance pitfalls
I've seen mentioned are related to 'boxing' (converting a value-type, for
example an 'int', to a reference-type such as System.Object), and the Platform
Invoke (P/Invoke) mechanism (that can be used to
call functions of the Win32 API from managed code).
The basic rule here is to avoid doing these things too frequently (i.e. in time
critical loops), completely getting rid of them is most likely overkill (let's
call it premature optimization).
There are certainly a
few more problems that will show up every now and then, and performance is
probably always going to be a bit worse with managed code than it is with
native code anyway, after all nothing comes for free. Tim Sweeney wrote he
would gladly sacrifice 10% of performance for a 10% higher productivity,
personally I'm fine with losing even a bit more than that, if that allows me to
take advantage of the huge productivity gain C# brings to the table. In a way,
to me it's like using C++ instead of assembler: you can't beat the speed of the
latter, but writing and debugging a reasonably big game in assembler would be
time consuming to say the least, and I'd better spend more time adding features
and tuning the game, rather than try to make the fastest piece of software
ever, and have a hard time keeping it stable. The gap between C# and C++ is
obviously not as big as the one between C++ and assembler, what I mean is this
is the same kind of compromise we always have to make: performance versus
I can hear some people thinking: "I have been programming in C++ for many years, I'm an
expert, I don't want or don't have time to learn another language". There is no
worry here: you don't even need to read a book, C# looks so similar to C++ that
you can start coding immediately. Later on you may have to search for the exact
syntax for properties or delegates, but basically that's it, everything is
pretty straightforward (especially if you have done some Java as well).
The real problem is to
avoid reinventing the wheel, by knowing what's available in the .NET framework,
and where to find it. There are literally a few thousand classes, which might
sound overwhelming; fortunately, they're grouped under namespaces corresponding
to what they do (for example, System.Collections includes the different
containers supported by the framework, and the generics introduced by .NET 2.0
are in System.Collections.Generic), you will end up always reusing the same
ones, and the IntelliSense system of Visual Studio makes it easy to navigate
the tree of namespaces and see what classes are in there. Otherwise, there is
the internet and your favorite search engine, that works very well too :-)
If you have to create
GUI applications, using the Windows Forms shouldn't be difficult. The controls
are the same as usual, with the addition of the PropertyGrid (used in Visual
Studio itself), which is a very powerful tool since it takes advantage of the
reflection feature of C# to display the properties of one or several objects
(yes, it supports multi-selection editing!). I would just recommend using VS
2005 and .NET 2.0 rather than VS 2003 and .NET 1.1 if you have the choice, a
few missing events have been added to some controls, and the designer feels
improved as well. If you have used MFC in the past, you should find the code
generated by the designer is cleaner: for example, the horrible message maps
are replaced by event handlers and delegates, and some tasks like creating
nested splitters don't even require you to write code anymore, it can be done
entirely in design mode. Same thing with resizing controls when the dimensions
of the window containing them change: the new docking/anchor system is not
perfect, but it can handle a lot of common situations with only a few
properties to edit.
To sum it up, programming in C# is easy if you have coded in C++ for a long time, creating a
GUI with the Windows Forms is not difficult either, discovering the content of
the different namespaces of the framework takes a bit more time though; but you
don't have to learn everything upfront, this is an incremental process, and
these already implemented classes is one of the things that will help you save
time and increase your productivity.
Has the time come to develop games in C#?
If C# is so great, why
is not everybody in the game industry already using it? The first problem is:
it's not really cross platform. Its primary target was the PC, it has only been
available on xbox360 since the end of 2006 (with the release of XNA 1.0) and
there are still a lot of limitations in this case (for example, it's impossible
to write a tool running on PC that talks to the console while the game is
running), and it's not supported at all on other consoles.
The second problem is
middlewares: they are all written in native code, with a C++ API. It is totally
possible to call such an API from C#, for example to write a managed program
that uses OpenGL for rendering. There are several drawbacks to take into
A third problem is executing the game: in addition to DirectX or OpenGL, a C# game
needs the .NET framework in order to run. This issue is not too bad, PC games already
contain a redistributable version of the DirectX runtime, they could also
install the .NET framework if it's missing on the target computer. On xbox360,
I suppose Microsoft could push the framework through Xbox Live if they wanted
to, but it would also have to be included on the DVD anyway (for people not
connected to Xbox Live).
Writing the wrapper translating the C# calls to C++ (because the types are not the same
in both languages, for example a C++ function can take a char* parameter) is
tedious and error prone. And it has to be done each time you get a new version
of the middleware. This can be automated to some extent, but from what I've
heard there are always some tricky cases that have to be handled manually.
Each call to the middleware means switching from a managed context to a native
context and back, which is expensive performance wise. This will also make
debugging more difficult in general (assuming you have the source code of the
Using native libraries kind of defeats the purpose
of writing a managed application in the first place, since these libraries
won't benefit from garbage collection for example, if they allocate memory.
So, do the first two problems mean the answer is "no" (the time has not come
to develop games in C#)? I guess if you want to develop for
other platforms than the Microsoft ones, you'll have to stick with the good old
C++, probably for a very long time (I don't see any other language replacing it
any time soon). You can (and should) still use C# to code some tools running
on PC, but that's about it.
Now if you're mostly
interested in the PC and Xbox, or if you can afford (lucky you!) to develop a
game for only one platform (and eventually port it to other ones later when
your title is successful, or have another company do the conversion), then it's
a different story. There is still the issue of middlewares, and the
limitations of XNA on the xbox360 (at least until XNA Game Studio Professional
is released, supposedly next summer), but I believe it's time to begin
experimenting, at least on PC. It's time to do some R&D work and learn the do's
and dont's regarding performance, to start writing libraries that are too game
specific to be in the framework, and perhaps to develop a prototype in managed
code for a future game. Think about it: a prototype doesn't have to run on all
existing platforms, and would be quite a learning experience! I think Microsoft
realizes developing games is really becoming way too long and expensive, and I
expect them to encourage developers to make the move to managed languages a lot
more in the future, maybe with the successor of the xbox360, or even before. If
that happens, we, game programmers, would better be ready for it! And let's
face it: learning and trying new things is part of what makes our job so
exciting, isn't it?
back to top