What is a "Gameplay Programmer"?

Question

In job descriptions, I often see positions called "Gameplay Programmer." What do people in that position do?

Answer 1

When companies talk about hiring a gameplay programmer, what they are talking about is a programmer who will be responsible for code that directly touches on the game experience. That is, the programmer will be responsible for actually constructing the games, rather than engine or larger game systems. But beyond that, things vary a lot:

Some companies expect gameplay programmers to implement the user interface. Some don't. Some companies expect them to implement AI code, some don't. Some expect them to implement audio code, some don't. To be honest, the "gameplay" in gameplay programmer is an industry shorthand for "everything that we haven't hired a specialist to do". So these programmers need to be very versatile, and need to be able to learn new disciplines quickly.

I spent almost fifteen years being a gameplay programmer in the commercial industry, across five different companies.

My experience was that in some companies, a gameplay programmer is considered to be a junior or entry-level position; programmers who are only working on an individual game, after all, don't need to be as sophisticated as those who are working on systems that need to support lots of different games simultaneously, the way that engine programmers need to. In this sort of company, if a gameplay programmer does really well, he might be promoted into the engine team someday, if he can prove his worth. Or he might become a specialist, if he shows an aptitude for a particular area.

In other companies, a gameplay programmer is considered to be a medium-level position; programmers working on an individual game need to have some useful experience and be dependable. Inexperienced programmers might be given undesirable jobs to cut their teeth on (data pipelines, tools, etc), and eventually be allowed to move up into a "gameplay programmer" job. In this sort of system, a gameplay programmer who continues to do quite well might move up into a project leadership role, or else onto the engine team.

In still other companies, a gameplay programmer is considered to be a senior position, and to be a half-design position as well; these programmers are expected to be excellent, proven programmers, but also to have strong design sensibilities and qualifications, since they're directly touching the code that most strongly affects the player's experience with the game. In this sort of system, a really good gameplay programmer will likely remain a gameplay programmer forever -- this is considered to be the most valuable position which he can fill.

As a general rule of thumb, the better the company's games, the more senior a position they consider gameplay programmer to be (and therefore, the more difficult it will be to actually land such a job).

Answer 2

I always find it helps to illustrate by example.

• A gameplay programmer would be given tasks along the lines of: implement the melee combat system, implement the health regeneration mechanic, or implement the player jump controls.

• An engine programmer (what you'd call someone who wasn't specifically a gameplay programmer) would be given tasks along the lines of: implement deferred lighting, or an animation system, or a networking layer.

The key distinction is that of who the 'customer' is. For gameplay programmers, it's the design team - their task is to make the design into a reality. For engine programmers, it's generally other programmers. Engine programmers make technology and systems, which gameplay programmers and content creators can then use to realise the design.

Engine programmers write code which is largely game-agnostic - the same technology can often be used in multiple games. Gameplay programmers tend to write code which is very specific to the game being made. And there's always overlap - sometimes to implement the gameplay you need some new engine code.

Gameplay coding isn't any harder or easier than engine coding. It is however definitely a slightly different skill-set; you often need to be more creative, and be able to bodge solutions. Your goal is not to create the perfect re-usable system (the ideal for engine programmers), but to create the best game implementation. So what can be an asset in engine programming (attention to detail and well engineered structures) can be a hindrance in gameplay programming (where adaptability and iteration time are more important). A good gameplay programmer knows when to do it right (when the design is solid and the code will be used in many places), and when to do it quickly (when the design is still being worked out, and your code has a good chance of being discarded once tested).

Most of all, gameplay programmers need to be able to collaborate with the design team on a level that engine programmers do not. Aside from the obvious communication skills, that means you need to be familiar with other game designs much more than engine programmers do, so that when a designer says "make it work like Zelda," you know what they're talking about.

To learn to be an engine programmer, you'd drill down on a technology and learn how it works, and maybe implement your own version of it; the game would just be an arena in which to show the technology.

To learn to be a gameplay programmer, you'd take someone else's engine, and use it in as many different ways as you can. In other words, if you want to be a gameplay programmer, make games, not technology.

Answer 3

Exactly what it sounds like, a programmer who implements and maintains game play mechanics.

http://en.wikipedia.org/wiki/Game_programmer#Gameplay_programmer