Simple, concrete, step-by-step guide for aspiring Game Developers (Gameplay Programmers) to enter the Games Industry

This is “Games Industry” focused, but applicable to literally all programming.

Step 1, Year One — Start literally anywhere

Your favourite game or studio. What engine do they use? Unity, Unreal, some custom C++ thing? Google it!

• If it’s an engine — Install it now on a capable machine and go to step 2.
• If it’s a custom engine, find what language it was written in (probably C++), google “Game Engine in [Language]”, pick the most popular open source project, clone it, and go to step 2. Don’t know how to clone a repo? Google it until you do.
• If it’s an obscure language, you maybe want to pick a more popular one. Google it.
• If you’re <15 years old, you may want to start with a slightly more accessible version of “Game development”, like RedStone in Minecraft, or building mods, or modding existing mods, or Scratch. Dreams, Little Big Planet, Roblox, Halo Forge etc are all valid. Just find somewhere where you can build something, and build.

Step 2, Year One — Do the thing

Have a Game Engine in front of you now? Nice. Google “[Game Engine] Beginner Tutorial”. Complete any and all of them.

Some will be rubbish. Sorry about that. Do this for 6–12 months, then go to step 3.

Hard fact: This step is not optional. This is the job. Game Development is not “playing” games. It’s building them. But it’s not all bad. There are loads of really compelling problems to solve in Game Dev.

Also: People who build houses (for example) don’t get to live in them (usually…). We do (get to play our games).

Is opening this tutorial f**king scary right now? Yes? Good! Google it all until the words on the screen fill you with enough confidence to continue forward. This is everything.

While following tutorials and building, spend a few hours a week introspecting on:

• What makes a good tutorial? I.e. How do I learn best? What medium works for me?
• What do I struggle with? E.g. “I don’t get Quaternions.”
• What do I enjoy doing in Game Dev? E.g. “I can just add a Rigidbody to each of these cubes and now they dynamically stack? That’s so cool! Lets blow them up!!”
• What do I not enjoy doing in Game Dev?

These will likely inform your “interests” or “specialties” next year, and they’re really good things to talk about in interviews and to mentors.

For me (Niki) it was multiplayer, performance optimization, AI and character controllers. I’d end up watching GDC talks that went over my head most of the time. In hindsight; that was a very good sign.

Tip: It doesn’t matter where you get the information from. YouTube, blog posts, videos or docs or guides. (In fact, a good mix is often great for avoiding burnout). Google literally every question or problem you have. Have no shame about this (because we all do it, and it’s a good thing, actually).

Tip: Learn to learn. I’ve said “Google it” so many times already and it’s the most important truth. Programming is not about how much you can memorize. It’s about identifying a problem and solving it, especially if you didn’t know the answer beforehand. Sounds like “research”? Yes, exactly! It is! More on that below.

Tip: Read (research) a lot. Don’t stress about reading the wrong thing or whatever, it really doesn’t matter. Disagree with people on Reddit. Have rigorous, civil debates (arguments, lol) on game architecture. Start to get a feel for what code patterns you like (and f***ing hate!). Don’t stress about “code quality” or “anti-patterns”. When you read an opinion, work out if you agree or disagree, and why.

Tip: Learn to be wrong. Egos in programming suck because they stop people wanting to help you, and learning is everything. There often are right answers. It’s okay to be wrong: We all are, all the time.

Tip: “I don’t know” is a valid answer. We’re programmers. Literally hundreds of libraries, languages, and APIs are released every year. We all have to learn them. If someone writes a better way to do X, thank them, (buy them a coffee if you can) and copy from them shamelessly until somebody else finds a better way. It is the way.

Tip: Learn how often you assume. Programmers have to assume. There are too many variables. But often it’s a bad assumption that is causing the bug. Validate assumptions.

Step 3, Year Two — Learn the “Problem Solving Loop”

Programming is not rote memorization. Programming is learning how to solve very specific problems, over and over again. It’s a loop. It looks like this:

1. Identify a problem that you’d like to solve. Example: “Make the pong paddle collide with the ball.”

2. Develop “googling” skills to find resources or guidance on how to solve this specific problem. E.g. In Unity, Google “Unity physics ball not colliding with paddle”. Google “Google-fu” to learn how to Google. There will be many or no answers, but you’ll likely now have some ideas to try.

3. Follow that guidance (and your own intuition) until you find a solution (thus building experience). E.g. One solution is to actually write the C# MonoBehaviour OnTriggerEnter code, adding it to the Paddle Prefab (along with a collider of the right shape), setting it as a trigger, testing it etc.

4. Iterate. E.g. Changing values until you get the desired “paddle bounce feel”. Be a Game Designer for a few hours and tweak everything (including code) until your game feels “good”. Not happy with the code itself? Google ways to make it better or cleaner. Ask around. Get second, third and forth opinions.

5. Repeat (with the next problem). E.g. Now you have paddles that the ball will bounce off (you built a whole f**king feature btw, feel proud!), what is the next step (problem) that gets you closer to the ideal game?

And that’s it. That’s the “programmer / problem solving loop”. This is literally what we do all day at the fancy offices.

Tip: The problem with Tutorials is that they show you one way to solve one problem. They don’t teach you the strategy you need to solve all problems. The secret? The above 5 (five) steps are literally all you need.

Spend this year really focusing on this skill. Start working on projects that *don’t have* tutorials. Wing it. Just keep following the above 5 steps and you will end up with a game. I promise. Keep it small and release it on itch. Do it for you.

