Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


C++ for Gaming Industry


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
20 replies to this topic

#1 thyagobr   Members   -  Reputation: 141

Like
0Likes
Like

Posted 08 March 2013 - 07:14 AM

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 =]



Sponsor:

#2 C0lumbo   Crossbones+   -  Reputation: 2405

Like
4Likes
Like

Posted 08 March 2013 - 08:09 AM

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.



#3 Yrjö P.   Crossbones+   -  Reputation: 1412

Like
0Likes
Like

Posted 08 March 2013 - 08:36 AM

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?

#4 NightCreature83   Crossbones+   -  Reputation: 2937

Like
5Likes
Like

Posted 08 March 2013 - 08:39 AM

What they mean is that you know C++ so well that you can tackle any problem with the language and understand what the performance impact of that solution is. So use reference passing instead of by value for large objects, but also what functions are called when you assign a new object to a variable.

 

Knowing additional API's is helpful as well, 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.


Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, Mad Max

#5 landagen   Members   -  Reputation: 376

Like
0Likes
Like

Posted 08 March 2013 - 08:40 AM

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. 





#6 swiftcoder   Senior Moderators   -  Reputation: 10242

Like
3Likes
Like

Posted 08 March 2013 - 10:39 AM

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.


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#7 Yrjö P.   Crossbones+   -  Reputation: 1412

Like
0Likes
Like

Posted 08 March 2013 - 11:13 AM

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... smile.png)

#8 KulSeran   Members   -  Reputation: 2567

Like
1Likes
Like

Posted 08 March 2013 - 11:26 AM

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.

#9 BGB   Crossbones+   -  Reputation: 1554

Like
0Likes
Like

Posted 08 March 2013 - 12:07 PM


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).

#10 swiftcoder   Senior Moderators   -  Reputation: 10242

Like
0Likes
Like

Posted 08 March 2013 - 12:16 PM

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.


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#11 BGB   Crossbones+   -  Reputation: 1554

Like
0Likes
Like

Posted 08 March 2013 - 12:46 PM

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, ...).

#12 ApochPiQ   Moderators   -  Reputation: 16079

Like
3Likes
Like

Posted 08 March 2013 - 01:02 PM

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.

#13 AllEightUp   Moderators   -  Reputation: 4241

Like
0Likes
Like

Posted 08 March 2013 - 01:26 PM

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.



#14 ApochPiQ   Moderators   -  Reputation: 16079

Like
0Likes
Like

Posted 08 March 2013 - 01:32 PM

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 :-)

#15 AllEightUp   Moderators   -  Reputation: 4241

Like
2Likes
Like

Posted 08 March 2013 - 01:46 PM

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

Edited by AllEightUp, 08 March 2013 - 01:52 PM.


#16 thyagobr   Members   -  Reputation: 141

Like
0Likes
Like

Posted 08 March 2013 - 01:55 PM

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.



#17 Nick Gravelyn   Members   -  Reputation: 851

Like
2Likes
Like

Posted 08 March 2013 - 02:18 PM

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, 08 March 2013 - 02:19 PM.


#18 swiftcoder   Senior Moderators   -  Reputation: 10242

Like
1Likes
Like

Posted 08 March 2013 - 02:22 PM

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.


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#19 BGB   Crossbones+   -  Reputation: 1554

Like
0Likes
Like

Posted 08 March 2013 - 03:28 PM

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.

#20 0r0d   Members   -  Reputation: 819

Like
2Likes
Like

Posted 08 March 2013 - 05:03 PM

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, 08 March 2013 - 05:05 PM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS