Hey everyone,

My name is Bryce Hanneman and I am currently pursuing a Bachelor's degree in game programming and development through SNHU. I'm new to this community, but I look forward to interacting with you all and learning from your experience. Throughout my time at SNHU I've often been asked what skills I will need for a given position, but I have never really tried asking anyone with experience in the industry which skills I will need. Today I'd like to pose that question to some of the veteran programmers out there. As a gameplay programmer, which skills will I need to secure a job in the game industry? Are there some skills that are more important than others? Is there any specific skill that I should be focusing on more than others?

Roughly from most-specialized to least-specialized:

The 3D math transformation pipeline, and how to apply matrices and quaternions, and in what order they apply, is super important for anyone doing any kind of game development (graphics, physics, AI, audio, …) except perhaps build systems. Build systems are important, too, but don't use 3D math.

The ability to DEBUG SYSTEMS is invaluable. Look at something that goes wrong, and go from that, to understanding clearly WHY it goes wrong, and going from that to understanding what the fix is, such that the problem won't come back, will set successful developers apart from … less successful developers.

The ability to understand requirements, and to ask questions until you understand requirements, is super important. It doesn't matter how well you build something, if you build the wrong thing. Sometimes, designers or producers or artists will think they know what they mean, but asking questions about specifics will show that they actually don't, and their great idea won't work. Good designers will realize this and value the help.

One part of requirements is “what does done mean?” A prototype needs different things from a cutscene needs different things from a quicktime event needs different things from a minigame needs different things from a main mechanic needs different things from a core engine function. What level of testing, polish, robustness, and configurability is right depends on needs, and always building it the best possible will waste more time than you have, and always building the quickest hack possible that fulfills the letter of the stated specification is a great way to be seen as “the guy who can't actually build anything that works.” Balance!

The ability to estimate how many resources are used by particular solutions, when those solutions are in the hands of artists and used “in anger," is very useful. I've seen more than one junior engineer demo something which looks great in a single instance, and bogs everything down as soon when the artists place it on every NPC or every rock or whatever.

At the entry level, a key point is recognizing that you're a raw beginner.

Sure, relative to other students you have been quite skilled. As a senior ready to graduate you are more skilled than all the underclassmen. You're the best of the group when you look around.

But when you get into the workforce, you're the raw beginner. You will have coworkers with 5 years, 10 years, even 20 years of doing exactly the job that you're starting. They have not only worked with the tools every day for years, they may have helped build them, and know them inside and out. Some of them may have been doing it professionally since before you were born, they made the games you enjoyed all your life, and when you enter the workforce you know nothing in comparison.

Ask questions. Assume nothing. Learn from everybody. Cut your ego. You will break things, and your employer knows it. Their hope for entry level workers is that the things you'll build and the help you provide will exceed the issues you cause as a beginner. People will double-check your work, good managers will quiz you to ensure you really understand the requirements, then you'll have one or more people give you code reviews before you submit the code. Use every one of those as an opportunity to learn, to ask questions, and as a way to better yourself.

For specific things you can focus on during your remaining time at school, I recommend getting extra comfortable with anything related to theory and the science side of computer science. Know your algorithms and data structures, because those will always be with you no matter what language you use, no matter what tools you use, no matter what platform you use. I recommend learning whatever you can about low-level systems, how hardware works, how performance works and why it matters, learning both the Big O performance when done with asymptotically large data sets, but also learning the performance when used on smaller data sets.

As hplus mentioned, learn to use debuggers, learn to use tools, learn to read code you didn't write, learn to understand what is going on in code. Learn to understand why people want things, and whenever you're able to, learn to offer up things you can do, or offer up alternatives. This comes with learning lots of theory and algorithms, but if you can tell your co-workers “I don't know how to make X, but I know how to make Y and I think it is similar, will that work?” you'll go a long ways, but in order to do that you need to understand what both X and Y are, and understand how both of them work. So learn everything you can.

I don't know what programming languages they teach at the school. If they don't teach you C++, get some good books on modern C++ and become familiar with it. You don't need to master the language, but you do need to be comfortable reading and writing it. Be sure you're learning C++ as it exists today rather than C++ as it existed in the 1990s. Many schools focus on Java and that's fine, especially if you're going to work on back ends. But also learn C++, which is the language for a lot of systems-level work. also consider learning JavaScript, the language of the web. C# is worth learning if you're going to work with Unity, and you'll likely end up doing that at some point but it's an easy language to learn if you've already picked up a few. Be able to read SQL and able to make your own basic CRUD operations. Like above, employers aren't expecting an entry level fresh graduate to have mastered the language, but they'll expect enough competency that you won't break things too badly or require too much training. If you can do more, if you can work with the tools for hobby projects that's great (they're free, do it) but they're not hiring you for your mastery.

