Jump to content

  • Log In with Google      Sign In   
  • Create Account






Yayy, ranting about languages!

Posted by ApochPiQ, 14 August 2010 · 204 views

Disclaimer: I'm two rum-and-cokes (heavy on the rum) into the evening, and working through a triple Jameson as I write this. Expect lots of vitriol, some unpleasant language, and some very informative and honest information about the real world.


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.




Nice post, Mike
Nice post indeed and I agree with it as well...

Now, where did I put my C++ particle system [wink]
I always find these types of posts to be somewhat difficult to agree or disagree with. The choice of a language is usually made for you - for example, if you want to use D3D11 then you either use C++ or some wrapper around it (like SlimDX). Since the primary development language for games is currently C++, the deck is stacked toward using it. Open source projects and libraries are very widely written in C++, so choosing another language is somewhat taking a step back IMHO.

But of course, several of your points are also very valid - its much easier to corrupt memory in C++ than in something like Python or C#. And sure, if you are a beginner then this is a detail that might be beyond your knowledge level. But do you really know anyone that learned Java first and then moved to C++? I think learning to program without memory management is potentially a bad idea - if you struggle through it the first time then moving to a managed language is much easier...

I guess it depends on what the beginner's motivation is. If they want to get a game made only, then they should use something like Unity - minimal programming required. But if they want to learn how to program, why not use C++? Its harder, but that makes you be careful - that is how you become a good programmer!

This is just my two cents - thanks for the writeup and the insights. As a indie/hobbyist, I don't know what goes on inside the development studios...
That's a huge part of why I suggest that new projects should not use C++, as I briefly mentioned in the post. The more we use alternatives, and register with Them What Matter that we don't want to use C++ necessarily for everything, the better chance there is for support for improved tools in the future.

Microsoft, IBM, Google, Intel, and a few other major players have all indicated that they're willing to chip in and help new toolchains gain popularity and success - provided that there's a decent market incentive for them to do so. Having a large client base is exactly that incentive. If we let ourselves, we'll be stuck with C++ until the heat death of the universe; but I truly think that if we play our cards right as developers, we can swing the tide towards tools that don't suck.
One other benefit you glossed over, that matters for professional game studios.
C or C++ gives you a relatively well known way to target a diverse set of platforms with a single engine core.

For people starting out, I doubt your going to be simultaneously targeting 360/Wii/PS3/PC/Mac out of the gate, and if you need to be, you should be looking at an existing system you can buy (for very reasonable prices) like Unity or Torque.

Hell I recently ported my personal game projects over to Java and LWJGL and off C++. :)
See, I'd consider portability to be a non-argument, along the lines of the stuff in the first section. Things that really matter for performance etc. are, generally speaking, platform-dependent - which means that the stuff that really needs to be in C++ is going to have to be rewritten during the porting process anyways.

Everything else should ideally be written in a higher-level language, like Lua or whatnot. And that gets you true portability for free.
Nice summary.
Quote:
Original post by Jason Z
But do you really know anyone that learned Java first and then moved to C++? I think learning to program without memory management is potentially a bad idea - if you struggle through it the first time then moving to a managed language is much easier...


Personally, started with ZX Spectrum BASIC when I was a kid. Obviously wan't too involved with the under-the-hood stuff there.

Have to say that when I started working with C and then later C++, the fundamentals of variables, expressions, subroutines etc were probably the reason I was able to get to a point where I could start learning about the more technical points of using the language.

Anyway, very nice journal entry although I'm not sure if I agree. Problem with all this is the same as the problem we have with operating systems. In the old DOS days, you had to develop a certain amount of understanding in order to use your computer whereas with easier and easier OS's, you need less of an understanding. This is great for making computers accessible. It is also great when things are going right, but these days when things go wrong, people are far less able to figure them out.
Quote:
Original post by ApochPiQ
Everything else should ideally be written in a higher-level language, like Lua or whatnot. And that gets you true portability for free.

Sorry to disagree again, but Lua by itself is portable for free. Once you hook it into C++ with your engine/game functionality, then it becomes platform dependant once again - you need to port the individual interfaces to the target platforms...

So what type of languages would you suggest as an alternative to C++? For general development (i.e. all parts of an engine and game) would you suggest Java or one of its classmates?
Quote:
Original post by Jason Z
Sorry to disagree again, but Lua by itself is portable for free. Once you hook it into C++ with your engine/game functionality, then it becomes platform dependant once again - you need to port the individual interfaces to the target platforms...

So what type of languages would you suggest as an alternative to C++? For general development (i.e. all parts of an engine and game) would you suggest Java or one of its classmates?


No worries - disagreement is a fundamental element of learning [smile]

I wouldn't personally say that the Lua-C++ bindings are a big deal. Honestly, if you wrote your engine in a half-decent way, it should have an interface that is largely (or entirely) platform-independent by itself, which means the bindings to Lua (or whatever other language you might use) shouldn't really change across platforms. Certainly in my cross-platform game development experience this has been the case. Either way, bindings into scripting languages are so trivially easy that porting this stuff is like a day's work, tops. I'd consider it a non-issue.


As for language alternatives... it really depends a lot on the game you want to make and the platforms you want to target. For anything mobile Java and OpenGL|ES are big winners in my book. XNA is another major winner, especially with Xbox Live Arcade on the scene; again with the caveat that you won't be maxing out the console, it's a heck of a capable platform by itself, and certainly far better suited to rapid development than is C++. The web is loaded with Flash/ActionScript stuff, and while I don't have any personal experience in that arena, from what I understand it's a pretty pleasant place to work. Short of that... I honestly think fewer people should develop engines and more people should utilize the stuff that's already out there. Unity is pretty awesome, for instance.
Quote:
Original post by ApochPiQ
Quote:
Original post by Jason Z
Sorry to disagree again, but Lua by itself is portable for free. Once you hook it into C++ with your engine/game functionality, then it becomes platform dependant once again - you need to port the individual interfaces to the target platforms...

So what type of languages would you suggest as an alternative to C++? For general development (i.e. all parts of an engine and game) would you suggest Java or one of its classmates?


No worries - disagreement is a fundamental element of learning [smile]

I wouldn't personally say that the Lua-C++ bindings are a big deal. Honestly, if you wrote your engine in a half-decent way, it should have an interface that is largely (or entirely) platform-independent by itself, which means the bindings to Lua (or whatever other language you might use) shouldn't really change across platforms. Certainly in my cross-platform game development experience this has been the case. Either way, bindings into scripting languages are so trivially easy that porting this stuff is like a day's work, tops. I'd consider it a non-issue.

I actually mean the stuff behind the interfaces - Lua code calls C/C++ functions which must be implemented for each platform, which is the big cost for cross platform development. Pure Lua, as used in game logic or whatever, is portable - but so is C++. I'm just saying, unless you make the whole engine in a completely portable language then you have the same troubles that C++ has...

Regarding the language, the problem is that there isn't something universal enough to dislodge C++. I think the MS platforms will be sticking with the Silverlight / .Net / XNA combo for its mobile/XBLA platforms, but there is no way that Sony or Nintendo would go that route... I think there will never be a replacement for C++, but rather smaller groups of development in specific areas that can wander away to other languages. Just like you mentioned - there are several languages floating around that are good for particular platforms.

So I think we agree on at least that point [grin]!

First post in a long time, but this article made me smile :0)
I agree that C++ sucks. But I disagree with all the rest. How about the most important argument that most serious game engines and libraries like for sound, physics and everything are for C++?

I'd also love to see what languages, libraries and technologies do you recommend for beginner and intermediate game programmers instead of C++?
I disagree pretty significantly, then again I'm not a computer scientist and I rarely concern myself with the complexities of language design and whatnot (I'm a hardware guy by training).

C++ is an odd language with many eccentricities -- keep it mind it wasn't designed at all around the same lines as most others in its class (no pun intended... that would be a terrible joke). For example (as compared to Java) C++ is not supposed to be an object oriented language, but rather a language in which object orientation is possible. It is a language of choices, not necessarily of strict rules (though there are certainly plenty of those). Another thing is that a lot of the areas where things get weird is kind of on the periphery, where people didn't really travel very much in the early days. I can hardly think of "metaprogramming" without resisting a certain urge to vomit (figuratively, of course).

Ultimately, what language one uses is a matter of personal opinion and choice (this varies, of course, depending on what kind of company you work at or if you work on your own, etc). Just like there are programming and commenting style are generally things each programmer needs to develop for themselves (though there are certain conventions which are good to follow), each programmer will like or dislike different languages as applied to their own activities. No point in arguing "C++ sucks" or "Java sucks" or "C# sucks" or what have you, since there are no reasonable objective means to make that designation.
Quote:
Original post by medevilenemy
No point in arguing "C++ sucks" or "Java sucks" or "C# sucks" or what have you, since there are no reasonable objective means to make that designation.


Except there are clear objective metrics one can take with regards to programming languages.

There's rarely going to be something that is clear cut better than another for all situations for all people, but I would be surprised if C++ wasn't clearly worse in many metrics for the majority of programmers doing the majority of programming tasks as compared to the majority of other programming languages.

That's far too long to say in web forums every time, so "C++ sucks" is good enough.

Nice post. I agree with most of it but I think there should be a couple of points added to "why game companies use c++"

The biggest reason IMHO is because they already have an incredible amount of existing code already written. It would be infeasible to rewrite all that code in another language.

The second point is very much related to the first. Most existing game development API's for graphics, physics, sound and so on are written in C++. This leads to 2 scenario's. Either the game engine also has to be written in C++ or some kind of wrappers for another lanuage have to be written (probably also in c++). I've experienced this first hand because I use C# to develop my games, but I've still had to spend a significant amount of time in C++ writing wrappers.

The last point I'd like to make is that most modern game engines don't use C++ for game logic. This has already been mentioned to some degree but I'd like to bring it up again because I think it's important to realise that if your developing a game of any significant size you'll find most of the work won't be using C++ anyway.

The approach I've taken in my game development is to keep the core systems in C++ and write the rest of the engine in C#. This is really not much different to how a game engine works that uses a scripting language such as python or Lua. I've just chosen to shift more of the code into a higher level language for rapid development.

Yeah that's an awesome rant and I have to agree with you totally. Some will disagree with you but that's going to happen unless you expand every point out by 1000 pages to take into account the origins of their counter arguements.

ie. C++ *is* like Java and C# to most people because it uses the same or extremely similar keywords and syntax. Most people saying this don't care about the traps and pitfalls of programming in the differing languages when they say this, merely that the code looks the same ie. "int j;" and "for (int i = 0; i < 100; i++)" in C, C++ and C#. That's good enough to most people.

I hated trying to learn C++ because I don't want to write engines, I want to write games, so XNA and Unity 3D are the best choice for me. I get to do high level C# coding and some other poor sod gets to write the engine code that lets me do what I want. I think a lot of people who say C++ is best have odd dreams of writing their own engines with vague ideas about writing a game well after their engine is mature and capable (ie 20 years from now). I remember being like that for a little while. Now I just make games.
Writing template classes is the bomb. ;) I have a love hate thing with C++, but the love part is somewhat greater, otherwise I would not be able to tolerate developing under it.

August 2014 »

S M T W T F S
     12
3456789
10111213141516
17181920212223
242526 27 282930
31      
PARTNERS