This year will mark my 12th year anniversary as a gameplay programmer, or sometimes called a “gamelogic” programmer. Consider it the video game equivalent of a “front-end” programmer. The work of a gameplay programmer can be as varied as coding the playable character, the artificial intelligence, the animations, the user interface or the multiple gameplay elements used by the game designers. It’s about coding what is specific to the game.
I’ve spent a bit more than 10 years working at Beenox, which is an Activision owned studio, followed by a short period at Gearbox Studio. I consider myself a game developer first and programmer second, so having a creative part and direct input on the game I’m working on is very important to me. This is hard to do in a very large team, so I decided to make the leap to indie development and left Gearbox to join a team of four of my ex-colleagues from Beenox in a one-year-old startup.
Enough about me; what about you? Are you interested in game development? I learned a couple of things in those years from mistakes, successes, trying things and from the experience of way better programmers than me. It’s time to share them with you!
Love It
You would think the first thing you need to do to become a game programmer is to learn how to code, but it isn’t. Before trying to learn anything, you first need to want to learn. Remember those high school classes you hated? Did you learn much?
Learning to code feels alien, weird and borderline pointless. You look at what can be done with programming, then you look at what you can do with it and think: “Wow, I suck; why am I even doing this?” That’s why the very first step is to love it. Love video games. Love game development. You first need to feel how awesome it is to play your own creation.
In my teenage years, I spent a lot of time in the Starcraft and Warcraft 3 map editors. It wasn’t coding, but it was enough to have the feel of creating my own little game. So I would suggest that you start playing with something like the Starcraft 2 map editor, or “game making” applications like RPG Maker and the likes, to know if you like game development and if you have the drive and passion to continue.
StarCraft II map editor
Once you realize you actually spend more time making games than playing them, you’ll be ready to learn how to code and be happy every time you learn how to do something new with it.
Be Proactive
So there you are, you know how to code and love game development. You already sent your resume to your dream game development studio and never heard back from them. What now? What more can you possibly do to get a job in the video game industry?
Oh, I’m glad you asked.
Personal Projects
You know how to code, but do you know how to code games? Practice makes perfect. Make your own personal projects. Make your own game. Don’t try to make the game you’ve always wanted to make. Create something simple, from the beginning to the end. It will make you understand what is hard to do, what is easy to do and the areas you still have to improve. Once you know that, you’ll be able to aim for “easy wins” – things you know can be done fast that have a lot of impact on the game. Instead of trying to create the next MMORPG Battle Royal MOBA and failing miserably…
I would suggest that you try Unity, a game engine easy to learn for beginners with a ridiculous amount of tutorials and information on the internet. If you encounter a problem, the internet probably has the answer. You can script in C# and JavaScript.
If you feel more adventurous, Unreal would also be a good choice. I feel it’s a bit more “advanced” and not as beginner friendly, but since, like Unity, it’s a public game engine, there is also a lot of information on the internet to help you out. Unlike Unity, you have access to the engine code, so you can modify it. The code is in C++ (fanboy here <3). Unreal is also used in a lot of AAA game development studios.
Game Jams
Game what? Game jams are game development competitions. You usually have 2 to 3 days with a small team of 3 to 6 people to make a game following a given theme.
If you like CodinGame contests, these jams are for you. It makes you work as a team and around constraints such as limited time, limited people and around a theme. This is usually the problem with personal projects: You get lost with too much time, and never finish anything. Game jams are also a good thing to show off and be proud of afterward. Look around for game jams, either where you live or globally. You can also create your own with some friends, following the same guidelines.
Get a Job in Game Development
“Wait, what? To get a job in game development, I need a job in game development? It doesn’t make any sense!”
Yeah, but let me tell you what I mean. The video game industry is a very young industry, so the amount of experienced game developers is very small. On the other hand, a lot of people want to work in it, so the amount of people looking for a job with zero experience is really high. This means that getting more than zero experience makes you go really fast from “nobody wants to hire me” to “my LinkedIn account is getting spammed.” Don’t be picky looking for your first job. Instead of going for the job everybody wants, look for the one nobody wants.
My first released game was Bee Movie: Game, a game based on a kind of bad Dreamworks movie about a bee suing humanity for taking their honey…
Pretty exciting stuff…
Yet my last release was a Call of Duty game, so it’s not like you’ll get stuck forever coding free-to-play mobile Paw Patrol games.
Get a Job as a Programmer
Okay, so even finding a job nobody wants didn’t work. Maybe you’re in a country/region where there are just no game studios, or nobody was hiring. Look for programmer jobs outside of gaming then. You’ll still build valuable experience. Unfortunately, I’ve seen students passively wait for a game programmer job while working at Subway or something, waiting for a ray of light from the heavens to send them a job. Guess what: They didn’t get one. Seeing a 3-year gap in a resume only makes employers think that they weren’t good enough to land a job.
Spoiler alert: You can quit a job. So while at your “non-gaming” programmer job, keep working on the 2 first points. If you have programming experience and you can show that you are passionate about game development from your personal projects/game jams, you are a thousand miles ahead of the passive Subway employee.
Making Games
I thought I could share with you some of the lessons I learned from my own mistakes throughout the years. So here are some tips in a totally random order:
Enemy AI Is Not Supposed to Be Smart
It’s supposed to be fun. You probably think that coding AI is always about making the smartest of them all, defeating everything on its path; but you have to remember that when you are making games, you are not working in research, you are working in entertainment. So your first goal should always be to make the AI fun for the player to fight against. How? The AI must be understandable.
The human brain is good at finding patterns, so let the player’s brain do its job. Avoid random. Avoid learning AIs. The player must be able to predict and anticipate the behavior of the enemy. If the player loses, he/she either played poorly or didn’t understand the patterns yet. If the enemy behaves unpredictably, the player will feel cheated. On the contrary, if the player is able to beat the enemy through learning, he/she will feel gratified; that’s when the player has fun.
The Dark Souls series is known to be hard, not because the AI is hard, but because the consequences are punishing. I think that’s a good part of why this series is so popular, because players can learn the patterns and feel good about beating an AI who can kill them in 2 strikes. Patterns can be as simple as: “If the enemy is close, it will do these types of attacks, if at a certain distance, then others.”
It can also be through animation queues: In the first Dark Souls, one boss is a giant wolf with a sword in its mouth; if it starts swinging from the right, it will do a certain attack, but if it’s from the left, another one. The player feels really clever once he’s figured it out, and the sense of achievement makes it much more rewarding and fun to play.
Optimizing Code Is Not Your First Priority – Not Even the Second!
You might think otherwise in the context of a real time game trying to run at 60 frames per second, but trying to optimize your code too much can be a trap.
Don’t try to fix a problem you don’t have.
Don’t waste time trying to save a microsecond that neither the players nor you will notice in the end.
By “pre-optimizing,” you might make your code unreadable or unmaintainable for your colleagues – and even yourself. You could also make the tools harder to use for non-programmers – or even worse, lower the game’s quality.
Wait to have a performance problem before trying to optimize your code. Most of the time, you have bigger problems than a function call or a square root.
Most game engines use script languages or visual scripting to empower non-programmers and allow them to be creative. These scripts are A LOT slower than C++ code. Why would anybody use it? Because allowing more people with different backgrounds to add content makes better games in the end. Making a good game should always be your top priority.
A “blueprint”, Unreal’s visual script
Make Time for Debug Features
A real-time game can have hundreds of entities running at the same time. It can be hard to find the source of a bug with only break points and logs. You need to code debug features: text boxes attached to AIs with data, drawings of the AI path, its state…These features won’t end up in the final game, but they will save you a lot of debugging time. Being able to activate a debug feature at run time is pretty useful. Some bugs happen very rarely. Reproducing them can be a pain if you have to stop the game to investigate them.
Make time for it, because a manager/producer will probably have a hard time understanding the point of a feature not meant for the game, but it will save you hours of debugging. And don’t make it in an obscure compilation option that only you can use; make it available to everybody, including non-programmers. Making a game is a team effort, and non-programmers can help in the debugging; the more info they have about a problem, the easier it is for them to help.
I worked on the wallcrawl of some Spider-man games. It was really hard to understand what was going on when the character would refuse to stick on a surface or acted weird, putting his hands at the wrong place, etc. So I coded a simple debug feature that drew the collision polygons of a surface and its type, when you pointed the cursor at it. Just staring at the code would have been pointless.
Spider-man wallcrawl
In the end, even artists were using it to understand and help with the debugging.
Play Your Game
This seems obvious, but you’d be surprised how many game developers release a game without playing it even once. The typical day of a game developer, programmer or not, is usually: work on a task, try your modification in the game to see if it works, how it looks and feels, then keep working on it. So the only time you are “playing” the game is to try out your work, but that’s not playing the game.
I’m talking about really playing the game as a player, as a gamer, as a person who wants to win, who wants to enjoy it. Hit that “New Game” or “Start Match” and try it for real. If it’s a multiplayer game, plan a moment with your coworkers. Musicians need to listen to their music, chefs must taste their new recipes, game developers must play their game. How will you improve your game if you don’t know what’s good or bad in it? The only way to know is to play your game.
Egos Are Enemies of Learning
This lesson can help anybody, even outside of gaming and programming. It’s when you think you’re the best that you stop learning anything. There is no such person as an all around “better programmer.” There are a lot of things to know, and while you are good at one thing, you might be totally clueless about something else. Your ego will make you ignore the things you are bad at – afraid of looking incompetent, of not always being the best at everything.
I’m pretty sure that when I started coding, I thought I was 100 times a better programmer than I am now, and yet, I didn’t know much. I met really good programmers. It made me realize how much I still had to learn and be open to ask “stupid questions”; one can either look stupid for a moment or stay stupid forever. You can learn anything, from anyone. I remember a new co-worker who was using a specific simple syntax in C++ to merge code files. It is something you wouldn’t think much about usually. The guy ended up getting fired because he wasn’t competent enough; nonetheless I learned something from him that I’m still using today. Be humble, know your strengths, don’t be afraid to expose your weaknesses; by admitting you don’t know something, you might learn it through the person you’re admitting it to. You’ll never know everything; you’ll never be done learning. What was true in the past, might not be true anymore today. Keep challenging yourself.
Well, that’s it. There is obviously a lot more to know about being a game programmer, so if you have any questions, feel free to PM me on CodinGame or start a conversation on the forum (I know I’m not the only game programmer on the platform). See you in the next contest!
About the Author:
RockyMullet
You might have seen me on CodinGame in your multiplayer bot last battles or rambling on the English general chat with an avatar rocking a glorious mullet. Besides being an avid fan of the best haircut in the world, I also happen to be a video game programmer.