How do I know when I need to use c++, instead of Java, C#, pythonor something else? All I read is that "when you do real game making" you use C++. I put the word "real" because that is the feeling I get after reading many articles.

The games in question are for the desktop, Windows in particular. No genre.

  • \$\begingroup\$ There really is no language requirement. You can use pretty much anything. People just prefer C++ because it is faster (generally speaking). Basically what you are looking at is the "No True Scotsman" logic fallacy (yourlogicalfallacyis.com/no-true-scotsman). \$\endgroup\$ – Benjamin Danger Johnson Aug 26 '13 at 16:46


C++ is a highly portable language. There are C++ compilers for almost every platform. Even languages which are in theory as or more portable, like Python, may have no standard implementation for a particular platform. For instance, to write a Python game for the XBox, you would at least need to write a C++ loader around libpython since there is no way to directly run Python code on the XBox. The same goes for most other languages. Note that you will generally have to port an OS-specific layer for each platform with C++, but then this is no different than needing to port another language's interpreter or standard library. Your target platforms may mandate or strongly encourage the use of C++.


Just about every single notable middleware, library, and OS provides a C or C++ API. In order to use these libraries from other languages, at the bare minimum a wrapper must be written. Sometimes these wrappers are not trivial to write. There's a lot of time and money to be saved by being able to drop in Scaleform, Havok, SpeedTree, or so on to your game which you will have a tougher time doing if you're writing in Java or Ruby or somesuch. The features you want to support and the amount of money you're willing to spend independently developing them may push you towards C++.


