#gameplay programmer

Yes, Gameplay Programmer is a specialization. Gameplay Programmers are the engineers who work directly with designers to make the designs actually work in game. This primarily means writing code to make the systems and rules that the designers come up with work.

Gameplay programmer goals tend to be building systems that allow designers to create new content. This often involves building and supporting tools to allow the designers to create, edit, and tune many different individual instances of a specific kind of content - abilities, spells, items, enemies, quests, etc. Thus, a gameplay programmer might build an item editor that would allow an item designer to create many different items. This can scale up to enormous core gameplay-driving systems, like Shadow of Mordor's famous Nemesis system, Prince of Persia's Time Rewind system, or Street Fighter's combat.

Gameplay programmers are not particularly high priority when it comes to layoffs. Engineers tend to be more expensive and marginally more difficult to hire and vet than other fields like QA or production, but gameplay engineers are absolutely not the kind of unicorns like technical artists, engine programmers, graphics programmers, and the like. There's always a need for senior gameplay programmers when it comes to standing a game up at all, but you only need as many gameplay engineers support the designers to build the content that production has scoped.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

Let's consider things from the hiring manager's perspective. As a hiring manager, I have a bunch of specific tasks I need to hire and pay someone to do for me. My ideal candidate will have the necessary skills to do these tasks in a timely fashion and be able to work with and communicate with the rest of the dev team. I am looking for candidates who can show me that they can do the work. The most persuasive way to do that is to show me that they've done that kind of work already.

It is obviously most persuasive if a candidate has demonstrated those skills in a professional environment - it means another company was willing to pay them to do that kind of work. However, it is still pretty persuasive (if not most persuasive) if the candidate can demonstrate those skills elsewhere - in an amateur environment, on a volunteer basis, etc. If you have work experience to show - by all means show it. If you have hobbyist experience to show - show me that too. Relevant hobbyist experience (e.g. building your own mod) is still much more persuasive than irrelevant work experience (e.g. two years as a barista).

If you're aiming for a mid-level position, you need to understand the difference between junior and mid-level. Junior positions are usually technically proficient but do not have the understanding to do things on their own. Juniors need direction and mentorship. We rarely leave them to their own devices. Mid-level programmers need to have more autonomy and less oversight. This means that your lead can assign you a task and you'll generally be able to solve the problem through code without a lot of direction. An ideal mid-level gameplay programmer candidate has built at least one or two robust gameplay systems on their own and can talk at length about the problems they had to solve, the benefits and drawbacks of code solutions they wrote, and the things they would do differently if they had the chance. Those gameplay systems should be performant, self-contained, and stable at the minimum. Gameplay systems that are data-driven and have built-in extensibility for adding new functionality are even better - that's starting to creep into senior dev territory.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Gameplay programmers do a lot of setting up of rules for a particular game mechanic or system and building interfaces/tools for us designers to use to create specific bits of content to utilize those rules. For example, a programmer working on itemization will write code that enforces all the desired rules for our game's items and build an interface for a designer to create specific items bound by the rules the programmer set up.

Some of the different subfields of gameplay programming include:

Combat - One of the much larger subfields. Includes setting up the rules for the actions and results in combat, like determining whether an attack hits, making stats affect attacks and abilities, setting up damage calculations, setting up how things die, deciding when and how to play certain animations, making status effects work. Also includes spawning reinforcements with timing, positioning of enemies, rules for PVP, rules for kill cam, hitting weak points (e.g. head shots), play of the game. Building the interface for designers to tweak combat-related parameters to create specific fights (e.g. boss battle, minion battle, pvp, etc.).

AI - Setting up the rules for what an AI takes into account when making decisions on what to do, how the AI navigates the map to get to where it wants to be. Building the interface to allow designers to create individual AI personalities.

Itemization - Setting up rules for item stats, equipping an item, stat randomization, stat budgets, procs, rarity, drop rates. Building an interface for item designers to create their desired specific items and set up how they drop in game.

Characters - Setting up rules for leveling up, earning experience points, character stats, character classes, talent trees, character abilities. Building an interface for designers to adjust the specific formulas for individual stat growth, experience required to level, costs for specific abilities, etc.

Audio - Setting up the rules for when specific music/motif/voice-over plays, audio effects like reverb/echo/doppler/etc., making directional audio work, applying footsteps based on the material being walked on, adjusting volume of in-game events due to specific priorities. Building an interface for designers to author specific audio events to their liking and to set up specific audio trigger conditions.

Monetization - Setting up the rules for how players engage with the cash shop, how the player receives an item they paid for, how to deal with refunds, showing featured items. Building an interface for designers to assign specific in-game items for sale, associate those items with an event or schedule, set prices. Also building an interface for customer service to refund and roll back sales.

