What is a Gameplay Programmer?

A gameplay programmer (or engineer) is someone responsible for translating a game designer’s intent into the game’s codebase to provide the desired player experience.

That’s the succinct version. A gameplay programmer often has a generalist skillset. After all, making a game do the things a designer wants it to do can touch upon a multitude of different systems: audio, physics, animation, cameras, user interface, localization, networking, artificial intelligence, lighting and shaders, user generated content, et cetera.

Some gameplay programmers perform a very niche role and may work on only one particular system, either individually (and therefore responsible for “all” of it) or as part of a team (focused on a narrow slice of the system). Gameplay programmers therefore often fit the idea of the “T-Shaped” engineer.

Photo by Alvaro Reyes on Unsplash

What Makes a Gameplay Programmer Great?

An experienced gameplay programmer is successful at these 6 things:

1. Communicating with designers, artists, and anyone else involved in a gameplay feature to make sure it is implemented in a way that matches the vision.
2. Carefully architecting gameplay systems and features so that they are easy to iterate and morph as design evolves — but balanced by being able to do so without over-engineering it. The systems must be able to do this as they stand alone and also in the ways they interact with the rest of the game — it’s very easy to develop gameplay systems that are far too tightly coupled, making iteration and long-term maintenance a nightmare.
3. Always keeping the player at the forefront of their mind. Implementing a gameplay feature merely to put a check mark on everything from the design specification is not enough. The programmer must understand and respect the feel of the gameplay (which can easily be missed by the player when done well, but can be a showstopper when done poorly).
4. Providing feedback to the designers on that gameplay feel and giving them the engineering information they need to make the best design decisions.
5. Being aware of what technical debt they are creating and making others aware of it as needed. Making and executing plans to fix it when time permits.
6. Giving and taking criticism professionally, not personally. The goal is to make a fantastic game that people want to play, and good communication amongst the team is crucial to achieving it.

Josh, How Do You Know All of This?

I’ve been coding in the industry for almost 24 years, and though my title has varied, gameplay has always been my focus and passion.