fragmentbuffer
fragmentbuffer
programming, games, graphics, etc.
fragmentbuffer
fragmentbuffer
programming, games, graphics, etc.
At least once a month I see the same question pop up on various programming forums I visit – “How do I get into the games industry?”, or a variation such as “What language should I learn?”, or “What should I do in college?”. Sometimes I try and answer, but I invariably find myself writing the same bits 
of advice and yet never have the time to go into the detail that I want to. This is my attempt to make up for that.
Of course there’s no one right answer to any of these questions. It depends on your goals, your experience level, and a multitude of other things. If you’re just looking to dip your toes in the water and make some games for fun, the good news is that it’s never been easier to just dive in and start making them – just check out Unity, Unreal Engine 4, Gamemaker, Stencyl etc. Hell, there are still awesome games being made in Flash.
But that’s not what I’m here to talk about. I’m writing this post for the people I see as the future backbone of the mainstream games industry. You might not know how to program, yet have dreams of working on the Big Games at places like Ubisoft, Valve, Naughty Dog, DICE etc. But you don’t know how to get there, or what to do next. In short, I’m writing this for me twenty years ago.
A common first question is which degree to do in college – straight Computer Science, or one geared more towards games? Of course these aren’t the only choices; I’ve known plenty of great game programmers that did Maths, Physics, Engineering or other degrees. But given a choice between the two, in almost all cases I would advocate Computer Science.
The curriculum for a dedicated games degree can be very enticing to the prospective student, especially compared to what might be a fairly dry CS one. However, too often games degrees will attempt to cover all the bases and teach every aspect of game programming, from networking to graphics to sound. As a result the students end up with a good flavour of every subject but no in-depth understanding of any single one, and at the expense of spending more time on the fundamentals.
Employers take graduates as investments – they’re not going to expect them to be experts in any area, but they absolutely must have a rock-solid grasp of the core concepts of programming and software design. Additionally, the majority of game programming jobs are for specific domains we’ll look at below, and potential employers will often prefer deep specialized knowledge to the broad general kind. CS degrees are generally structured to meet both these requirements – a solid understanding of computing and programming is built up, and only in the final year does the student specialize in one or two areas.
The other thing to keep in mind if considering a game-specific degree is the industry experience of the lecturers. The strength of a game degree is directly tied to how relevant its curriculum is to game development. If it’s designed by academics, their idea of what is applicable to games might differ substantially from reality (UML diagrams, I’m looking at you). Make sure the degree has at least been designed in collaboration with the industry, or preferably that the lecturers have direct experience themselves.
Of course there are some good game-specific degrees, and some poor CS ones. Each must be considered on their own merit. A college degree isn’t even a strict requirement – I’ve worked with some amazingly talented programmers who were largely self-taught. However given two candidates for a job, the one with the college qualification is less likely to have gaps in their knowledge, and so will be a more appealing hire. But either way it’s the talent of the individual and the work they put into their study (and their spare time) that’s going to get them hired in the end, not the letters after their name.
There are many ways into the mainstream games industry as a programmer, and you’d be surprised at the varied and roundabout routes people have taken (for me, it was to do a PhD and then move halfway around the world). When I started in the industry, I was amazed at how people had found their way into the job I had always wanted (“someone said a company down the street was hiring programmers” takes the prize). But all of them start the same way: learning to program.
Well this is an easy one; learn C++.
It’s the industry standard and used to make the vast majority of big games out there, primarily because of its low-level nature. C++ gives you full visibility and control over important performance-related things like memory allocation, memory access patterns, code generation and much more. With that control comes complexity, and some industry leaders have legitimate problems with the language – it has many dark hidden corners that can trip up the unwary coder, and gives you enough rope to hang yourself and then another mile or two. It’s easy to do Bad Things™ that lead to serious problems like crashes or memory corruption, but that’s because runtime safety costs performance that we’d prefer to spend on the game. Legacy code is also an undeniable factor in the language’s popularity – there are many stable codebases that have had their bugs hammered out through countless man-hours, and have proven themselves by shipping top selling games. C++ is going to be around for a good while yet.
The most common argument against needing to learn C++ is usually something along the lines of, “But Unity!”. It’s true, Unity uses C# (although Unity’s runtime engine is itself built with C++). However even Unity programmers should at least know enough C++ to appreciate the things going on under the hood that C# hides from you, particularly those that can affect performance (eg. memory management). By all means, learn C# and become familiar with Unity; a variety of skills always looks good on your resume and going from C++ to C# is much easier than the other way around. Learning Unity can also teach important engine concepts like component architectures. But even employers looking for Unity programmers will appreciate applicants having C++ knowledge to back up their C#, and most relevant to this post is the fact that if you want to work in a major studio on a AAA game, C++ knowledge is just non-negotiable. To quote the inimitable Brenda Romero:
Aspiring game coders who insist they don't need to know C++ must not be looking at job listings for this industry.
— Brenda Romero (@br) July 8, 2015If you’re reading this on a PC, you already have enough to get started right now. Download Visual Studio for free and start learning the basics. I usually recommend the tutorials on learncpp.com and cplusplus.com which are well structured and approachable. Don’t worry if you don’t understand something initially (eg. pointers, which are a simple concept but always seem to confuse people the first time around), just keeping reading different sources and keep coding and eventually it will click. Don’t wait until college either – if you’re old enough to read this far, you’re old enough to learn C++!
Once you get to grips with the basic language there are some other great learning resources. The entire codebase of UE4 – a full, mature AAA engine – is available for free to whoever wants it. It might be hard to know where to start, but it’s instructional to even look at how a modern engine is set up: libraries, coding standards, platform handling etc. Then there’s the GDC Vault free section which is expanding all the time, and is full of excellent videos and presentations about a wide variety of topics. There’s also Casey Muratori’s video series Handmade Hero, where he’s programming an entire game from scratch in C/C++ and narrating the whole thing. Finally, I find Twitter a great resource for finding new blog posts, videos and presentations, if you follow the right people.
But by far the best (and most fun) way to learn is by doing…
There’s only so long you can learn about language syntax and development environments in isolation, and it’s not going to come as any surprise that the best way to learn game programming is by making a game. I have two pieces of advice before you start your first one though; keep it simple, and plan to finish it.
It’s very easy to get ahead of yourself and want to make a first-person shooter or an expansive RPG only to slowly realise that you’ve taken on way too much, at which point you may lose heart and give up. Game development is hard, and even seasoned professionals sometimes underestimate the amount of work a given feature or system will take after redesigns, bug hunting, and a thousand other unexpected issues. Over-scoping is the number one reason that games are delayed.
It’s tempting to get the guts of the gameplay done and then want to move onto something new. This is fine if you’re prototyping ideas, but for a learning exercise it’s important that you see things through and finish your game. That means menus, high score tables, and whatever else makes it a complete polished game. You’ll learn from having to do some UI work, you’ll be more proud showing it off, and if you’re using it as part of a portfolio it’s important to show that you finish things. When you’re done you can move on and improve on what you’ve made – start using sprites, or even move to 3D. You’ll see the consequences of some design decisions you made earlier and learn about code reuse, refactoring, and designing for flexibility.
Since the aim is learning, try to write everything from scratch. Every game programmer should have written at least one vector/matrix maths library in their time! But if you want a leg-up to get started with the more mundane stuff like windowing and input handling, you can use a library like SFML. Just make sure you understand the inner workings of any external code you do use – “I would use a library” is never a good response to the interview question, “How would you implement that?”. This particularly applies to libraries like STL or Boost; if you need a container or a sorting algorithm, implement it yourself. Compared to just learning Big-O complexities, you’ll gain a much deeper appreciation of what should be used and when, and it’s important for every game programmer to understand things like the memory allocation behaviour & performance implications of one container versus another.
By now you should have some idea of what areas of game programming you’re most interested in. In larger studios, each programmer usually has a specific role that they work in. So when it comes to hiring time, employers are often looking for people with specific areas of expertise. Here’s a list of the most common programming roles that appear on a game team:
Gameplay: writing gameplay-specific code. Anything and everything that isn’t engine code, and is written to make that specific game run how the designers want it. Usually requires a good game design sensibility.
Rendering: graphics programming, 3D engine design, shader programming, artist support and a few other things including optimizations and low-level engine implementation. Requires understanding of 3D maths, GPUs, and graphics APIs like Direct3D.
Engine: the basement levels of the engine, usually written by some of the most experienced people. Multithreading, memory management, I/O, maths/container libraries… anything low-level or close to the metal. The rest of the game is built on this foundation.
Tools: write plugins and engine-specific tools for artists and designers, including the game editor and DCC-specific tools (Maya, Max, Photoshop plugins etc.). Requires good UI and UX sensibilities. It also usually helps to have knowledge of tool-friendly languages like C# or Python on top of C++.
AI: game NPC behaviour, pathfinding, and all things intelligent-looking.
Animation: implementing the animation of all dynamic in-game objects, primarily characters. Forward & inverse kinematics, motion graphs, animation scripting interfaces etc.
Physics: implement or support the engine’s physics engine, primarily collision detection and resolution. For the maths heavyweights.
Network: all aspects of the networking component of the engine, transport layer and up. Obviously only applicable if the game has an online component, but most do these days.
Audio: sound engine programming – acoustics, attenuation, mixing and so on. Also scripting interface for sound designers.
UI: all things not in the game world – menus, loading screens, overlays, movies & HUDs.
Build: responsible for the build system – code compilation, platform SDK management, build version management & distribution, data pipeline maintenance etc.
Of course these titles and descriptions vary from studio to studio. Ubisoft has ‘generalist’ programmers who can wear multiple hats and work on a variety of systems. At Radical we even had a dedicated camera programmer, whose sole responsibility was the interface and behaviour of all the in-game and cinematic cameras.
If you like the sound of one of these roles, start working towards it as soon as you have a handle on C++. If you’re interested in graphics, start learning an API like Direct3D or OpenGL (D3D is much more commonly used because of the Xbox One/360). If AI sounds good, start implementing pathfinding algorithms like A* or steering behaviours like boid flocking. There are too many paths to list here, but just pick something interesting and start implementing.
This is where things become nebulous, as the hiring process all depends on the recruiting team of the company you’re applying to. No matter what your experience level, some companies can seem completely opaque when it comes to getting an interview, but this is often because of the sheer volume of applicants they get, of wildly varying quality. The best thing you can do as an aspiring game programmer is to make sure that when someone does consider you, you make it as easy as possible to see why they should hire you.
Without experience in the industry, the first thing they’re going to need to know is how well you can code. This means having personal projects you can show off (maybe in a public Git repository which also shows you understand source control). Having full games is good, but even better would be to also have some tech demos tailored to the role you’re hoping to get. Make sure the demos are interesting, polished, and get to the point quickly (assume you’re going to get someone’s attention for a maximum of 3 minutes). They don’t necessarily have to be flashy – a solid multithreaded task scheduler mightn’t be much to look at, but would be a great demo for someone going for an engine programmer role.
Most importantly, make sure the code is good. That means clear, concise, easy to read, well-commented and well-structured. Favour simplicity (readability & debuggability) over complexity. Write your code with the assumption that someone is going to judge you on it, because they will. Make sure it builds out of the box without any external dependencies. Provide executables, and make sure they run on multiple machines without any missing DLLs or other problems.
Beyond code, the usual CV/resumé tips still apply (keep it to 2 pages and spell check thoroughly), and the best places to find jobs are usually directly on studios’ websites – unless you know someone in the company, in which case it’s almost always better to try and get them to put you in touch directly. I’ve heard generally negative things about recruitment agencies, but I don’t have any direct experience so can’t really say one way or another.
With hard work, persistence and luck, you’ll be called for an interview.
Depending on how the studio does things, they may bring you straight in for an interview or arrange a couple of phone calls first. Before any interview, make sure you’re prepared. Read up about the company and play some of their games if you haven’t already. You may be asked about salary expectations, so have some idea of what you would expect. Gamasutra does a yearly salary survey which is a good place to start, although it’s generally very US-centric. At every stage of the interview you’ll also be asked if you have any questions, so it’s a good idea to have some prepared. They can be about anything – the game, the role, the team, the tech, or just life at the studio.
If your first stage is a call with HR, it will be a screening call to get a sense of what you’re like (ie. not a nutcase) and confirm you are who you say you are. They’ll give you a briefing on the company and the role they’re hiring for, and will probably chat for a bit, asking you about career goals or your general background. Take this opportunity to find out as much as you can about the rest of the hiring process, so you know what to expect and prepare for. They’ll then probably arrange a time for an email programming test.
This is a set of programming problems that they will email to you at an agreed time, asking for you to complete it and return the results within a set amount of time. When the time comes, be prepared – have your computer updated and ready to go, a new solution open in Visual Studio, some pen and paper or a text file for jotting down notes, and eliminate any potential distractions like phone calls or visitors. Just like your portfolio, make sure your code is clean, readable and well-commented.
Assuming that goes well, they may arrange another call with one or more programmers, or maybe even skip that and bring you on-site if you live in the same city. Either way, the next stage is the tech interview. Put simply, the aim of the tech interview is to determine what you know, how you think, and what you’re like. They won’t be trying to catch you out, but instead want to figure out how you approach problems, and to see if you’re generally smart. A secondary objective will be to determine if you’re a good fit for the team; some programmers are technically excellent but not good at interacting with others, which also has to be taken into consideration. Making a game is very much a team effort, so you need to be able to communicate well and get on with others.
Initially they may not be so tech-focused, instead asking about general things like what games you play, leading into questions such as what you would improve in one of their previous games (focus on aspects that are relevant to your discipline, and above all be diplomatic!). Since you won’t have any shipped games to discuss, they’ll ask about college projects and personal projects. They’ll be looking for things to ask you about, so try to lead the conversation towards the work you’ve done that is the most impressive and the most relevant to the role they’re hiring for.
Then will come the programming questions. Some will be C++ ones (virtual destructors, vtables, what does keyword X do, etc.), but most will be more involved. There’s an endless list of possible questions and every studio does it differently, so the best you can do is practise all the common ones (eg. linked list reversal, in-place string reversal, calulate nth Fibonacci number… a quick google returns a decent list). Some studios still do whiteboarding, so it might be a good idea to try answering some of these questions with a pen & paper, so you’re not helped out by things like syntax highlighting or reliance on the delete key.
If you don’t know the answer to a question immediately, don’t panic. Everyone knows that even simple questions can become complicated by the stress and artificiality of the interview situation. Interviewers are interested in seeing how you work through a problem, not just hearing you spout out the correct answer. Talk through the problem, identifying assumptions you’re making (even if you think they’re obvious) and break it down into smaller problems. A last resort answer – but still a valid one – is to just say you don’t know, but describe how you might go about finding out the answer.
If you’re ultimately not successful for whatever reason, take it as a learning experience. Follow up with a courteous email thanking them for the opportunity, and ask for feedback as to where they think you could improve. Then listen carefully and heed what they say. If on the other hand you get the job, congratulations! 
You’ve taken your first step into a larger world. Don’t get cocky – you still have a lot to learn, so keep paying attention and work hard. You’re going to continue learning for the rest of your career, but you’ll have some great people to learn from.
The only real path to becoming a game programmer is to keep coding. Work on personal projects. Contribute to open source projects. Keep learning. Identify gaps in your knowledge and fill them. Stretch yourself. Make your own games. Take part in game jams. Work on cool stuff and show it off. Join a college gamedev club. If that doesn’t exist, start one! Play games for inspiration.
And during it all, have fun – after all, isn’t that the point?!