Why Game Studios Use C++
AKA: Why You Shouldn't
One of the most popular topics around here is what language beginners or general game-programming newbies should pick up for making games. Almost equally popular is the debate over whether or not C++ is a good language for said newcomers; there are as many minor variations in opinion on this subject as there are posters in the community, and frankly the vast majority of them are utterly wrong.
First off I'd like to address some common misconceptions and misinformation, and then I'll dig into the subject of why exactly game studios use C++ in the first place. Finally, I'll wrap up with some quick comments on why C++ is the wrong choice for your game projects.
Burning off the Bullshit: Mistruths about C++
When addressing any argument, let alone one with as much strong opinion floating around it as the subject of C++, it is vital to ensure first that all the facts are on the table, and all the non-facts are thoroughly dispensed with. To that end, I'll tackle a few areas where people have some misconceptions about the language and its application.
- C++ is really fast
This is really a non-statement. The language itself isn't fast or slow per se. Even the generally available compilers aren't a huge factor when it comes to speed, unless you're doing some really obscure stuff. For the most part, the speed (or rather lack thereof) comes from the code itself - and that is almost entirely a function of the programmer, not the programming language. It's possible to write fast code in most languages, and it's possible to write hideously slow code in all languages. In fact, given the complexity of C++ and its semantics, it's actually pretty easy to write terribly inefficient C++ code - and most people who are not highly versed in the low-level aspects of the language and toolchain will likely fall into this trap. - C++ is really powerful
This statement is a hallmark of people who have very little experience with multiple programming languages. First of all, let's ignore the red-herring Turing completeness argument (wherein we can prove that all Turing-complete languages, and therefore virtually every serious programming platform ever devised, comprise equal "power"). What most people really mean when they talk about language power is expressiveness - i.e. how close can I get to saying precisely what I want to do with code? A highly expressive language lets me say very rich, complex, subtle things with built-in code constructs. A less-expressive language might require me to write out a lot of things explicitly, or (even worse) leave a lot of assumptions implicit in the way things are structured.
I wouldn't rate myself as hugely experienced in using different languages in production environments, but I have dabbled fairly widely, and I'm working on my own contribution to the plethora of programming languages. That said, I don't find C++ to be a particularly expressive language, at least in its current incarnation (I haven't really explored C++0x in a production environment so I won't comment on that revision to the standard). I could write an entire article just on the shortcomings of C++ and its lack of expressibility, so to keep things (somewhat) brief I'll just say this: for almost any domain, there exists a language which can more closely express the goals of the programmer in native syntax than can C++.
To close off this point, I'll offer two quick examples. First, consider domain-specific platforms like Ruby on Rails. Whatever beefs you may have with Ruby in general and Rails in particular, there's no arguing that expressing a typical web application in Rails is much more natural than trying to do it in C++. Secondly, in a more games-pertinent vein, the majority of interesting code in a game is high level logic, which is best expressed in a scripting language of some kind - ideally one that can easily be tailored for the engine in question, like Lua or Python. - C++ is basically just C with some extras
This statement reflects a fundamental ignorance of both the C and C++ languages. Yes, technically C++ is (mostly) compatible with C, and most C code can be trivially converted to compile as C++. However, that's a dangerous thing for the most part, and does not in any way mean that C++ is just "C with extras."
Programming in C++ requires a fundamentally different perspective on things like library structure, resource management and ownership, separation of concerns, and even code organization versus C. To suggest that C knowledge can convert to C++ knowledge (or vice versa) is like suggesting that you can learn to ride a bicycle and therefore know how to drive a car; they both have wheels, sure, but they're very, very different animals. - C++ is just Foo Language, except for X and Y (and maybe Z)
As an extension to the C++-is-not-C argument, C++ is not any other language, either. C++ is not like Java or C# with manual memory management. C++ is not like C with classes. C++ is not like Python with curly braces. Extend this to any comparison you like.
C++ is its own language, and has its own philosophy in a number of areas. Treating it like a variant of some other language is just begging for trouble. The best way to learn C++ is to steep yourself in C++ philosophy; learn to think like C++. Anything less is folly. If you bring a Java, C#, Python, Ruby, Lisp, OCaml, or even C mindset to C++, you will inevitably do something that C++ does not like. The only way to avoid all the myriad pitfalls of C++ is to know C++ in its own right.
Why Game Studios Use C++
So if C++ is such a dangerous beast, with all these pitfalls and caveats and associated crap, why does anyone bother using it in the first place? Surely all those professionals writing C++ games know something that makes it valuable for them!
Well, yes - but a very qualified yes.
- Pushing the envelope
There are very few studios out there right now that truly push the limits of what PC games are capable of. This is slightly less true in the console space (which I'll address next) but for the most part in the PC world games are not really truly pushing the available hardware. The main reason for caring about hardware limitations for PC games has nothing to do with cutting-edge technology, but rather backwards compatibility. The older the hardware your game can run on, the larger your potential market - and that means optimizing and cutting corners to run on older stuff equals more money. Running on older hardware often means that you need to be more efficient and more clever, and that means you need to be able to express your code in concepts that are fairly close to hardware. That means C++ is a good choice for these situations. - Pushing consoles
Consoles are, generally speaking, build-once-then-throw-away hardware. They're designed to do their job for a maximum of five or six years before being replaced by a "new generation" of technology. That's the development cycle of two standard full-scale titles, if you figure on 3 years to do the first title and then 2-3 to do the second, with an average-sized team. By contrast, the life-cycle of a typical programming language toolchain is measured in decades. This means that, in a typical scenario, you want to use old and well-proven language technology when designing the SDK for your console. This means that, for a long time, C was king; and then C++ has slowly edged up on it in recent generations. In these cases, C++ isn't the best language for development on its own merits; it simply has the pedigree and years of research and development behind it to make it a cost-effective tool for deploying new console hardware. In another 2-3 cycles we may see Microsoft-powered consoles running C# on a regular basis, but for now, C++ is the dominant player. - Memory control
One other facet of console development most people don't realize is the strict memory limitations in place. For instance, the Xbox sported a whopping 64MB of system memory, and the 360 weighs in at a mere 512MB. In the PC space, this is considered painfully cramped; 2GB isn't an uncommon requirement anymore, and with 64-bit operating systems proliferating at a decent rate, chances are this limit will skyrocket in the next few years.
Consoles, however, don't have that kind of storage. That means that you have to be remarkably careful with how you store your objects in memory, or you will run out of space frighteningly fast. C++ is a winner here because it offers two key things: specific control over the layout and size of everything you put into memory, and specific control over the lifetime and ownership of everything in memory. This is a critical part of why garbage collected languages haven't really taken off in large-scale console development: they just don't have the free space to work efficiently. Garbage collectors are an abstracted simulation of a machine with infinite memory; this runs perfectly counter to the goal of writing code that is designed to work in minimal memory.
What, that's it?! Only three major reasons to use C++ for major game development studios? Surely there's more to it!
Not really.
C++ is a hulking piece of shit of a language. It's full of weird corner cases, obscure semantics, nasty gotchas, and tricky bits of implicit logic that you have to be deeply familiar with to handle properly in production scenarios. No language is free of its dark corners, of course, but C++ is chock full of them - and they are responsible for a huge amount of time burned on developing the average game title.
Unless you are truly pushing new hardware, or trying to maximize the potential of fairly old hardware, you don't need the raw low-level potential of C++. If you aren't on a console with highly limited memory space, you don't need the exquisitely precise memory control semantics of C++. In general, you don't need C++, and you don't want C++ because much better tools for the job exist, and are plentiful, easy to use, and often free.
Why C++ is the wrong choice for your game
At this point I'm tired, a little buzzed, and feeling pretty lazy, so I'll gloss through these points quickly.
- Better languages exist. You can be more productive, work at a higher level, and be more expressive using tools besides C++. This should be enough of a motivation all on its own.
- Supporting new languages - by using them - will encourage further future development of such languages and toolchains. If everyone stays with C++, there's no market demand to do anything better, and that means we'll likely be stuck with C++ forever. Using alternatives helps promote the idea that we can improve on what exists.
- You aren't pushing the technical limits of modern PC hardware, and you aren't writing a console game that needs to fit into strict memory constraints. If you were, you'd already (hopefully) be knowledgeable enough to know that my advice is not absolute truth.
- You don't need to know C++ to work for major studios. In fact, you can get by with just scripting language experience, or solid programming understanding in general. There are plenty of positions available for people who just want to do tools, or game logic, or other high-level functionality who don't need to know C++ in depth. You can learn on the job - which is usually a better approach anyways, because you can be mentored by someone who is familiar with all the nastiness of C++, and can steer you around the bulk of the land mines.
So there you have it. Go forth, and quit using C++. Also, quit preaching it as a reasonable choice for beginners. Thank you.