Game Modes/PVP - Setting up the rules for tracking a game mode's victory conditions, dividing players up into teams, ranked/unranked matchmaking. Building an interface for designers to adjust parameters like scoring, time limits, map point capture rates, and so on.

I'm sure you can probably think of other areas for gameplay programmers to work - here are some I didn't get to: achievements, crafting, player housing, gathering, player-to-player trading, in-game pets, seasonal events, quests, cinematics, camera, and co-op. There's usually quite a lot of work for gameplay programmers to do when developing a game.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

If I'm looking to hire a gameplay programmer, there are a lot of useful qualities in a good candidate. Obviously, programming skills are necessary at the baseline. The ideal candidate will have a good understanding of performant code, algorithms, and data structures. Having design chops is helpful, but so is being able to work with a team and take direction from team leadership.

Consider what it is you're showing to a hiring manager like me and ask yourself how it serves to persuade me that I should hire you. What are the qualities of gameplay programmer that you want your project to demonstrate to me? What kind of skills are you showing that you have by telling me about your project? You should know ahead of time what I am looking for - it’s there in the job description. Show me you’ve done it through your project work.

If I were hiring for a game design position, I would care a lot more about the design decisions a candidate made and their thought process behind making those decisions. I would want to know the factors they considered and the potential tradeoffs they weighed. For a gameplay programmer, it is helpful but less important because the gameplay programmer will primarily be writing the code that turns the paper design into reality. If I were you and my goal was to get a gameplay programming job, I would focus on building projects that showcase your programming skills more than I would worry about showcasing design skills.

PS. [Click here] for some common examples of the kind of (math) problems that a gameplay programmer might be tasked with solving.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

I encourage hopeful gameplay programmers to take these classes in specific while in school:

Data Structures

Algorithms

Linear Algebra

Computer Graphics (more for the math elements)

Object-oriented programming

Something using C++

Specifically, you should expand your toolbox so you can tell which solutions are more efficient when solving problems. Linear Algebra and Computer Graphics set a mathematical foundation for understanding how things work in 3 dimensions and how to calculate getting from one point in space to another. These skills are incredibly useful to a gameplay programmer, because we often have to deal with solving those sorts of problems. C++ is the industry standard programming language, so familiarity with C++ is a very big benefit. 

For projects, I just encourage you to do a lot of stuff. Make games. Make mods. Make tools for games. Participate in game jams. Do your own projects. Build something cool, get your friends to play it. Take some video of it and show us your work. Apply the lessons you learned in class to the projects you work on - mod a grab system for a FPS or expand the way stealth works. Build your own maps with custom scripted behaviors or create a new way to traverse an old game. Put yourself in a position where you’ve got gameplay problems to solve through code and then solve them through code. The more of that you have, the better your resume will look to hiring managers like me.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

When I’m hiring for a gameplay programmer specifically, I look for three specific, major qualifications. These qualifications are general programming ability, understanding of 3D math, and a good general understanding of game design and how it translates into code. I’ll give a brief summary of each.

General Programming Ability

This is what most programming tests attempt to gauge. If you’re given a task, what sort of data structures do you choose? Will your code be clear and understandable to other programmers on the team? What is your code’s runtime complexity? Do you understand some of the trickier parts of the language? How do you protect your code from being broken by others? These are the sorts of criteria we’ll judge your general programming ability on. We want to make sure that you make appropriate choices when coding on a team.

3D Math

One very specific element of gameplay programming is the understanding of 3D math. The vast majority of games today are handled in 3D, which means that many gameplay features must take things into account. 3D math solves problems like collision detection, lining up animations for grabs and throws, playing visual effects, player movement and locomotion, and so on. At the base level we will probably expect some core understanding of Euler angles and matrix math.

General Game Design Translation Skills

While it certainly helps to have some game design chops as a gameplay programmer, having game design skill actually isn’t necessary. What is necessary is the ability to take a game design as written and figure out how to make it work in code in an efficient and clean manner, as well as recognizing and alerting the others to potential issues and pitfalls with the design as it is written. I want to know that you can spot problems in a proposed design and then come up with solutions that get what we want and avoid those problems to boot.

What I want to see in a portfolio and resume is your experience (professional or amateur) doing these things. I want to know you wrote code for some gameplay systems with a team. I want to see that you’ve built features that use 3D math principles to function. I want to see that you’ve worked with designers and made their paper designs come to life in a program through code you’ve written. That’s what will get you a callback.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Generally speaking, game designers are responsible for determining how something in game acts and game programmers are responsible for making that something act appropriately. Let’s take a reasonably simple example here - let’s say we wanted to have short cinematic scenes in our game. Let’s use this conversation from one of my favorite films, the Princess Bride:

What is the minimum necessary feature set someone would need to recreate this scene? In no particular order, here’s what I came up with:

Set character location

Play animation on character body

Activate Specific Camera

Deliver Dialogue (including lip sync)

