So You Want To Be A Graphics Programmer?

Recently, a university undergraduate asked me on Twitter for advice on becoming a graphics programmer within the games industry. I wrote a fairly detailed email response and thought the information was good enough to make an article for AltDevBlogADay. This is all my personal opinion of course.

If you're at university, you should research whether there's a programme to do a summer or year long internship at a games studio. There was nothing like that when I was at the University of Liverpool '97-'00 (or I wasn't aware of it), but I've seen people come through that kind of programme with much greater practical game development knowledge and it goes a long way towards persuading an employer to take you on. EA, Lionhead and other large companies tend to run this sort of programme so look on their job pages too. Beware that sometimes companies don't respond to intern applications for various reasons (team is deep in crunch, budget spent elsewhere, etc) and places are extremely limited.

Your best bet is to make a graphics demo, either on your own or with a small group of people. You learn more by doing than by just reading. Pick a modern graphics technique that interests you and implement it. Even better, do more than one. This is also great training for motivating yourself to get a project finished which is often the hardest part of games development, for all disciplines. Make sure you're prepared to talk in detail about the choices you made, performance (in milliseconds, not frames per second!), quality, alternatives and trade offs in a job interview.

When I was in university I did a straight computer science course – there were barely any games courses available back then, but I still think that employers still value computer science graduates above games graduates as there's a perception that you learn a greater range of software engineering skills. This could be a misconception though, as games courses are a lot better than they used to be, but you may have to fight your corner in an interview and prove you know your stuff (and not just the curriculum you were taught).

Computer science courses also tend to be quite maths heavy (I would hope games courses are similar), which is vital for graphics programming. Make sure you understand homogeneous coordinates, matrix maths, dot products, cross products, quaternions, normal vectors, tangent bases, etc and how these things (and countless others) are useful for transforming and lighting geometry. Learn big O notation for algorithmic execution time, understand colour spaces, gamma correction, what high dynamic range means and so on. Learn some basic lighting models - Lambert, Phong, Blinn, etc.

Software

In my experience, Visual Studio is pretty much universal as a code IDE (except for Apple, Linux, Android and Nintendo games), though you can of course use your favourite editor if you really want to, as long as you know Visual Studio. There is a free Express edition available from Microsoft (http://www.microsoft.com/express/Windows/), so it won't cost you any money to learn. The PS3 is a little different as there is a separate hardware specific debugger, but you should be able to learn that on the job.

You should be familiar with a source control system. Perforce (www.perforce.com) is a good choice as a lot of game studios use it and it's free for single users. Try to learn it on a project with other people as merging, branching and integration are good skills to have. With all source control systems, similar concepts apply so it's essential knowledge to have. Shockingly, my university course never mentioned source control and I was naive enough to believe that people just shared code over the network or on floppy disks.

As you're unlikely to have access to devkits at home or in university, you'll most likely be learning your skills on PC. In what may come as a surprise from someone with a decade's game development experience, I don't know much OpenGL as there's never been a pressing need for me to learn it. Most PC games use DirectX, though if you learn DirectX 11, make sure you also learn DirectX 9 as it's still current for Xbox 360 and many PC games still use it to support the dwindling, but still large Windows XP market. DirectX 10 is completely superseded by DirectX 11, so it is not worth learning (you can write DirectX 11 games for DirectX 10 hardware, and even DirectX 9 hardware).

It's also definitely worth learning a graphical debugger. PIX for Windows isn't as good as the Xbox 360 version, but there are fantastic free alternatives (Intel GPA - http://software.intel.com/en-us/articles/intel-gpa/, Nvidia Parallel Nsight - http://developer.nvidia.com/nvidia-parallel-nsight). These tools are not just for performance tuning on the GPU – they're also for debugging your draw calls, working out why something doesn't draw, why it looks wrong, and so on. You can also learn about how a GPU works as you can see all the renderstates, shaders, meshes, textures, etc for any draw call in a frame and really understand what the GPU is actually doing with the data you give it.

Other Duties

As a graphics coder you'll probably have to do some tools work too, working with mesh compilers, animation compilers, plugins for Maya/3DS Max or in-house editors for the artists to use. Remember that your job is to provide technology to support the artists in their daily work, so it needs to be presented in a friendly manner. If you give your art team a tool that lets them tweak some coefficients of a fancy rendering algorithm and they have no idea what the numbers mean, they probably won't use it. Also, technical artists are your friends – they're the best people to talk about requirements for artists and to work out the best workflow for the content creators.

It's also good to learn general performance and optimisation techniques as this often falls to the graphics/engine team to do. You probably won't have to write any (or very little) raw assembler, but you ought to be familiar with what the C/C++ compiler is doing to your code, how to spot problems and what to do about them. For example, one of the biggest performance problem will be L2 cache misses (you lose hundreds of cycles per miss on all modern hardware), so learn techniques to reduce them (almost always changing the data, not the code is the fix).

Online Learning Resources

Online resources are a goldmine, and there's much better stuff out there than there was when I was at university as a lot of companies publish papers on their techniques which are pretty useful stuff. A few examples...

http://www.valvesoftware.com/company/publications.html

http://publications.dice.se

http://www.crytek.com/cryengine/presentations

Also there are a few good blogs posting regularly about graphics. A few good examples...

Lost in the Triangles. Aras Pranckevicius' blog (a lead programmer for Unity).

Real Time Rendering has good information (also the book is a worthwhile read!).

Humus. Another good graphics programming blog.

Make sure you read the relevant presentations from GDC (very useful) and SIGGRAPH (slightly less useful as a lot of it is for non-realtime graphics, but useful as a crystal ball for future techniques).

My last handy tip is that if you live near a big dev studio, find out which pub they go drinking at after work and join in on a Friday night. You'll learn a lot just chatting with developers. You can also join Twitter and talk to many games developers there who are willing to share their experience.