UPDATE: After getting some feedback from some programmers, I’ve decided to include the comments.
A blanket generalization, completely unfair, and easily refuted by pointing to plenty of strong examples! But if you ask engineers (including software engineers, ie. programmers) I’m sure they will tell you that there’s a lot of truth to it.
Engineers are remarkable people, and I have a deep envy of their abilities. They harness complex problem solving, computer languages, physics, unbreakable rules, and advanced math in order to “CREATE”. It’s a type of creation very different from my own writing or drawing, which is loose, intuitive, expressive, and designed to simply “CONVEY” ideas.
Good engineers see what they do as problem solving, systems building, optimization, efficiency, logic, and everything except fun. I’ve heard more than a few programmer’s explain that they only get enjoyment out of things that are procedural and random, because it’s the only time they can’t tell exactly what will happen in every situation with mathematical precision! I’ve seen programmers burn out on their own creations, unable to play their game because all they can predict everything, even when it is randomized.
Fun and enjoyment is a sense of wonder. It’s asking “What if?” and testing it to find out. Interaction is about choice and discovery, but programmers know every choice and every discovery before they even see it.
Popular comic strip “DILBERT” deals with an engineer’s mentality. It’s a person who respects practicality and efficiency, and only gets enjoyment out of seeing something designed well, and being productive, not from actually “enjoying” the things he creates the way an average person would. (Of course he’s not a game programmer, but he’s still task-oriented, and never seems to question the purpose or experience of a program, only its technical workmanship and development workflow.)
Steve Jobs was considered a godly visionary of the hardware/software industry, not because he was a brilliant engineer like Steve Wozniak, but because (shock!) he actually cared deeply about the user’s experience and measured success by it. It’s a very rare thing.
Brian Provinciano, the creator Retro City Rampage, once said this:
…Something that I wish I had more time to talk on was the transition from programmer to designer. Everyone seems to think they are already a designer, but there’s a lot to learn to really become one.
It was quite a journey for me to move from thinking technically to thinking more creatively. The whole checklist approach I had as a programmer — implementing all the features that Grand Theft Auto had — didn’t end up with a fun game. It took a lot of playtesting and iteration to make it enjoyable.
This is the crux of it.
Provinciano was not a “game designer”, he was a programmer. He was thinking in purely technical ways, not actually being creative or having a plan for what would be enjoyable. He had a “checklist approach” which meant including tons “fun things”, but without actually understanding what made them fun!
I played Retro City Rampage with optimism, but found myself tunneling slowly into madness as I tried to decipher the game design behind it. How could somebody so brilliant, who’s obviously such a huge fan of Grand Theft Auto series, not “get” why the game was fun to begin with?
I wrote this about Provinciano and the “Programmer’s Paradox” back then, and it’s an example of the disconnect between “creativity” and “technical implementation”:
When you tell a programmer what you want, he will always ask you HOW you want it EXACTLY. If you say “I want the character to be able to push the crates,” there’s not much room for interpretation, right? You just imagine a character pushing a crate, and do what it takes to make it feel like that. But that means nothing to a programmer.
Here’s what he’d like to know instead:
- Does the character “lock on” to the crate while pushing, or slide along it freely as he goes?
- If he locks on, do players need to push a button first, or does he lock on automatically?
- Does the action button need to be held down the whole time, or just initially?
- Does the character slow down while pushing, or maintain normal move speed?
- If the character does slow down while pushing the crate, is the speed reduction proportionate to the weight of the object and/or strength of the character, or is it always the same speed reduction?
- Are there sound effects while the crate is being pushed? How many sound variations?
- Do the sound effects get played randomly, or in sequential order?
- Does the camera view change at all while pushing?
- Do other characters’ behaviors change while he pushes the crate?
- If their behavior changes, how do they change exactly?
It’s enough to make you hate crates for a lifetime.
Your initial spontaneous design impulses will always be smashed upon the uncompromising rocks of programming reality. It’s like telling your accountant what kind of party you want to throw. He’ll kill the mood immediately, turning your wild ideas for zoo animals and celebrity appearances into a depressing list of itineraries, logistics, and expenditures.
So when an accountant throws himself a party, does he have fun?
The “accountant throwing himself a party” metaphor is still how I feel about many programmers who design their own games. This problem is compounded by the fact that, unlike traditional engineering, there are almost no rules to what can be done with software. Anything is possible if you spend enough time and effort on it.
Traditional, structural engineering is limited by the laws of physics. This is very helpful to the engineer, because every problem is measurable and solvable. Limitations actually help solve problems, because they eliminate so many questions. But programmers have complete freedom over all aspects of a game’s “reality”, including its basic structure. And while complete freedom may sound like a dream come true to an expressive artist who likes to dream big, it’s a road to madness for a technical problem-solver. Freedom means no clear principles to build on, test with, or lean against when you’re creating a system. And since each system is built upon another system, freedom in all directions can mean complete paralysis — not knowing where to start or finish. They’d much rather be given a quantifiable problem to solve! (Hence, game designers.)
The “checklist approach” is probably the best description of a programmer’s stunted imagination you can get. Just picture the accountant as he makes a checklist of all the things fun parties include, then blindly expecting his own to be just as fun when he puts those same things together. I always said math isn’t fun.
“Most game designers suck”
There are plenty of notable examples of game designer-programmers who created something fun, let’s not forget. People like Richard Garriot, Marcus Persson, or Julian Gollop all come to mind at once. Like almost any creative mind, they copied some ideas of others, but added their own twist, using feedback and caring about the experiences they made possible.
This article by Tadhg Kelly talks about how hard it is to “teach” game design, and it speaks to why there’s such a poor conversation in the gaming industry about games themselves. Most game designers are either founding members of their own studios, or a jerk who knows how to do a little of everything and wants to copy something else. It’s infuriating to me. We’re all experts at discussing economics, marketing, and trends, but when it comes to game design we enter a swamp. We get stuck on the most basic ideas, can’t sort out what’s relevant and what’s not, can’t organize ideas, and can’t reach meaningful conclusions.
Finally, who can speak on the matter with more authority than Richard Garriott himself? In this PC Gamer interview he talks about how most game designers “suck”. He says that people who like games but have no programming or artist skills end up becoming designers, instead of people who understand game design, are passionate about it, can communicate it well, and therefore turn game design into a skill itself, critical to the quality of the whole project. Understanding programming is a very important part of being able to knowing how to translate your designs into practical features, but programming itself isn’t game design. Building systems and tool chains without a meaningful direction is like building an motor that doesn’t actually power anything.
COMMENTS FROM PROGRAMMERS:
Below is a comment from a well-experienced programmer friend of mine:
The article about programmers being blind to fun is spot-on, although your description of it as-is comes off a bit as a pejorative. I’d call it a blind spot caused by the skills you must emphasis and prize to be better at programming.
Since I feel golden hammer behavior is very natural to humans, this causes an obvious problem. Analytical behavior isn’t great for design, vision or creativity (I lack any creative bone whatsoever) but it can compensate assuming people realize how they can apply the skills in a different way. For example for games, it is my opinion that to make usability and fun metrics worthwhile, it’s important to get the product/game into as many of your intended hands as possible other than yours or anyone actually working on it. Obviously because you can recognize the defacto position of being unable to trust yourself for multiple reasons.
Great article though.
Programmers are engineers, and engineers have that blind spot for a reason. As I said, I envy their abilities, and I realize those skills require a particular mindset I can’t have. My blind spot is bigger than theirs, in that sense. There are programmers who know how to compensate for their blind spot in a variety of ways, including playtesting and feedback loops. I love how the rise of Kickstarter and “community development” has given developers direct information needed to refine their products.
Any more programmers want to confirm or deny what I’m saying? Let me know and I’ll be glad to include your insight.