# C++ for Gaming Industry

This topic is 1778 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi guys.

I'd like to pose a question for people who've been around for a while. I decided to guide my studies checking hiring requirements of gaming companies. When I didn't know whether to go with C++, Java, Unity or the HTML5 Stack (HTML5, CSS3 and JavaScript), I checked job offers and noticed the most promising ones were C++-related. So I'm going with C++.

The thing is: what do they mean with "C++"? Core? Is there something intrinsic to that sentence, like OpenGL, SDL, SFML (which seems to be built on top of OpenGL), ...? I'm currently studying SFML, but I have no idea if it's industry-accepted, so I just might be wasting my time. So, I ask: should I direct my studies to something specific, or all that is needed is core C++...?

Thanks everyone =]

##### Share on other sites

I doubt that SFML is particularly widely used in the games industry since most companies will either buy or develop an engine with cross-platform functionality that includes consoles/mobiles, etc. That's not a negative though, use SFML or SDL for your demos and experiments so you can get on with the interesting stuff instead of messing around with awkward platform functionality.

That said a familiarity with OpenGL and/or Direct3D will probably be considered a plus from a new hire. Looking briefly at SFML it seems you can choose to use their abstracted 2D graphics calls, or just use SFML to handle the windowing and use OpenGL calls direct. I'd recommend you do the latter.

##### Share on other sites
What C0lumbo said. SFML or SDL are not industry relevant tech in themselves, but they get you up to speed a ton faster than building everything yourself from the ground up. When you have something (anything) that is a working whole, you can then iterate on it and add more tech.

If you aim at a graphics programmer position, you'll eventually need to know intimately how to output stuff with OpenGL or Direct3D. But even then there's no need to start there. For instance, building stuff like proper collision and physics will teach you a lot of math and algorithms you'll also need for high-end graphics.

Where are you starting from in terms of skills and experience? What (live) programming education do you have access to?

##### Share on other sites

I would think core is referring to the most commonly used libraries and understanding the language itself.  So that would be operator overloading, pointers, memory management techniques, by reference, value, pointer, const correctness, functors, stl, OpenGL, DirectX, multi-threading including semaphores and critical sections, IO (files and sockets), OO, etc.  The list I am sure is much longer.  Make your own game and then to have a good idea of the kinds of things needed to program a game you might want to look at some open source projects code such as irrlicht and make sure you pay attention to the details.  For instance, pay attention the constructors.  what does it mean to have MyClass(MyClass& aClass); as a constructor.

##### Share on other sites

to have a good idea of the kinds of things needed to program a game you might want to look at some open source projects code such as irrlicht

Only if you are looking at it for the humour value.

There is very little code in IrrLicht (and the same goes for many similar projects) of a quality to exist in a production codebase.

##### Share on other sites

For instance, pay attention the constructors. what does it mean to have MyClass(MyClass& aClass); as a constructor.

If this is an unfamiliar construct for someone, I think they need to finish their beginners' C++ book instead of digging through open-source game engine code. (And why no const? Looks likely to be a design error... )

##### Share on other sites

the ability to know how to program and use C++ however is far more appreciated then knowing one particular API, unless the job advert asks for it of course. What we want is a programmer that can be productive nearly immediately from the day he starts, of course you will have to learn how to use the codebase but we will not teach you how to use C++ at the same time though.

I really want to emphasize this. It doesn't matter what language you're playing with at home, or what APIs you're learning. You're not going into a job knowing enough to do anything. Even if you've got all of OpenGL's API memorized, it still can be used in a multitude of ways, and every team will have their own encapsulation layer ontop of it so that everyone can think in "Animated Art Asset" instead of VBOs and whatnot.

Learn to program. Learn the concepts. Learn how to look things up. Don't waste your time memorizing the complete syntax of a language and all the API functions it provides. If you know what a hash-map is, you can Google for the canonical implementation API for any language out there, and most IDEs will then fill you in on what the exact functions it provides are.

##### Share on other sites

to have a good idea of the kinds of things needed to program a game you might want to look at some open source projects code such as irrlicht

Only if you are looking at it for the humour value.

There is very little code in IrrLicht (and the same goes for many similar projects) of a quality to exist in a production codebase.

could be. (just writing in general, not actually seen the code for Irrlicht)

I have before made the observation that in many cases, the smaller and more narrowly defined the scope is for a project, often the worse the code is (on average).

granted, I have seen a few exceptions here (a few large projects with some fairly nasty code, and a few small libraries with reasonably clean code). I hesitate to get more specific, as it is possible that code quality/cleanliness is largely a matter of personal or community taste.

some people claim it should be the other around (say, smaller projects being cleaner due to the developers being able to focus more polishing effort on a lot less code, vs developers being spread more thin for a larger project), but this doesn't really seem to match my general experience (at least for the sorts of codebases I have seen).

##### Share on other sites

It doesn't have much to do with the size of the codebase - it's a matter of the experience and calibre of the developers involved.

Did they establish a coding style? Did they establish a testing methodology? Did they provide adequate documentation? Have they performed profile-guided optimisation? Did they produce a comprehensive threat model?

These may not be the fun parts of 'programming', but when a company advertises a position for a 'C++ developer', they are looking for all of the above.

##### Share on other sites

It doesn't have much to do with the size of the codebase - it's a matter of the experience and calibre of the developers involved.

Did they establish a coding style? Did they establish a testing methodology? Did they provide adequate documentation? Have they performed profile-guided optimisation? Did they produce a comprehensive threat model?

These may not be the fun parts of 'programming', but when a company advertises a position for a 'C++ developer', they are looking for all of the above.

well, just observations, don't know all the specific reasons.

don't know as much about companies here, but more experience looking at FOSS stuff, and have often seen patterns like:
"lib<somefileformat>" or "lib<sometrivialtask>" as often having fairly hackish/poor code (exceptions partly being ones like "libjpeg" which are at least "much better than average").

then quality seems to generally go up along with code-size (like, better maintenance of conventions and abstractions, ...).

but, then sometimes there are large projects (notably some of the ones within the GNOME project), which seem to have some pretty poor coding practices (often code is written without a consistent style or maintaining abstractions, ...).

this is in strong contrast with, say, LLVM, which overall looks pretty clean (albeit sometimes slightly odd IMHO, looking almost Java-like at times), ... V8 also looked fairly good here. though, I didn't exactly look over all of the code in these projects.

despite some funkiness, also Mozilla looked pretty good overall (at least in the parts I looked at).

related is Quake 1 vs 2 vs 3 vs Doom 3, where in each case, the code got bigger, and also seemed to often generally get cleaner (though harder to directly compare Doom3 to its predecessors, due to being in a different language and apparently largely a rewrite of the engine).

of course, others may disagree or see it all as possibly unrelated (or I may be wrong due to only seeing small parts of the code in many of these projects, ...).

##### Share on other sites
The correlation between project size and code quality is dubious at best. In many of your examples, the large projects are only possible because the developers involved are already experienced and disciplined.

For id's engines, the code improves because the developers improve. The size of the project is enabled by code quality; code quality does not necessarily arise as a result of having lots of code.

As a strong counterexample, I've seen plenty of codebases shrink and improve in quality simultaneously. I plan on deleting a bunch of code today, in fact.

##### Share on other sites

Something to keep in mind is that a lot of folks always seem to equate graphics as "game programming" which is a very poor comparison.  A game like Doom is "mostly" a graphics engine with little gameplay but many/most non FPS games have considerably more actual game than simply graphics to them.  What this generally means to most programmers is that the graphics specific positions are typically few and far between.  What is most commonly meant by "C++" is understanding enough of the language and the available tools to not cause "problems" when you start working with people and being able to clean up your own messes.

Programming itself is not "that" language specific, knowing your data structures, general constructs and how to put them together are the most important bits.  What the C++ bit usually suggests is really more about being able to understand what you read, how to avoid causing problems and of course debugging.  Some of the silly questions you might see during an interview:

int DoSomething( std::vector< int > data )
{
int avg = 0;
for( std::vector< int >::iterator i = data.begin(); i!=data.end(); ++i )
{
avg += *i;
}

return avg / data.size();
}


There are a slew of problems with that code, naming at least 3 would be a good start, 5 would be better and of course knowing when/where exceptions to some of the things you find in the above would not matter so much.

Parsing that at a glance and just "knowing" most of the problems without really thinking about it, that's what is usually considered knowing "C++".  This is just one silly example, though I've seen many variations of this sort of "function of badness" you are supposed to fix during an interview.

##### Share on other sites
How did you come up with your number of things "broken" in that code? I'm just curious if my tally agrees with your tally :-)

##### Share on other sites

How did you come up with your number of things "broken" in that code? I'm just curious if my tally agrees with your tally :-)

Hehe, mostly just wrote it and figured those were good numbers given what I could see without really looking at it much.. :-)

[spoiler]

int DoSomething( std::vector< int > data )

^^ is this really an integer average?

^^ copy, ewww..

^^ non-const, can't be called by const functions, why not?
{
int avg = 0;

^^ what about overflow?  if the numbers are all small, fine, what about big numbers?

for( std::vector< int >::iterator i = data.begin(); i!=data.end(); ++i )

^^ have had issues with some compilers not optimizing

the "end" call and always performing end-start per loop.

Move to an initializer.
{
avg += *i;
}

return avg / data.size();

^^ divide by zero possible.
}

[/spoiler]

Edited by Hiwas

##### Share on other sites

The process is actually  being harder than I would hope to. I'm a graduated Software Developer, but the entire course used Java to represent our studies (i.e. translating pseudo-codes from Algorithm classes to computer, to code data structures, and so forth). The down side is that, after 3 years, I was pretty good at Java only (for language experience); the up-side is that we had good teachings for the theories of programming, so it's not hard, as all of you probably know, to grasp a new language and learn it. But the sintax does change, and C/C++ is being specially complicated. Maybe (ahem...I'm pretty sure about this) it's so hard 'cuz I'm trying to learn, at once, how to: program in C++, use SFML and game programming techniques. Don't know. But today, I found myself wondering "what if I go through all this hard work and end up with nothing?".

Anyways, thanks everyone for the input, it's been invaluable for the continuation of my studies.

##### Share on other sites

I'd toss out that C# can be a good language for studios. Lots of C# used for tools, build systems, etc. You may not be directly engineering the game, but while on a tools/pipeline team you can learn a lot about the studio, the code, and build familiarity/skills over time that will enable you to move into a different engineering role if you want.

I'd also mention that Unity is becoming more prevalent of an engine which uses C# for scripting (technically also UnityScript and Boo). It's obviously not taking over the AAA spectrum yet, but a decent number of companies are starting to use it and I expect that number will continue to rise.

And lastly, in my experience, the really hard core C++ needs are deep engine work. Many studios (especially as you get away from the smaller ones) have dedicated engine teams leaving many of the remaining devs to write higher level concepts. Even if you're still in C++ and not some scripting language (some studios break out Lua or another language for scripting) the requirement of knowing the nitty-gritty C++ stuff starts to loosen as you're writing more game-specific code (so you don't have to have a general solution that works for 100% of scenarios) that can start being less performance critical (such as simple UI backing logic).

Everyone starts somewhere and it usually isn't the role of most knowledgeable C++ engineer in the company. You need to learn enough C++ to be competent and show an aptitude for quickly learning new skills. That's what I'd recommend, anyway.

Edited by Nick Gravelyn

##### Share on other sites

You need to learn enough C++ to be competent and show an aptitude for quickly learning new skills.

QFE.

Companies tend to pretty much assume that your first few months of employment will be spent unlearning all the tripe you learned in university. Which means that if you want to land a job with '4 years C++ experience' right out of college, you are going to have to work at it.

##### Share on other sites

The correlation between project size and code quality is dubious at best. In many of your examples, the large projects are only possible because the developers involved are already experienced and disciplined.

For id's engines, the code improves because the developers improve. The size of the project is enabled by code quality; code quality does not necessarily arise as a result of having lots of code.

As a strong counterexample, I've seen plenty of codebases shrink and improve in quality simultaneously. I plan on deleting a bunch of code today, in fact.

yeah, this makes sense.

wasn't claiming here that there was a causal relationship between them, just that when wandering around and looking at stuff, a pattern was often being seen.

but, yeah, simplification and similar can be a good thing as well sometimes.

##### Share on other sites

Hi guys.

I'd like to pose a question for people who've been around for a while. I decided to guide my studies checking hiring requirements of gaming companies. When I didn't know whether to go with C++, Java, Unity or the HTML5 Stack (HTML5, CSS3 and JavaScript), I checked job offers and noticed the most promising ones were C++-related. So I'm going with C++.

The thing is: what do they mean with "C++"? Core? Is there something intrinsic to that sentence, like OpenGL, SDL, SFML (which seems to be built on top of OpenGL), ...? I'm currently studying SFML, but I have no idea if it's industry-accepted, so I just might be wasting my time. So, I ask: should I direct my studies to something specific, or all that is needed is core C++...?

Thanks everyone =]

I can tell you, as someone who has interviewed many people for junior to senior to tech director positions in game studios, the least you need for a junior position is a pretty solid knowledge of C++ and decent math and problem solving skills.  You can forget Java and HTML5 and all that stuff.  Unless you're applying for a position that specifically uses those, what you need is C++.

If you're aiming more for a graphics programmer position, then you need to step up your math, hardware, and graphics API knowledge.  You should have really good 3D math, experience with either OpenGL or DirectX, experience with shaders would be welcome, and preferably be able to discuss previous work (formal or hobby) you've done relating to game-relevant graphics techniques.  And that's just for an entry level graphics programmer position.  For a senior position you should throw in at least 4 - 6 years experience and a few shipped titles, hopefully at least one a AAA game.

But, even for a non-graphics gameplay programmer position, you still need a solid grasp of C++, how the hardware works and interprets your code, and 3D math and basic algorithms and logical problem solving.  Knowledge of tools such as Unity are nice because the studio might be using something similar (either 3rd party or in-house), but it's the low-level stuff that will matter most because they can teach you the tools later, but they cant teach you C++ or math.

Edited by 0r0d

##### Share on other sites

Hi guys.

I'd like to pose a question for people who've been around for a while. I decided to guide my studies checking hiring requirements of gaming companies. When I didn't know whether to go with C++, Java, Unity or the HTML5 Stack (HTML5, CSS3 and JavaScript), I checked job offers and noticed the most promising ones were C++-related. So I'm going with C++.

The thing is: what do they mean with "C++"? Core? Is there something intrinsic to that sentence, like OpenGL, SDL, SFML (which seems to be built on top of OpenGL), ...? I'm currently studying SFML, but I have no idea if it's industry-accepted, so I just might be wasting my time. So, I ask: should I direct my studies to something specific, or all that is needed is core C++...?

Thanks everyone =]

I can tell you, as someone who has interviewed many people for junior to senior to tech director positions in game studios, the least you need for a junior position is a pretty solid knowledge of C++ and decent math and problem solving skills.  You can forget Java and HTML5 and all that stuff.  Unless you're applying for a position that specifically uses those, what you need is C++.

If you're aiming more for a graphics programmer position, then you need to step up your math, hardware, and graphics API knowledge.  You should have really good 3D math, experience with either OpenGL or DirectX, experience with shaders would be welcome, and preferably be able to discuss previous work (formal or hobby) you've done relating to game-relevant graphics techniques.  And that's just for an entry level graphics programmer position.  For a senior position you should throw in at least 4 - 6 years experience and a few shipped titles, hopefully at least one a AAA game.

But, even for a non-graphics gameplay programmer position, you still need a solid grasp of C++, how the hardware works and interprets your code, and 3D math and basic algorithms and logical problem solving.  Knowledge of tools such as Unity are nice because the studio might be using something similar (either 3rd party or in-house), but it's the low-level stuff that will matter most because they can teach you the tools later, but they cant teach you C++ or math.

I both agree and disagree with this overview.  I totally agree with the math requirement, without basic math and preferably decent vector math/geometry, you are not a game programmer, you are a web dev, db guy or something not really involved with the "game" itself since games "are" basically math at all levels.  You can't hope to write anything game related without a basic understanding of vector space and to be good you need to know it pretty damned intuitively.  (I.e. close your eyes and "see" the geometry, now convert that to math.)

On the other hand, I don't agree with most of the other stuff completely.  When it comes to junior and even sometimes mid level programming I don't look for C++ specifically which seems at odds with your description.  Actually, I usually ignore all "education" background as meaningless to my hiring points for juniors.  I'm more interested in the hobbies, are any programming related?  Are they active in places such as this?  I.e. is this just a job or something they really are interested in?

I know, I'm probably not common in this view of hiring but I've never had to fire a person I've hired with those "desire" based goals.  I "have" fired way too many "it's just a job" I went to college to do types unfortunately.  I know others with the same view of things, but yes, it is unusual I suppose.  Unfortunately over 20 years, desire usually trumps education because those with desire will "learn" and keep on learning.  The others are making bank software or digging ditches somewhere.