Top Ten Mistakes Game Programmers Make While Trying To Make It In The Industry

Last Updated: Jul 30th, 2020

I’ve been in the game programmer industry for over 7 years now (with clearly next to no web design experience) and in the time I’ve seen a lot people try to make it in the gaming industry as engineers and I have seen a lot of people flounder while trying to get in. It’s always the same handful of mistakes, so I’d figure enumerate them by the degree to which they ruin people’s chances in the gaming industry.

Before I begin, this list is for game engineers. Game artists, game designers, and other game development disciplines have a much more difficult road they have to deal with.

10) They think being a game programmer is just playing games all day when it’s actually like running a business

I have lost track of how many times I have encountered college seniors who go up to me telling me that they want to get into the gaming industry and when I ask them what they have done, all they have to show is a bunch of Steam achievements.

Being a game programmer is like owning a business. You invest time into your skills. You then sell your skills to companies in the form of a wage. The concrete skills to build a game is something you can sell. Odds are time you wasted in free to play grindfests is not something you’ll be able to sell.

Also, remember that game programming professionally is very different than game programming for fun. There are parts of game development that aren’t fun to do, but are valuable skills to have. It’s gotten to be really frustrating when students go up to me asking for what skills they need, I give them some theoretical material to read, and then they don’t read it because they just want to learn by doing. “What research you have been reading lately?” is a very common interview question. You better have a good answer.

9) They think game programming is game design

Game programming and game design are two different professions. Most good studios try to get feedback from as many people as possible, but if you’re a game programmer you’re not likely to have any real creative control over the product. You’ll be given a bunch of sprint tasks every 2 weeks and those tasks are likely to be implementing someone else’s ideas. Arguably, the ones who have real creative control are the executives (unfortunately).

I know a lot of people are disappointed when they finally get into the gaming industry only to find out they have no creative control. If you want creative control, you’ll have to go through the design route or get up to management. If you do want to get into either one of those positions, it’s still good to know game programming because managers/designers who can code are highly sought after.

8) They don’t know game programming follows a different set of rules from other software engineering jobs

I’ve encountered a lot of people who are software engineers, went into in demand fields like front end web development, quit their jobs to move to very expensive cities to pursue their dream game programming job, and think they can just waltz into a position like engine programmer and they’ll get hired off of their JavaScript experience.

The gaming industry does not play by the same rules as the rest of software engineering. Most software engineering positions have a shortage of qualified engineers. I have seen people who cannot iterate through a linked list get jobs as mobile developers. For game development positions even hole in the wall companies will get a hundred applicants.

I think they key difference (besides the difference in starting salaries) between game programming and other software engineering jobs is that other software engineering jobs will hire people off potential. For a DevOps position, they’ll hire someone with decent Linux knowledge and train them on the job. For game development if you have not already trained yourself, there are 100 other applicants and at least one of them already trained themselves and they’re the one that is going to get hired.

7) They don’t know that server side is just as important as client side development

Almost all of the big titles these days have an online component. Besides the online servers you play on, these games need support infrastructure. If you’re serious about a career as a game programmer, you’re going to need to know the fundamentals of backend development. I expect you to know (at least at a basic level) how to create and implement a REST API, scalability/SOA/microservices, cloud services, and different database types. Backend development is its own specialty, but even if you don’t plan on specializing on server side stuff you should at least have an idea on how to implement a match making service that can scale out.

6) They don’t stick their programming fundamentals

Game programming. Is. Still. Programming.

Is that clear? So many students ignore anything that isn’t relevant to their pet game programming projects, but the gaming industry will still grill you on core computer science and software engineering fundamentals.

I would expect a game programmer to be able to whiteboard merge sort because it’s a common programming problem that any decent programmer should be able to solve even if it’s been a while since their college algorithms class. Don’t be surprised you’re expected to explain how UTF8 works because game programmers have to deal with string manipulation and localization and off by one errors can be deadly.

You will be asked about time and space complexity. Odds are you’ll be asked about continuous integration and Git. Design patterns also come up regularly. That’s great that you know graphics and collision detection, but don’t forget your fundamentals.

5) They look for shortcuts to make them more professional

So a while back I got an e-mail complaining that my tutorials should be in C. I replied (back when I actually had time to reply to e-mails) that C++ is more of a core language used in the gaming industry. They then replied they wanted to use pure C because it was used to make Ocarina of Time.

This is someone falling prey to the toolbox fallacy. It’s the belief that the tools you’re using matter more than the person using them. While it is important to know the intricacies of core languages like C++ (like knowing when and when not to use inline functions), it’s more important that you understand core concepts than using the latest shiny tools the professionals are using. Using Vulkan over OpenGL will not magically make your graphics better. Bad C++ code will lose out to properly made Python code.

Newbies also have the bad habit of trying to copycat professionals. Professionals don’t always do things the right way. A lot of this has to do with programmers trying to come up with hacky solutions to deal with crunch time. You’d be surprised how often professional code has mistakes that would make a college sophomore gag. You’re not going to get anything magical by looking at the source code or using the same engine. Using the latest tools will not make you better. Understanding the key fundamentals of game engineering will. It doesn’t matter if you managed to get the source code of your favorite game. Knowing how they made it doesn’t help you much unless you know why they did it the way they did.

4) They’re dependent on their tools and don’t study low level programming

Let me preface this section by saying Unity isn’t bad. Believe me, I am very much aware of Unity’s faults. I have been crunching in the office past midnight because of bugs in Unity that made me question why they thought it was acceptable to release the engine in that state. The thing is that every engine I’ve worked with has bugs that I am surprised were allowed to slip in. Unity is easier to use vs Unreal and other engines so it’s the preferred game engine of people who don’t know that they’re doing. It’s less the tool itself and more the people who are using it.

In fact I think anybody who is serious about getting in the industry should know how to make Tetris in Unity at a minimum because it’s such a popular engine. But (and this is a smelly but) Unity should only be a tool in your development arsenal. It should not be a crutch. Not having any game development experience outside of Unity is going to raise some eyebrows when people look at your resume. You should be able to make Tetris with only a low level API like SDL and with a C++ based engine like Unreal. If you get a job making games in Unity, you should have side projects making games in C++.

I’ve worked with AAA studios and hole in the wall development studios. Even hole in the wall studios would easily get a hundred applications for a single opening (and major studios can get 10 times that). Looking through their portfolios, we will get a dozen Unity platformers. You need to set yourself apart from the pack, and many think they are distinct from the dozens of Unity platformers because they only compare themselves against their classmates when they should be comparing themselves against people in the industry. What separates the professionals who do well vs the ones who don’t is that they are adaptable because they understand low level programming and aren’t dependent on a specific game engine. You can put them in a Unity, Unreal, or in house game engine project and they can adapt because they understand the fundamentals.

What are the fundamentals? I would say:

Knowing C++ well. By well I mean you understand the underlying low level stuff like the costs of inheritance and performance implications of memory management. Even if you’re working with C#, a lot of the low level principles of C++ carry over.
Basic graphics programming. Even if you’re not a graphics programmer, you should know at a conceptual level how to take a rigged mesh and animate it.
3D math. If a gun fires a laser shot, you should know how to calculate the point at which it hits the mesh.
Know how to make a rigid body simulator at a conceptual level. Even if it’s just dropping a bunch of 2D boxes and having them behave believably.
Know how computer hardware affects code. Two algorithms can both have the same time complexity but one will run much faster because it is hardware friendly.
Know how the OS affects code. A lot of what goes into a game engine is dealing with how the OS can slow things down.
Know how the compilation process affects performance. A lot of optimizations can be done by writing code that is compiler friendly.
Know the fundamentals of game artificial intelligence. There is overlap between traditional academic AI and game AI but there are significant differences like how game AI often treats AI like a service in a game engine.
Know the fundamentals of latency compensation.
Know the basics of software security and why you should assume the packets you get from the player are the devil.
As mentioned before, you should know the fundamentals of backend service development and architecture.

Yeah, when that tutorial set says beginning game programming I mean it is for people who are just starting out. Believe me, I wish I had the time to update them with more advanced stuff because if you plan on working in the game industry there is so much you need to know. If you’re in a 4 year university, those tutorials are for people who are in their freshman/sophomore year at the latest. By the time you’re a junior, you should be already working on games more complex than Tetris and rolling your own little game engine for your portfolio tech demos.

Even if you don’t deal with the engine code directly while you’re in the industry you will be affected by it. Even if you’re applying for a position that is 99% simple stuff, you will be tested on the complex stuff. When companies hire, they want to know you can handle anything they can throw at you. If you can’t, they’ll find someone who will.

Applicants who get the job typically have at least 3 things:

A playable game to show breadth of knowledge (A New Super Mario Clone, A Quake Clone, etc)
A low level tech demo to show off depth of knowledge (Graphics demos, physics demos, AI demos, etc)
Strong programming and software engineering fundamentals

Many people don’t make it because they don’t know what’s expected of them. You no longer have that excuse so hop to it.

3) They think once they’re in they made it

Most of the people I knew in my computer science program wanted to get into games. Less than a quarter of those made it in. Less than half of those lasted 5 years which, considering the industry average is 5 years, makes statistical sense. Of the people who lasted 5 years, only about half of them are doing well. By doing well, I mean they have relatively stable employment and have salaries that are at or above industry averages for game programmers with 5+ years experience.

The reason so many game programmers don’t last and/or don’t do well is because they get complacent after they get their first job. A lot of them made their Unity platformer, got lucky by getting a job because they knew somebody, and never bothered to continue researching after they got their first job. Then layoffs come and they try to get another job and they don’t get lucky a second time. Job interviews get harder the longer you are in the industry because you’re expected to know more because they expect you to research in your spare time.

You should always be researching because odds are you’re going to be interviewing again because layoffs are always around the corner because layoffs are part of the game industry business structure. Game companies spend X amount of money in 10 projects, 9 of those projects fail, and they hope the last one makes 20X in net income. It’s a high risk, high reward industry. There are companies that wish 1 in 10 of their projects made a profit. The makers of Angry Birds had around 50 projects fail before they got their first hit. It’s highly unlikely the project you’re working on will be successful, and you will need to always be ready to find your next job.

If somehow you find a job that lasts your more than 2 years (2 years is a long time to work a single company in the gaming industry), don’t get complacent. I have seen people get complacent at jobs that last them 5 years, layoffs finally came around, and when they interviewed they were blindsided. They were doing junior level work for 5 years but most places that are looking for people with 5+ years experience are looking for people with 5+ years of research. They end falling out of the industry because they did not keep their research up to date.

What's really bad is that these complacent game programmers give bad advice to students which makes them complacent too. Never trust a game programmer who says that independent research isn’t a core part of their career strategy because they’re the ones that end up falling out or end up making entry level pay years into their career. Yes, even if they’re working at a big name studio.

In the gaming industry, there is no such thing as “making it”. The industry is always changing and you need always be leveling up.

2) They think taking abuse is cool

So I want you to imagine the following scenario: a group of people each bought an HDMI cable. The first person goes “I bought my cable for $8”. The second person goes “Oh yeah? I bought mine for $50!” The next guy goes “Guess what? I bought mine for $500”. Then the last guy goes “I gave them my house and several organs!”

Sounds stupid doesn’t it? Well if you’re salaried game programmer, if you’re working overtime you’re essentially working for free. I have lost track of how many times I’ve seen game developers use the fact that they worked for free as a flex. Working crunch does not make you cool or make you hard working. You can work hard for 40 hours a week. Fortunately, only the newer engineers tend to do this. The more experienced engineers know better.

Bouts of crunch do happen. Project planning is gloried guesswork and no matter how much padding time they put in it is never enough. A few days of overtime here and there is going to happen at a minimum. You’ll probably get a handful of weeks of overtime year. However, when the crunch happens for months on end, you need to get out.

Constant crunch is the result of incompetent management. Anybody who knows the basics of software engineering management knows that after 4 weeks of crunch there is a decrease in productivity. Crunch doesn’t benefit the company and it certainly doesn’t benefit you. Some toxic companies like making their crunch to prove their dedicated. It does not matter how Cool™ this company is or how important their games were to your childhood. It’s just not worth it.

1) They don’t do anything outside of class

I’m based out of southern California and I know quite a few people who graduated from the University of Southern California. Last time I checked, they were one of the top ranked game programming degrees in the world. Indeed, some of the best game programmers I know went to USC. I ended up going to a Cal State because holy mother of pointers have you seen the tuition rates for USC?

