Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
July 31, 2014
arrowPress Releases
July 31, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
On being a "Gameplay Programmer"
by Shay Pierce on 08/17/12 06:33:00 pm   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

My profession is: "Gameplay Programmer."

However, some people may not understand exactly what that is. Allow me to expound on it for a moment.

My job is to take the abstract design ideas about what would make for a fun game, and create the lines of code and math formulae which turn those ideas into something you can actually play with.

My job is to engineer a system of moving parts. The trick is that my systems all have one special moving part: a human mind, experiencing joy.

My job is to take the dozens of decisions made by game designers about what will make for a fun game, then implement them... and make hundreds of tiny decisions about that fun which the designers never thought about.

My job is to read the minds of game designers and what they intended; and to read the mind of game players and what they'll expect. (It helps a lot that I am a game designer, and a game player.)

My job is to make the part of the game that people play.

My job is to create mathematical structures that evoke emotion.

My job is to create art that people can interact with.

My job is sculpting gameplay.

In summary: I have the best job ever.

Thanks for your time!

-------------------------
Shay Pierce is a game designer and programmer with 9 years of experience in the industry, and owner of Deep Plaid Games LLC. He designed and coded the iOS puzzle game Connectrode. He is happier that he doesn't work for Zynga with each passing day.
Follow his game development antics on Twitter: @IQpierce
This post was reposted from his blog at Deep Plaid Games: http://www.deepplaid.com/blog/?p=456


Related Jobs

Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan
[07.31.14]

Programmers
Raven Software / Activision
Raven Software / Activision — Madison, Wisconsin, United States
[07.31.14]

Senior UI Engineer
Disney Consumer Products
Disney Consumer Products — Glendale, California, United States
[07.30.14]

Contract Game Programmer
Zindagi Games
Zindagi Games — Camarillo, California, United States
[07.30.14]

Software Engineer






Comments


Alexander Kraus
profile image
Making a 'fun' game is a little hard as I think that relies on personal opinion. Games like "Dark Soul" is fun to some gamers due to the difficulty and minimal story, yet others would prefer a more 'cinematic' story and squad-based gameplay from "Dragon Age: Origins." Both are great games, but each are subjective to what could be 'fun' from a gamer's point of view.

For me I would like to make a game that is targeted towards a group's interests. If I knew that my target audience prefers fighting games, I would do my research on games in this genre and ask the community what they would like to see. In a way I am "reading their mind" and "creating mathematical structures that evoke emotion," but it involves the basics of communication and research.

Eric Schwarz
profile image
Here's a quick question: how do you feel a gameplay programmer's job differs from a game designer's, who might be responsible for things like balancing the same game systems he/she proposed, or scripting various gameplay objectives and scenarios?

I simply ask because when I think gameplay programmer, I don't necessarily think of someone with tons of creative control - though of course this could also vary dramatically based on the studio itself.

Shay Pierce
profile image
In theory the role "Gameplay Programmer" DOESN'T involve creative control; in theory it's just a programmer implementing a design document written by a designer; the designer will then work with the implemented system, setting variables and creating content.

But in practice, whether anyone wants it or not, the gameplay programmer ALWAYS ends up making decisions about how the game will function and "feel."

Essentially the way it goes is, a designer comes up with an idea for how a game (or game system) works, writes it up, and asks the gameplay programmer to implement it. The programmer immediately recognizes 5 edge cases the designer hadn't thought of, and they hash it out. The programmer figures out how to implement the system (and in the process makes about 20 decisions about how the system actually functions, since they have to break it down to a mathematical level that the designer hasn't, and account for technical constraints the designer hasn't). The programmer then implements the system (and in the process discovers/solves 10 edge cases where the system interacts with other systems, and makes sure the behavior in all cases is sane and follows the designer's intention). The programmer then runs the code, plays with it, and fixes many more edge cases that no one had foreseen.

For big decisions, the programmer pulls the designer over... but it's not feasible to do that for every tiny decision the programmer has to make. No matter how conscientious the programmer tries to be about keeping creative control in the designer's hands, a gameplay programmer is going to make some decisions about How Things Work, because they're the ones making it work.

That's why it's best to acknowledge and embrace that the programmer IS going to be making game design decisions, and to make sure your programmer has a good design sense... and a good ability to read designers' minds!

In practice I prefer to operate as a solo Designer/Programmer (which I think is a role that deserves its own term, since it's really more than the sum of its parts). But I do like this kind of designer/programmer relationship; when it works well it can be a beautiful thing, and I've had the fortune of working closely with some great designers this way.

Andrew Grapsas
profile image
Gameplay programmers have a lot of creative control. We define the constraints a system exists within (the variables exposed, the range of those variables), we handle the thousand edge cases designer do not think of (and, often, cannot). We bring structure to madness. Gameplay programmers have to be individuals with a strong sense of design (for those moments where we must challenge design, or collaborate with design), a head for user experience (in the end, we help gain that sense of "feeling" games requires to be great), an understanding of rules and systems, and rabid (snarling) engineering powers (often times, we have very tight constraints on the performance of our systems and scant resources; so, we have to write optimized, thought out code).

As a gameplay engineer, you work one on one with design, often times in a very friendly manner. As such, your communication with the designers, you ability to collaborate, that gives gameplay designers a significant influence over feature-level design.

Being a gameplay engineer is hard :) And wonderful.

Joe Doe
profile image
"Gameplay programmer" is a glorified definition of: "Intern."

Andrew Grapsas
profile image
If your gameplay programmer is an intern, your product is pretty well screwed.


none
 
Comment: