‘Gameplay Programming’ is a fairly opaque term for folks not involved in the game industry (or those looking to break-in) which is my motivation for writing this post. I would like to provide a high-level overview of what the role is from my experience and perspective. Apologies upfront if you’re a more seasoned developer and don’t get a ton of value from this post.

Definition, role, and responsibilities of a gameplay programmer can vary widely between companies, projects, and even other gameplay programmers. A quick Google Search for ‘What is a Gameplay Programmer?’ leads to a few results like this one from gamedev.stackexchange and this Wikipedia definition that might leave you with more questions than answers. Even my own response to the dreaded “What do you do for a living?” question from new acquaintances is pretty vague. To which I normally respond “I work with a team of other engineers to bring the game design team’s vision to life on the computer screen”. Another unhelpful platitude, I know – but hang with me as we dig into it.

My second year of college (~2015), I decided that I wanted to focus primarily on the programming aspect of game development. I really liked the problem solving space and being able to manifest my ideas into something you could play. At that point I had a few small games/experiences under my belt and was looking at industry job postings. At the time, I was primarily looking for paid internships, but I was also trying to figure out what specializations I could hone in on. There are a lot of subfields of game programming so it was a little overwhelming. Because I had the experience of making a few small games and projects from start to finish, I had exposure to some of these fields: User Interface, Artificial Intelligence, Graphics, Audio, Engine etc. All of those fields are extremely useful and necessary to make most games. However, when I really sat down to think about it, the problems I loved to solve most are the ones related to game mechanics.

The Wikipedia definition for game mechanics states “there are no accepted definitions of game mechanics.” Without inciting a philosophical debate and for simplicity, I would define a game mechanic as “a rule, system, or action between the player and the game.” By this definition, the game designer would need to define how these game mechanics function in the context of the game. The gameplay programmer’s responsibility is to then translate that design into something you can interact with on the screen. Game designers often write game design documents (i.e. GDD) to describe the vision to other team members. Similarly, game programmers of all disciplines write technical design documents (i.e. TDD) based on the game design documents to describe programming solutions, predicted roadblocks, etc. based on the outlined mechanics. Both of these documents are tools for organizing ideas which is extremely useful on large teams. That said, they’re not a requirement to make the game. Sometimes, game mechanics need to be prototyped out to verify they’re fun or to see if the concept is valuable to the game’s experience. Prototyping is one of my favorite areas of game development and it involves a back and forth between gameplay programmers and game designers.

You can see why pinning down a definition of ‘gameplay programmer’ is hard to do. It’s very contingent on the type of game you’re making, the gameplay mechanics, and required game systems. That said, here’s the systems I always expect and like to work on as gameplay programmer:

• Character
• Controls
• Camera

Savvy readers know these better as the 3Cs of Game Development. These three systems are the first thing I think of when gameplay programming. Given a game description or pitch, I immediately wonder how these systems work in the game because I know each of them will have a direct impact on how the player ‘feels’ when playing the game. If you’re working with a game designer, it also opens up a world of questions from you to them:

• How does the character move through the world? What actions can the character perform?
• What controls does the player have access to? What kind of input windows are needed? What should happen when this button is pressed?
• How does the player see the game world? How does the camera move?

Working these out together will get you closer as a team to putting that vision on the screen and that’s what it’s all about. Exposing design variables to the game designers that they can tweak will also prevent you from spending all your time on one gameplay system. Naturally, you may find yourself writing tools here too but that’s a topic for a different day.

Hopefully I’ve answered the question this post posed and shed some light on what it is a gameplay programmer does. Everyone’s path and experience in the game industry is different so I’d love to hear your thoughts or experience. Until next time!