Tip: Learn how to communicate. “Active Listening” is a trainable skill. Do it. It has the side effect of making you a better person. Listen to programmers talk about specific coding problems and try to follow along. Begin to notice when you get lost. Noticing your own confusion is essential when communicating hard code problems with others. E.g. Sentences like “I understand what you meant about the singleton getting destroyed, but why exactly did that cause this exception? I didn’t understand that bit.” are great for one-on-one conversations.

Tip: Learn how to “debug” and “find and fix bugs”. Yep, Google it. A decent IDE will support “breakpoint debugging” and it’s magic. Printing to the console is also valid. Both are. You’ll quickly learn habits and “go-to” strategies when debugging some new bug. Those are great. Build familiarity.

Step 4, Year Three —Choose your path

By now you’ve hopefully lost count of the number of concrete, specific problems that you’ve solved (or hacked around. That’s great too).

You now have some appreciation for the kinds of problems that are worth solving, the kind of problems that are the “wrong” problems, and the kind of problems that should never have been problems to begin with.

Did you actually press the [Publish] button on that (terrible, awful) game you made? No? Fair. The problem with all skills is that our taste is way better than our ability, so we’re rarely happy with our own work at this stage. That horrible dissonance will last for a few more years in Game Dev, unfortunately.

But when you finally do make that work of art, no feeling is better.

Anyway. Nice, well done. You got this far, and the important thing is that you used that game to learn how to build games. Take a breather. I’m going to state some facts about you. These are objectively true.

• You are now “a steal” for any Game Development Studio’s Junior programmer position.
• Your formal education (or lack thereof) is completely irrelevant. The skills you’ve developed actually concretely building games will dwarf any formal education. BTW: A “Graduate” is essentially the same as (or slightly below) a “Junior”. Why? When you account for all the teenagers who take Game Dev courses then find out it isn’t right for them, “graduating” isn’t a good metric for the quality of new hires. Passion and “self-taught” very much is.
• You can call yourself “self-taught” if you do any kind of unguided googling. It’s magic, and talking about self-taught achievements will be great for your hiring chances.

I (Niki) dropped out of school at 17. Didn’t matter to any of my employers. My self-taught projects mattered a lot.

• Why are you a “steal”? You have the “programmer mindset” locked. I.e. Someone can ask you to “build some small feature into this game” and you’ll already be thinking about how to solve it. You’ll be able to take a (terrified) stab at it by yourself because you now know and trust the (5-step, starting to sound like a cult :D ) process. I.e. You can accept (some) responsibility over building and delivering a feature. That is literally what they’re going to be paying you for, so start making that $$$.
• You’re a real Game Developer! You actually have been since the day you started… We all struggle with Imposter Syndrome.
• Specifically, you’re a “Junior Gameplay Programmer”. Google “Junior Gameplay Programmer” roles. Those are for you.

Tip: F*** it, aim higher. Aim for “Gameplay Programmer” roles. The difference between “Junior” and “Non-descript” Gameplay Programmers is variable enough that you might be able to jump straight into a non-junior role.

Also note: The ability to “learn on the job” is such an important skill that showing off that you know how to learn is often more important than your actual experience. This is why all technical interview advice says to “Ask a bunch of questions when you get given a code problem”.

Now you have a path to choose, my friend:

- Join a studio!

The safer and more pragmatic option, although it can be difficult if you live in the middle of nowhere. Remote roles are getting more common every year though.

• Google how to interview well.
• Google how to make a decent one page CV, and Google what interviewers care about.
• Create a LinkedIn and add all projects you have, starting with the best. In your About Me, explicitly state what you’ve done. Years, what tech, your interests, your passions etc.
• State what roles you’re interested in. In office vs remote. Be concise. E.g. “Looking for full time Junior Gameplay Programmer roles in the UK, in office in London or Remote. Open to recruiters, message me.”
• Expect a gaggle of recruiters to contact you. They’re great when you need a job, and a PITA at all other times. Don’t give out your phone number or email except to setup interviews.

I still get emails using a name I had when I first entered the industry because I sent 1 (one) CV to a recruitment website. It’s been 12 years…

• Being a decent person is essential to getting hired. There is a difference between confidence and arrogance. You will be rejected if you’re a dick, and companies won’t tell you they rejected you for this.
• As mentioned, learn to communicate. Get practice “talking shop” anywhere you can. Google “rubber duck debugging”. You’ve already learned to “active listen” to friends and family now, right?

Best of luck. “Breaking in” is often the hardest bit, but it only has to happen once. Take a job even if its mobile and you wanna do PC (or vice versa). You’ll get there eventually.

- Try to make it as an indie!

You wanna make that dream game and personal circumstances allow you to try? Fantastic, best of luck! It is the hardest path, but it can work. Just be aware that it most likely won’t lead to an indie career. Don’t burn out before your career even starts.

• Keep the scope as small as you can. There is thousands of work years difference between your first Pong and Stardew Valley.
• Read about Steam (or mobile equivalent stores), actually think about commercial viability. Google it all.
• Game Design is as hard as programming has been. And so is Art, Animation, Audio, Marketing, Testing, Business, Community Management, Monetization etc. Being good at programming does not equal Game Design expertise, and you have to do all of these jobs (and more) when you’re making an entire game by yourself. It’s a daunting challenge even for veterans.
• It’s a commitment of likely thousands of your work hours. Giving up evenings, weekends, social events.
• Don’t work with friends. Trust me. It barely works even when everyone is middle aged.
• If you really must work in a team of friends, get a f**king contract and talk it out as if you’re all CEOs. Now. Today. Google how to do it right.

Tip: The often-repeated things about mental health are all accurate. Diet, Exercise, and balance. Work on those too. You’re a person first.

GG

Feedback encouraged: LMK what was helpful, false, confusing etc.