Programming

This chapter is written from the point of view of someone who is a designer and a programmer, as I have been on all of my projects. Being in such a position has many unique advantages, especially in terms of being able to experiment with gameplay. A designer/programmer is able to have an idea for some gameplay and then can instantly attempt to implement it exactly how she wants it. A designer who does not program is forced to first communicate her idea for the gameplay to the programmer and hope that the design is understood . Often the communication will break down and the designer will not get exactly what she wanted or the feature in question may have an inferior 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 particular 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 different, 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 implement 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 coding on the games you ship. Indeed, I originally pursued programming because I wanted to design computer games. It is beyond the scope of this book to actually teach you to program, and there are certainly plenty of books available to help you learn what you will need to work on games. Much of effective programming is a matter of discipline. And you do not even need to be a terribly good programmer to have it help your design out immensely. Indeed, almost all the designer/programmers I know will insist that they are not very good programmers, but that they are persistent enough to get what they want out of their games . As I have mentioned, knowing how to program will give you a better sense of what is easy to do in a game and what is hard, and programmers will respect you for attempting to better understand their side of game development. Furthermore, learning how to program will help teach you how to think logically and abstractly, a talent of vital importance to both programmers and game designers.

Of course, with modern projects and fifty-person development teams , it is often difficult to be both a designer and a programmer, simply due to the amount of time designers will need to spend on their own work and conveying their vision to the team. If you are not going to be programming on your project, it is essential that you have a lead programmer with a good sense of gameplay, someone whose opinion you can trust. Indeed, you will be well advised to only have programmers on your team who have a good sense of what makes games fun. In the end, there are an infinite number of small decisions that programmers make that will have a profound impact on the gameplay, details that no designer can anticipate. These little details have an enormous impact on the final game and determine how the game feels to play. Often, unmotivated or disinterested lead programmers can be found to be behind games that seem like good ideas in theory but just do not turn out to be any fun. Many projects have gone from promising starts to dissatisfying final products as the result of programmers who merely implement various features from a specification and never take a moment to look at the whole game and see if it is any fun.

This book includes interviews with seven people who are indisputably some of the most talented game designers in the history of the industry. It is interesting to note that of those seven, all were programmers at one point in their careers and programmed in some capacity on their most respected games. Indeed, back in the early days of the computer game industry, the development process was of a small enough scale that one person was doing all the work, so there was no need to separate the role of designer and programmer. Nonetheless, several of the interview subjects still serve as the lead programmer on their own projects. This is not to say that one cannot be a great designer without being a programmer, but I think designers who are able to program have a leg up on those who cannot, an advantage that allows them to make better games.