I’ve also observed the hiring process at multiple studios and I have seen USC students get their resumes put at the top of the stack. I have also seen recent graduates from USC get their resumes thrown in the trash. Why did these students from one of the best game programming get their resumes thrown in the trash? Because they were the ones that didn’t do anything outsides of class. Even with a high GPA at a top school, if you don’t have any outside of class projects you are not getting to the interview at any decent studio.

It does not matter how good your school is, school by itself will not prepare you. School doesn’t prepare you because it realistically can’t. Game programming is such a huge field there is no realistic way it can prepare you for every possible position you may want to apply for. All they can realistically do is teach you the basic fundamentals so you can teach yourself the rest.

Beside the fact that you’re going to have to fill in the knowledge gaps that school left out with your own research, companies want to be able to see you can self teach. In the industry, you’re going to be dropped into situations where you need to learn and there’s no one to teach you on a pretty regular basis. Having side projects show that they’re not going to have to spoon feed you everything.

You know, I have been programming since 2003 and I feel like I haven’t even scratched the surface. Keep in mind, this year alone I have done at least 2000 pages of independent research. The fact is that if you’re game programmer having side research projects is going to be a part of your life. Even after you get your first job, you’re going to have to have side projects in order to keep up in the industry. It becomes part of your lifestyle. If hiring managers don’t see side projects when you’re in school, they know you’re not ready for the lifestyle it takes to be a game programmer.

One Last Thing

Some of you may be tempted to e-mail me asking for a list of books or other resources. I was considering doing so, but I think it’s more important to teach someone how to fish than to just hand them a fish.

So how to do you fish? Before you even try to start fishing make sure you’re at least capable of making a Tetris clone in C++ with a lower level API like SDL. The reason I keep mentioning Tetris is that it’s a well known game that covers most of the basics of low level game programming while being small enough that you don’t spend too much time on it. It’s a great starter project to make sure you have the basics down.

It’s also a good idea to knock out linear algebra and physics as soon as you can when you’re in college since graphics programming and game physics (and game AI which uses game physics) use them heavily. Operating systems and computer architecture are also pretty important.

Then it’s mostly a matter of effective search engine and social media use. If you want to learn about graphics programming for example, just type into a search engine something like “What is a good book on graphics programming?” or “How do I learn Vulkan?”. Make sure to collect as many opinions as you can, don’t just go for the first thing that pops up in search results because people do try to manipulate those. If you find a game programming forum, let people know where you’re at in your studies and ask where you should go. Again, don't just go off of what one person says. Get as many opinions as you can. Research as much as you can.

The one specific resource I will point out is GDC talks. I always recommend that after you created your Tetris equivalent, you should browse around GDC talks for stuff that looks interesting and if there’s anything you don’t understand so you should go research to fill in those gaps in.

You have list of what to research as a starting point, but when will you be 100% ready to go? Probably never. Despite the fact that I have been game programming professionally for longer than most game programmers last in the industry, I still have lots of things I research. Being a game developer is like climbing an infinitely high mountain: you don’t do it because you’re hoping to reach the top, you do it because you like the climb.

You may be wanting to e-mail me asking where are the GDC talks. I could hand you that fish, or you can fish for it yourself by typing “GDC talks” into the search engine. You may want to ask me if it’s worth paying for the GDC Vault. You could e-mail me or you can search “Is the GDC vault worth the price?” and ask on various forums to get a collection of different opinions to make your decisions. I’m not saying all of this only to discourage you from flooding my inbox (but that definitely is a reason), but because learning how to figure out what you need to research is a skill you need to practice.

You may be thinking “Did you really need to create a guide on how to Google stuff?”. If you hung around newbie programmers as much as I do you’d understand that I very much have to. I would say the overarching problem to most of these top 10 reasons is that students expect things to be handed to them for doing the bare minimum. Knowing that you need to figure things out for yourself and things will not just come to you will make you keep pushing yourself. That’s what you need to do more than anything to make it in the gaming industry.

If you have any suggestions to improve this article, it would be great if you contacted me so I can improve this article. Back to Index