What do AAA game developers use?

Started by
3 comments, last by Buster2000 10 years, 3 months ago

A little background... I am a mobile game developer and I dream of being part of a AAA gamedev team someday. So my concern is this; What do I need to learn to be capable of breaking into the AAA side of gamedev? Let's say I want to be a Gameplay Programmer.

My specific questions to AAA game developers out there are these:

1. What languages do you use?

2. What game engines do you use?

3. Do you still code using low-level graphics API like Direct3d/openGL (how frequent?) or just use a high-level game engine for that?

4. Some more insights are welcome.

I'm in the phase where I ask myself, "What should I learn next to prepare myself for AAA?"

A little more background... I am proficient in C/C++, C#, Java, Objective-C. And right now, game engines I use are cocos2d and Unity3d.

Advertisement

My specific questions to AAA game developers out there are these:

1. What languages do you use?

2. What game engines do you use?

3. Do you still code using low-level graphics API like Direct3d/openGL (how frequent?) or just use a high-level game engine for that?

4. Some more insights are welcome.

1. Predominantly C++. You will likely also work with C#, Python and Perl, probably some Java, some shell scripts, and scripting languages. This is not universal, some games are written in other languages; you may be expected to spend your days in Java, or ActionScript (Flash), or C#, or Lua, or Boo, or other languages.

2. Predominantly in-house developed engines. Some companies rely on engines like Unity, UTK, C4, and others, but they are the exception.

3. Gameplay programmers do not typically touch the graphics. Entry level programmers also do not typically touch the graphics. Don't worry about it for breaking in.

4. An entry level worker or a recent college graduate is seen as a beginner in the craft. They know just barely enough to potentially be a net positive, but employers know entry level workers will need a lot of hand-holding, a lot of code reviews, and a lot of guidance. It is quite common for beginners to think they know everything, but fun to watch as they flounder and struggle to keep up with those around them, ultimately realizing that even if they were the top of their class they still have a long way to go before becoming industry veterans.

Frob's covered most things. I'd also say that:

1) Regardless of what's used, try to practice learning new languages. On the job, you may be required to use languages that you have little or no experience with, and start being productive quickly.
On the job I've been tasked with writing Lua or C# or UnrealScript code, despite not knowing much or anything about them -- having practice in using unknown languages is actually a skill, letting you learn new ones in the future more quickly.

Same with any programming tools - expose yourself to OO, procedural, functional, etc paradigms, use different APIs, try writing some web stuff as well as desktop and mobile, etc, etc - practice learning new tech.

2) In my career I've used Unreal, Mark6(proprietary), Gamebryo, Merkury2(proprietary), Merkury3(proprietary), Kadmium(proprietary), a proprietary fork of PhyreEngine, and Eight(proprietary).
That fits with what Frob was saying about a few places using the big popular engines, and many using their own internal tech.

3) a few people inside the engine team will work with D3D, GL and the specific APIs for each console.
That goes back to point 1 of learning how to learn new APIs - say you want to be a graphics guy and you've learned D3D and GL already, then you should be able to say "ok, I know 2 ways a graphics API can look like, I know how to implement the same concepts in both, learning a 3rd way will be easy" ;)
Outside of the engine team, if the game team themselves are doing graphics programming, they will very likely use a wrapper API provided by the engine.

I was lucky to get an entry-level "special effects programmer" job as part of a Wii game team, which involved graphics programming via their proprietary engine. The Wii version of the engine wasn't very good (engine team kept saying "that can't be done" in response to the tasks I was being given), so I ended up using the raw Wii GX API as well, but this was very out of the ordinary (and got me a promotion because I wasn't actually entry-level, with years of prior experience :-P).


3. Gameplay programmers do not typically touch the graphics. Entry level programmers also do not typically touch the graphics. Don't worry about it for breaking in.

I've known entry level programmers to get thrown in at the deep end, depending on the studio ;)


frob, on 20 Jan 2014 - 9:52 PM, said:


3. Gameplay programmers do not typically touch the graphics. Entry level programmers also do not typically touch the graphics. Don't worry about it for breaking in.



I've known entry level programmers to get thrown in at the deep end, depending on the studio ;)

A lot of larger studios I know stick the graduates in the R&D department so that their first experience is tinkering with the low level nut and bolts of the games engine. So yes they could quite easily be tinkering with the graphics engine.

This topic is closed to new replies.

Advertisement