Some platforms have artificial restrictions making other languages less attractive. The XBox360 does not allow JIT compilers due to security concerns, automatically eliminating some languages/implementations like V8, most Java VMs, LuaJIT, Pypy, and so on. iOS bans any JavaScript runtime other than the one bundled (which is not the same one that Safari uses, notably, giving Apple's first-party applications a distinct advantage), barring the use of v8, and for a time had license language that would have barred any scripting language (though that language was relaxed). iOS also lacks any Flash/ActionScript runtime. There are other, more esoteric restrictions that can matter. You may be barred from using an option you prefer more than C++.


The experienced game developers in the industry typically know C++ very well but may be somewhat "deficient" when it comes to today's popular Web/FOSS favorites. If you're making a game you may need to plan for the future and think about what it'll be like trying to find an experienced games developer down the road. You may find it easier with C++ simply because there simply aren't any 10-year games industry veterans whose games experience is primarily with, say, Scala. HR concerns are eased with C++.


Games often need to do tricky things, and a game engine is some of the lowest-level software you can write besides kernels, graphics drivers, and compilers (though they can often have elements of all three). Keep in mind that pretty much every other popular language today is likely running thanks to C++. The popular JavaScript runtimes are all C++. The most popular Java VMs are written in C++. Python and Ruby and Lua and so on are written in C. Some languages aim to be self-hosting, but boot-strapping them (which you'd need to do on some platforms) still generally requires C. The analogy a professor of mine had used goes something like: "Ruby or Python or JavaScript is like an elegant easy-to-drive luxury car and C++ is like an incomprehensibly complicated tank with a car factory in the back." This issue will not come up often at all (many games never have issues here), but in those rare cases when it does come up, it's easy to regret not choosing C++. You can always tack a scripting language onto C++, but it's somewhat harder (though not impossible) to plug C++ into many managed languages like C#. You won't often get backed into a corner with C++.

Learning & Career Growth

Assuming you're making a game to learn and maybe get a job (and this topic is related to Familiarity) there are a lot more resources on games programming for C++ programmers. The vast majority of "Write games in Java" books or the like are geared towards incredibly simplistic platformers and card games that don't even have the sophistication of most NES titles. You're going to have an easier time finding learning materials on how to do things - and do them right - using C++ as a base. Additionally, while there are many jobs in gaming using JavaScript or Java or Python or such, they're mostly limited to mobile/social games and not the kind of AAA titles most aspiring game developers hope to work on some day. Getting a job almost requires C++.

Good Enough

The advantages of other languages are usually given as them being easier to learn, more concise to code in, safer, and so on. However, while C++ is not at all great by any stretch of the imagination in those departments, it's not terrible. If you're a developer who already has C++ experience, there's little reason to bother switching. Other options can be better in many instances, but only somewhat, and generally not enough to be worth throwing away years of experience or expensive tools and libraries. This is less a reason to choose C++ and more a reason not to choose something else if you're already a C++ developer. It's easy to get into the habit of always wanting "the new shiny" but it often just isn't worth the hassle. This applies to languages, operating systems, libraries, tools, and so on. Use what works and only switch up when there is a very clear and concrete benefit to doing so. Choose C++ when you don't have a strong reason not to.


This topic was left last on purpose. Yes, C++ can be a good deal faster than most other languages if used properly. This almost certainly does not actually matter in practice. Even for the Big Guys, the runtime efficiency gains of C++ over Java are barely of importance. The things that kill performance in games are typically just as likely to kill performance for you in C++ as in any other language. Some languages, such as Java, do make it harder to deal with modern CPU caches on the like, but you can get by. Unless you're making the next Grand Theft Auto and targeting the last generation of consoles, you probably don't need C++ for efficiency's sake. Massively complex games on consumer hardware essentially require C++.

  • \$\begingroup\$ Very comprehensive answer, thank you. In response to Good Enough, as someone who often works in other languages, but has a pretty solid enough understanding of C++, I'm wondering if it would either help me, or language designers, to detail (elsewhere) what sort of things make me absolutely despise working in C++. Even though I acknowledge its importance and understand its workings, it seems I'm always betting against the odds by hoping people will move to a more readable language. \$\endgroup\$ – Katana314 Aug 26 '13 at 4:20
  • \$\begingroup\$ @Katana314: that list has been compiled many, many times before and can be found in a hobajillion places on the Web. Many of the ISO C++ committee members are also generally aware of C++'s short-comings and areas it could be improved (without breaking backwards-compatibility too badly, of course). Making yet another list complaining about C++ not being Python or whatever is not helpful. If you're interested in seeing C++ improve, I'd suggest reading the WG21 papers and contributing papers or proposals of your own. I have a few papers to write sitting in my task blacklog right now. :) \$\endgroup\$ – Sean Middleditch Aug 26 '13 at 20:41

The idea behind this is, that C++ can be faster.

C++ has no automatic memory management (less overhead, but potential memory leaks yay!), direct pointer access (so we can do l33t pointer manipulation to squeeze out that last bit of performance. This is simply not possible in java, since java does not allow pointer access in the first place. segfault anyone?).

C++ is statically typed language that is compiled to machine code. C# and Java are statically typed languages, that are compiled to byte code, which is interpreted /JIT-compiled by a VM. Python is dynamically typed scripting language which is interpreted at runtime.

Compiling translate the code to machine code, which is then run directly by the CPU. Byte code has to be read and executed by an interpreter. Same goes for scripting language, but since byte code is simpler and compiled at runtime performance isn't as bad as interpreting the scripting language.

In commercial games multiple languages are used. The core engine is written in C++ for performance reasons and static type checking. Some stuff even in assembler! The gameplay is written in a scripting language as lua or python, because this code isn't as performance critical and productivity/ease of development is more important. That's why scripting language are dynamically typed. Some safety is traded for flexibility which increases developer productivity. Script code, that is too slow, can still be moved to C++ later on.

So if you're asking, if you should use C++ for your own hobby game project. Don't do it. You will have to deal with a lot issues you simply won't have using Java, C# or Python. Manual memory management, inclusion guards, cryptic error messages (try using C++ templates...), artificial split between header files and source files (god why?! I know why btw.), issues like not being able to define float constants in header files (have I mentioned cryptic error messages?) etc. make C++ a pain in the a**. C++ is in my opinion a quite dated language with a lot of unnecessary cruft. Don't use it, if you don't have to.

If you're looking for a job in the games industry, I think you will have to learn to C++. But there are some hugely popular games written in other languages e.g. Minecraft (java).


At the end of the day make any game or application in any language you want that will get you the result you are looking for. If you can put together your application in C# and there is no performance limitation then there is no need to choose a 'real' language.

What you are running into are the limitations of some development environments. Java and C# are managed languages and so you do not have direct code access, its going to be run in its own little environment. C# has made huge improvements on execution speed and resource management to make it more Viable but you will find developers have a general bias against Java because of its large amount of overhead.

C/C++ is closer to the hardware but dumps a lot of the management on your own shoulders. This can let you better utilize the resources because you can specialize them to your needs as opposed to the general case environments you will find in the languages listed above.

I can not really speak to Python as I have not tried to use it to make a game, just tools and quick little scripts and the like. Overall though, the first part of this answer is the important part. A completed project always wins hands down over just debating about a project that is never completed.

Hope this helps.


That's a pretty general question. You can write games in every language. Main reasons for C++ I can think of are first of all performance (C++ is simply way more close to the hardware than many other languages). Also you have complete control over the whole application: you have to write everything for yourself, e.g. garbage collection. Also when integrating special hardware, you might often have C or C++ drivers, but no drivers for Java, for example.


When you want a: close to the hardware/operating system (without being Assembly) or low-level/non-abstracting/non-interpreted/forces-you-to-things-its-way; language.


Not the answer you're looking for? Browse other questions tagged or ask your own question.