@hplus0603 Thank you for the response! This is all excellent info. I will definitely be spending some time to brush up on my 3D transformation pipeline in the coming terms. The other areas will definitely be areas of focus as well, but luckily I feel much more proficient in those areas and don't feel I have as much progress to make between now and graduation. Thanks again for taking the time to respond! It makes a world of difference to have experienced professionals to gain insights from.

@frob Thank you for responding! It's already clear how much more knowledge you all have in this field, and I really appreciate your willingness to take the time to give me advice. I will definitely try my best to stay humble and keep in mind that mistakes are okay as long as I learn from them and still can keep my work productive. I am fairly familiar with C++ at this point, and I'm pretty confident in my ability to debug. I'm glad to know that those will be valuable to me moving forward! While I've worked with C#, Java, and SQL, I'm not comfortable with any of them. I have not worked with CRUD at all yet, so I will be sure to put some extra time into learning about that. Thanks again for all of this information. Outside of schooling, do you have any exercises or resources that you would recommend for helping me work towards becoming a better programmer?

@hplus0603 @frob Not to discredit your answers, which are great, but aren't you just describing being a software engineer in general (with some emphasis on math and systems level programming)? It seems to me (from my outside perspective) that being a game engine programmer (or systems level programmer) requires mostly technical skills whereas being a gameplay programmer, which is what OP is asking about, requires a blend of technical skills and design skills. Maybe that's just me speaking out of ignorance though.

@frob Beautiful explanation! I am currently learning C# for Unity as long with Full Stack Development. I look forward to developing web games wit PhaserJS.

perry_blueberry said:
being a gameplay programmer, which is what OP is asking about, requires a blend of technical skills and design skills

I think points 3, 4, and 5 of my message supports that pretty well.

In smaller indie studios, the “designer” or “producer” you have to ask questions of becomes yourself. So, at that point, you need to ask yourself enough questions to understand what it is you're trying to accomplish for the player!

perry_blueberry said:
aren't you just describing being a software engineer in general (with some emphasis on math and systems level programming)?

A good programmer is a good programmer, full stop. At the entry level the best thing I can hope for is to see someone on that path. It is a path of perpetual improvement, not a destination.

I have worked with too many people who are lackluster programmers, they only know a few topics and struggle terribly when something is outside their tiny little island of knowledge. I've also worked with plenty of “okay” programmers, and had the difficulty of terminating their jobs. I feel they're the hardest people to fire because there is no specific thing to improve, other than do more of whatever they do. We don't need okay programmers. When we have amazing programmers and an okay programmer shows up, the okay programmer slows everyone down. The hardest thing I've had to explain to someone is that it isn't anything about lacking a specific skills, they're okay at it all. But being okay isn't enough, at least, not with the groups I work with.

When interviewing I look for broad skills first and foremost. That's been true of every good company I've worked at. Though it has been two decades I still absolutely love the old Joel On Software article, looking for people who are both smart and get things done. If they're smart but not getting things done they won't be implementing their features and might work as a consultant, but not an implementer. If they're getting things done but aren't smart about it, people need to go back and redo their work.

When someone has those core skills down, when they're a good software engineer in general, you don't need to explain things multiple times. You can explain it once, they can ask some questions, and you can be confident that they understand, won't screw things up, and get it done.

A good programmer can learn whatever specialties are needed for the task. They have a broad base of skills, and are both willing and able to pick up more. They're both smart, and able to get things done. They may not be a perfect match, but they can adapt by virtue of being smart and getting things done. They may not have a specific specialty, but they will find and develop specialties that we can use, and someone else with that specific specialty can pair up with them, that's why we're teams.

My absolute favorite recent type of recent graduate is one who can do exactly what is described above. Specialties will come with time and experience, so I don't care so much if they do game-specific stuff. The willingness to develop the core, learning the fundamental algorithms and data structures that apply to ALL topics, learning the actual architecture of what is happening under the hood, and learning enough of the tools to actually get their hands dirty, that's what I want to see. While knowing a few game-specific topics is nice, being able to see the big picture coupled with a desire to learn smaller specialties is far, far better.

hplus0603 said:

perry_blueberry said:
being a gameplay programmer, which is what OP is asking about, requires a blend of technical skills and design skills

I think points 3, 4, and 5 of my message supports that pretty well.

In smaller indie studios, the “designer” or “producer” you have to ask questions of becomes yourself. So, at that point, you need to ask yourself enough questions to understand what it is you're trying to accomplish for the player!

Fair enough. I think I glossed over point 4 when I read it initially. I'm just basing it on my own experience prototyping stuff in game engines. It usually ends up being quite trivial to implement most features whereas when I write other software I end up spending a lot of time coming up with a good solution. But maybe that's just the nature of the gameplay features I've tried implementing where I haven't had to face scaling issues due to it just being prototypes.