implementation than what the designer had in mind. As a result, either the game is
weaker or the designer must go back to the programmer and try to explain how a partic-
ular feature is actually supposed to work. Since game design is such an iterative and
experimental process, there must be a constant circle of feedback between the
designer and the programmer. Obviously, this process is greatly simplified if the
designer and programmer are the same person.
I often find that, as a designer who programs, I can try out ideas much more easily.
In fact, many of the ideas I have I would feel bad trying to get someone else to work on,
since I lack the confidence in them myself to waste someone else’s time with them. But
in the end some of these strange ideas turn out to work quite well in the game, and if I
had never been able to experiment with the code myself, the ideas might never have
been attempted.
A designer/programmer will also often be able to better understand the technology
involved in a project, and be more able to see what is easily accomplished and what is
not. Often a designer who is not a programmer or who is not technologically savvy will
suggest gameplay that is very difficult to implement in the engine. It may be that a dif-
ferent, though equally functional type of gameplay will work better with the game’s
technology, and if the designer/programmer (or at least a designer with programming
experience) notices that, she will be able to greatly simplify the game’s development.
Say a designer wants a certain sword to have a particular behavior to communicate to
the players that it is enchanted. The designer may request that the sword physically
appear to bend somewhat within the player character’s hand. The programmer
assigned to set up this functionality curses the designer, knowing this is a practically
impossible task given the constraints of the engine they are using. The designer does
not realize that creating a fancy particle system around the sword is much easier to do,
though she would be perfectly happy with that solution. As a result, the programmer,
not wanting to seem difficult by resisting the designer’s request, spends a lot of time on
a challenging implementation, when a much simpler one would have satisfied the
designer had she understood the technology better and requested it. Understanding
the feasibility of ideas is a skill that comes with understanding how game programming
fundamentally works, and how the engine you are working with is architected. Even if
you are not actively programming on the project you are developing, you can better
understand what can be easily accomplished with the technology and what feature will
suck away resources for months without adding that much to the game.
Another problem arises when the designer and programmer have different ideas of
what the gameplay for the project should be. I have heard one designer refer to this as
the “pocket veto.” A designer may come to a programmer with an explanation of how
gameplay for a particular section of the game should work, and if the programmer does
not agree, she can simply not implement what the designer has requested. She may
even pretend that the designer’s request is very hard or actually impossible to imple-
ment when it is not. Fortunately, programmers who pull these kinds of tricks do not
tend to last long in the industry. Nonetheless, a designer who cannot program will be
beholden to the talents and inclinations of her programmers, which can be eternally
frustrating.
I am of the opinion that it is worth learning to program if you want to be a designer,
even if you never manage to program up to professional standards and will never do any
292 Chapter 15: Getting the Gameplay Working