Designer-Friendly Programming 101

If you are a gameplay programmer, you are the conduit between design and programming. You are the person walking the thin line between the fantasy dreams of every designer and the harsh technical realities of what your target platform, game engine, and human resources can provide. You play a critical role in the development of any game and should treat it as such.

Being effective in bridge roles like this means being able to communicate well with both sides as well as making good compromise choices that attend to the needs and desires of both sides. Those choices are the focus of this post.

Most gameplay programmers are traditionally trained in the art of programming. So, it's typically very natural for them to interact well with other programmers and to be aware of the needs of the programming side of things. As such, I'm not going to spend any time telling you how to be a good programmer. Anyone still reading this is already a rock star programmer anyway, right?

But maybe you don't do so well with interacting with and being aware of the design side of things. Luckily, all you need to do is follow these simple engine-agnostic rules to make sure that your designers love you... or, at least, don't hate you.

1. Keep things on a need-to-know basis

The details of complex systems created by gameplay programmers can be overwhelming to non-programmers. Whenever possible, keep those details to yourself and don't trouble your designers with them. In practice, this means being careful to hide any information or logic that your designer does not need to know. One of the most basic ways to do this is by properly setting the accessibility of all your methods and variables. Don't make members public just because it will save you a few lines of code at the expense of potential designer confusion.

You must also consider the scope that the various design settings may take on. Many game engines have a concept of prefabs or templates used for their game objects. This kind of architecture allows you to define the scope of your settings as global, per-prefab, or per-instance. You should take great care in making this scoping decision such that only things that should be changed by the designer can actually be changed.

For example, in most games, whenever you encounter a character or object that you have encountered before, you expect it to behave just like the last one you encountered. In these types of games, per-instance settings are a no-no. You don't want to give a designer the opportunity to place an object that doesn't behave as expected by the player. Ideally, when a designer places an object in a level, they should be presented with a set of configuration options that make sense for them to change. No more. No less.

"Oh that setting right there? Yeah, you can change it, but don't." If this sentence has ever left your lips then you're doing it wrong.

2. Provide power without programming

As much as possible you should empower your designers to tweak the game without needing to change or even look at a single line of code. Hopefully, you're at least starting out by choosing to use a game engine with a robust GUI like Unity or Unreal. These kinds of engines give great power to the designers to make changes without coding.

Designers are struck with ideas and inspiration all the time. "Maybe the plasma cannon should do area of effect damage..." "What if the flaming zombies caught other zombies on fire?" "Maybe Frank the Ferret should jump higher..." Game development thrives on the ideas and inspirations of designers. Give them every opportunity to chase those ideas without having to ask for outside help from you.

As soon as their ideas require programming, the designers will either have to wait on you or be forced into making code changes that neither designers nor programmers feel comfortable with. This can ultimately lead to stifled creativity. But if you give designers tools from the beginning that allow them to iterate and expand on their ideas without your help, you have done them a great service.

The truth about programmers

3. Make it easy on the eyes

Designers are often very visual creatures. Many of them, especially level designers, have some kind of background or training in art. As you build systems for them to use, play to those strengths and make everything as visual as possible. Here are a few examples:

If you are building a system for designers to place guard towers in your game, then make sure to not just give them numeric variables like "radius" and "firingArc," but also to draw visible representations of those variables. Draw a circle on the screen so that they can see how far 50m really is. Draw a cone so they know how big a 30 degree arc is. 

If you are building a system where you have switches scattered around that unlock doors, consider drawing a line from the switch to the door that it operates. This is especially important if you are designing a game with lots of doors and designers will be prone to copy/paste and forget to update each object's references.

If you are building an enemy AI system and there are 5 different enemy types but only one has been modeled by art, it is your job to make the best of that situation. Temporarily add something visual for the designers so that they don't have to guess which enemy is which. Add an icon, a text label, or even just a simple coloring change to visually differentiate between the enemies.

Remember, though you are not an artist, there is still plenty you can do with simple circles, spheres, lines, and other primitives to provide excellent visual feedback to your designers. 

4. Automate the tedious design work

During your career you will find plenty of features that your designers don't NEED to do their job, but they would be nice to have. Often these will be tasks that can be tediously done by hand by artists and designers, but could possibly be automated by a programmer. Don't be too quick to shoot those ideas down just because they don't tangibly and directly result in a better end-user gameplay experience. In each of those cases you should always do some quick mental cost-benefit analyses in terms of how much team time may be saved by implementing those features.

For example, imagine you have a problem with AIs wandering out of the bounds of your level. The designers and artists could probably fix that without your help by manually placing invisible walls around the bounds of each level in the game. On the other hand, you might be able to programmatically determine the bounds of each level. Then, you could use that info to either place invisible walls or use it in the AI logic to make sure the AIs never leave those bounds. Your programmatic solution may take hours to do, but it may also save days or weeks worth of design or art work. That may make it a very worthwhile usage of your time.

So, there you have it. Four rules that will make your designers' happy. In general, just remember: if you make your designers' jobs easier, less confusing, less tedious, and less stressful, then you're doing it right. You will also inevitably end up with a better game. And we all want to make better games, right?