Skills for a gamplay programmer

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.

frob said:
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.

I've seen that and always thought “being smart” meant having high intelligence. Didn't realize he meant writing clean code as you suggest. Then it makes a bit more sense (since raw intelligence is difficult to improve). I've seen people be at both extremes. Some people implement stuff quickly and disregard pull request comments and general ways of improvements as “I'll do it later” or “too much work right now”, which means someone else gets the fun job of cleaning up their code later down the line. The people I've seen at the other extreme seem to adore Uncle Bob and care more about generic code (oftentimes overengineered code) which ends up solving general problems which sometimes happen to be the problems we are interested in solving and sometimes the solutions end making things less extensible than the simplest solution would have. Both groups can be frustrating to work with but at least the “smart” group sees it as their duty to write good code whereas the “getting things done” group only seem to care about looking productive to managers, which can be beyond frustrating for someone working alongside them. Obviously these are over-generalisations and even those people were not solely in one camp or the other, but I agree with the sentiment that bad engineers the rest down.
/rant

I do think, however, that there is some duality to “smart” and “getting things done”. Producing clean code quickly is something quite difficult in my view. Just the act of cleaning up code after pull request comments can oftentime take me 1-2 days of extra work (since it often involves learning about a more efficient way of solving the same problem, which takes extra time to research). IMO it is mostly lead developers, with many years experience solving similar issues in the same language/framework, who have the skills to do both things at the same time.

frob said:
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.

I agree. Working with someone where you say something once and they “get it” directly is an amazing feeling. It is very rare though because you both have to have a baseline of technical understanding as well as a similar view of architecture and coding practices for it to actually work in this way IMO. Doing pair programming when you find someone like this can be incredibly rewarding since you can feed off each other.

frob said:
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.

Too bad most recruiters don't seem to think like that. I would just add that being a good communicator oftentimes seems even more important than the other two, since teaching/learning from that kind of person is much easier than someone who lacks communication skills.

frob said:
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.

Where I'm from it's against the law to fire someone based on performance so I have never been in a company where people get fired. But I do wonder how I would stack up. I've gotten glowing reviews from several workplaces, however when I read what you are saying I doubt my skills would actually hold water. It's that old cliché of being an impostor I guess. Do the people who end up sticking around have confidence in their abilities or don't you notice any difference in that aspect between the “good” and the “bad”? How do the people you end hiring present themselves in the hiring process?
I'm just asking because when I've gotten rejected for jobs that I really wanted I've been left wondering if they thought my actual technical skills were not good enough or if they thought what they saw from my skills in addition to my perceived lack of confidence sealed the deal. From what I've heard, lots of people lie on their resumes and pretend that they know things they don't, and there are many engineers in general who have lots of confidence in their ideas/implementations even when wrong. It makes me wonder if recruiters base their decisions on what the applicant is showing and then reduce expectations based on the probable fact that they are overselling their abilities. I'm not sure if my strategy of brutal honesty about my abilities is working out as well as I would like or if it's taken as a lack of confidence.

I interviewed at so many places early in my career and even then after. I had a really cool portfolio of 3D game that I made from scratch and a lot of people said that I was interviewed solely on that. It stood out. So what you need to know in games is how to make a game. That simple. You don't need to know everything to create the best GTA 6, but you have to be able to create some kind of game on your own.

Without performing the best animation blending techniques and realistic facial animations: Simply learn to create a 3D mario game to some extent. It shows you can know how 3D things work and how to manage things that occur in every game. That's more than 95% of the people I've seen resumes for, or people that were hired as QA Testers with apparently computer science bachelors degrees that didn't create one single 2D or 3D game, and even couldn't do basic things like take a word in any language and reverse it or how to implement linked lists which every programmer should know.

Couldn't tell from SNHU website if your degree is mostly C++ but it looks like they hopefully teach some data structures and algorithms in depth. If your teacher isn't teaching you C++, then good luck. You need to take time out of your day to learn C++ really well.

@dpadam450 I appreciate the response! I am currently working with C++ and I've become pretty comfortable with it. I've also made a few games at this point, but I only have one that I've been comfortable sharing. It's linked in my profile if you want to check it out! I also saw your reply on my other post as well, and I really appreciate it. I've been pretty busy this term, but following along with the book that you shared will be my next project. Thanks again for your feedback! It really helps.

A: Make a video of your game. It's quick to see and evaluate. B: Your exe didn't launch for me, possibly because I don't have UE4 installed. CreateProcess returned 2. Make sure you have proper DLL's in the folder. Try running on a non UE4 PC, but 99% of people probably will never download your game. Make it easy for people to read and see your resume.

If you're going to use the latest and greatest features in C++, I recommend staying away from the auto keyword.

“auto” is a requirement to support certain template constructs, just like trailing-return-type in lambda-captures.

It's also quite helpful in cases like for loops over iterators (when not using colon iterator syntax.) So, like anything in C++, you can't say “never do X” or “always do Y;” each feature is there to support a particular set of use cases, and to be a GOOD C++ programmer, you have to learn all of them. Which takes a long time, and a lot of experience.

Whether this is good for C++ as a language or not, is a totally different discussion :-)

Never use pointers to allocate memory. :P