Gameplay programmer Cleo would be tasked with writing a tool that designers could use to specify commands to run at specific times, and she would be responsible for making those commands actually do that. Then she would pass the tool on to the cinematic designers to create cinematics with.

Cinematic designer Ranzal would be tasked with writing a cinematic script that uses these commands to bring this particular scene to life, like so:

0:00 SetPosition Inigo InigoPosition1

0:00 SetPosition Roberts RobertsPosition1\

0:00 Activate Camera1

0:00 Play InigoAnim1

0:00 INIGO: I could do that. I have got some rope up here. But I do not think you would accept my help, since I am only waiting around to kill you!

0:08 Activate Camera2

0:08 Play RobertsClimbAnim1

0:08 ROBERTS: That does put a damper on our relationship

0:11 Activate Camera3

0:11 Play InigoAnim2

0:11 INIGO: But… I promise I will not kill you until I reach the top

0:16 Activate Camera2

0:16 Play RobertsClimbAnim2

0:16 ROBERTS: That’s very comforting, but I’m afraid you just have to wait.

0:20 Activate Camera3

0:20 Play InigoAnim3

0:20 INIGO: I hate waiting… I could give you my word as a Spaniard!

… and so on.

Then, Ranzal would place location markers within the environment for Camera1, Camera2, Camera3, InigoPosition1, InigoPosition2, RobertsPosition1, RobertsPosition2, etc. 

For a particular cinematic, the features of the camera like placement, orientation, zoom, field of view, etc. are determined by the cinematic designer, depending on the sort of feeling that’s intended for the player. Maybe that’s a close up shot to show sincerity, or a long shot to show the difficulty of the task at hand. 

Often we take a more generalized approach - a gameplay camera that follows the player at a distance, doesn’t clip through walls, and generally tries to frame the action. In that case, the breakdown is still the same - the designer (usually the creative director in this case) in charge figures out how she wants the camera to behave (including the edge cases), and the gameplay programmer is tasked with making it happen. Here’s a few example edge cases: 

If the camera can’t clip through walls, what happens if the player backs into a corner? 

Should the camera behave differently in combat?

If the player is locked on to a specific enemy, what should the camera do?

If the player is being targeted by an enemy, what should the camera do?

When the camera has multiple different commands all trying to run at the same time, what takes priority?

The designer figures out what the camera should do and the programmer is responsible for identifying those situations and making the camera choose appropriate behavior. The nice thing is that we don’t have to set any of these in stone as we go. We can iterate on the design and feel of the camera by experimentation and obtaining feedback, add additional features like more granular camera controls (e.g. look at this, move to there, rotate, pan, zoom, etc.), and so on as time progresses, based on the needs of the game, the schedule, and the budget. 

[Join us on Discord]

The FANTa Project is currently on hiatus while I am crunching at work too busy.

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

They are specifically asking for understanding of vector and matrix mathematics, and the ability to apply those principles to solve real game problems. This primarily means matrix transformations and core principles of vector geometry. Here are a few examples of where this might come up.

Imagine that you’ve been tasked with writing the very basics of a shooter. There’s a target in the world somewhere. The player has an orientation and position, and the target has an orientation, position, and radius. The player equips a hitscan weapon and shoots. [Does the shot hit the target?] How can you tell?

Imagine that you’ve been tasked with adding a “doppler” sound effect to projectiles like rockets as they fly through the air. You want the rocket’s sound effect to build up to its maximum volume and pitch when it reaches the closest point to the listener and then scale down as it moves further away. The rocket can be flying in any potential direction. How do you tell when to scale the sound louder or softer? When should it be at its maximum?

Imagine that you’ve been tasked with writing code that determines whether an opponent can see the player. You’ve got the player’s position and orientation and the enemy’s position and orientation. The opponent has an field of view of 120 degrees and a maximum view distance of 100 meters. Can you come up with a formula to determine whether the enemy can see the player?

Imagine that you’ve been tasked with attaching various visual effects to guns - muzzle flash, barrel smoke, sparks, glowy lights, etc. You have the player’s world position and orientation, and have access to the weapon’s position relative to the player and where the vfx should go relative to the gun. Can you figure out where the effects should be placed in the world?

Imagine that you’ve been tasked with adding laser trip mines to the game. A trip mine sticks to a surface and displays a laser perpendicular to the surface it has attached to. If that laser is broken by a player or NPC, the mine explodes. It can also stick to practically anything, including players and enemies. How do you figure out whether the mine should explode?

As you may have guessed, there’s a lot of math that goes into placing things where they should be, pointing them in the directions they should face, and moving them to places where they want to go. Vectors and matrices are the best-understood ways of mathematically modeling those kinds of behaviors in 3 dimensions. This is why a lot of game programmer roles require knowledge of 3D math.

The FANTa Project is currently on hiatus while I am crunching at work too busy.

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr