Programmers as Designers

First let me point out that there are many game-building tasks that are given to a designer. The designer might come up with a world history, write character dialog, design levels, tweak game mechanics, design game mechanics, name classes or skills, come up with crafting recipes, write game-item scripts, and on and on.

Here, I'm talking about the high level stuff -- mechanics, and the other stuff insofar as it is relevant to the feel of the gameplay experience. The gestalt of (say) level design, rather than the craft of it.

--

Programmers, by the nature of their job, have a great body of experience to draw from; a rich source upon which they can draw insight into the game design process.

Let's say you want dynamically flowing water in your mostly-2D city building game. You can ask a programmer about it, and work with the programmer. But what works, the caveats, etc are all things discovered by the programmer. Having someone else (a separate designer) stare over his shoulder just wastes his time -- unless you think it's important to prevent that programmer from working without adult supervision. :P

Some programmers are eggheads. Total geeks. Socially inept, clumsy, absent-minded, the works. These guys might be good at algorithms, but you don't want to let them near your design. My argument isn't that being socially inept makes someone a game designer. Quite the reverse. My argument is that a rational mind is critical for the task.

A good designer needs to understand [1] how algorithms will impact gameplay; [2] what drives players, what they think of as fun, and what makes games compelling; and [3] how the mechanics he's built into the game will alter and steer player behavior.

Algorithms

I've met some designers that are great at level design. True artists. But their levels were sometimes awkward and unbalanced. I wouldn't want to ask them to come up with game mechanics, other than to contribute some creative suggestions. They were no better at designing game mechanics than dozens of the egghead programmers I've worked with, but the engineers understood Big O, searching, sorting, curves, graphs, charts, A*, inheritance, and/or state machines.

Compelling Gameplay

A good designer needs to understand how people think. Coming up with cool ideas isn't useful if you're the only one that thinks they're cool. I've said before (and this might well be a recurring them) that most players have no idea of why they like a game. It's easy to take something and criticize it. When you don't actually have to implement anything, it's also easy to suggest solutions. I'm reminded of suggestion threads on popular-game bulletin boards. There's a ton of people with theories for making the game more awesome or less sucky, and a ton of theories that just won't work.

This isn't something that a programmer would be better at than an artist or level builder, generally, except that I think a programmer is closer to learning about this stuff, because good programmers are good at analysis. They understand the scientific method, and how to test their own theories on player behavior. Some designers spend a lot of time studying game mechanics; some programmers do too; either one might also spend time studying psychology.

Incentives

Game designers get to play Economics Czar, but people are bad economists. Politicians will tell you "we're doing this for the children" and wind up with a plan that stabs them in the back. A game design sets up incentives, which players will quickly discover and play to. Learning to look for and see incentives before they're implemented in a game isn't something that happens after reading one blog page. A book might help.

As with creating compelling gameplay, I think this is one of those areas that programmers are often not any more competent than anyone else in a game studio, but yet an area where their mindset and experience with code (and scripting) can give them a head start in learning it.

The Biggest Barrier

I think the biggest hindrance to creating great game mechanics, for non-programmers, is not knowing what's possible to do in code. I'm an agile developer, and I think one of the key life lessons that's pushed me in that direction is learning that you find out far more about a problem by trying to implement it than you ever could be staring at it while it's on a piece of paper. When I was in college (and for years afterwards) I thought the most important thing a programmer should do is plan out his development path in excruciating detail. Implementation turns that detail to excrement. For years my plans never turned out the way I thought, and, like a politician addicted to money, thought the solution was to throw ever more at the problem.

But the lesson isn't to not plan; it's to acknowledge that you need to jump in and get your feet wet, to find out if the rock you see underneath those rippling waves is as sturdy as you think it is. Staring and planning and measuring from the streambed will give you a better idea, but not the answer.

Programmers are the ones charged with finding away across that stream. I think the experience of doing the grunt work gives the grunt a great perspective for planning the next one. It's up to the programmer to put that experience to work.