Intro to Gameplay Programming
Matt posted in Gameplay Programming on September 11th, 2008

Since the beginning of my career, I’ve focused on gameplay programming. Gameplay programming seems like it’s becoming a standard position at many game development studios. Unfortunately for people who are interested in programming games but aren’t in the industry, I haven’t found a very good definition of what exactly gameplay programming is. As well, I haven’t found as many sites carrying tips and tricks that are very useful in a gameplay programmer’s toolbox. (If you know of any, feel free to suggest them in the comments) I’ll try and offer some good tricks I’ve picked up over the years when I have time.
 
So, what IS gameplay programming anyway? It’s the most fun and exciting discipline that game development has to offer! Well, that’s just my opinion, but this blog is my opinion, so hopefully you are interested in what I think. Gameplay programmer tasks can vary significantly from studio to studio. The player logic is almost always done by a gameplay programmer. At studios with data driven design, it involves creating the enemies, widgets and other building blocks that designers use to create an enjoyable experience. At other studios, it can mean that you are given free rein to implement something fun based on a rough sketch that a designer provides. Everything that goes into the level is created by a gameplay programmer including doors, background characters, and sometimes even in engine cutscenes. (For more info about data driven design, here’s my thoughts)

Some studios have designer positions that are basically analogous to gameplay programmers but are called scripters and work in some sort of game engine scripting language (UnrealScript, Lua, Python, etc) rather than C/C++/assembly. (Although I have written very little in assembly, it’s important to be comfortable with it because otherwise, it’s difficult to debug crashes off of discs) I am of the opinion that scripting languages are a bad idea unless you are going to invest the time to make a debugger for your scripting language, but that’s a big time investment. Debugging a scripting language from something either parsing text (for an interpreted scripting language) or executing byte code (for a language that compiles but not to the native instruction set) is a real pain to do, and usually scripting languages don’t have that much convenience over C/C++ (in my opinion anyway).

Gameplay programming is very challenging because gameplay programmers need to have strong design sensibilities and a good handle on how to make something fun. Fun unfortunately cannot be quantified or defined in a word doc or even in a conversation, so good gameplay programmers need to be able to create something fun without a designer telling them what for every iteration. Although usually gameplay code is not the performance bottleneck in most games, it’s important to have a good sense for performance and tricks you can use to create something big and exciting without dropping frames. One of the most important things for gameplay programmers is the ability to create stuff quickly and make it flexible, since gameplay is always evolving to try and make it more fun.

Finally, gameplay programmers end up creating a lot of effects. In the future, there will probably be many specialized effects programmers doing that, but so far in my career, the gameplay programmers have always done the effects. If you are bad at creating effects, there’s still plenty of work for a gameplay programmer to do like AI, various widgets and player control.

So, hopefully I’ve given a decent introduction to gameplay programming. If you have any questions, leave a message. As well, I will try and offer some tips and tricks related to it here in the future.