Yes, you should understand code - even if you're not a programmer

In this reprint from the May 2002 issue of Game Developer magazine, Chris Hecker suggests that all game designers should know how to code -- to even understand what a game is. What is the role of technology in games? There is conventional wisdom in the game industry that games and game designs should not be based on technology, especially if we are ever going to be seen as a true art form. I'd like to challenge this wisdom. I take it as a given that games are or at least have the potential to be an art form on par with literature, film, music, visual arts, and the rest. We might squander this opportunity, but I am confident we have the potential. As many have said before, we resemble film in the early 1900s: disrespected as mindless popular entertainment. Sadly, we live down to that expectation all too often. However, someday, someone will design the game equivalent of D.W. Griffith's Birth of a Nation, and the world -- like it did with film in 1915 -- will take notice of what's really possible with games. Music is completely different from painting, and games will be different from the other art forms as well. This is why the Hollywood people who occasionally try to overrun us always fail: they don't understand our medium and its strengths and weaknesses. What is so different about games? The answer is cliched and appears in a lot of dot-com business plans, but it's the truth: interactivity. The computer underlying all of our games offers us the ability to dynamically respond to the player, and that's something no other art form can touch. If interactivity is the key differentiator of our form, then it behooves us to understand it. I'm not going to step into the morass of defining interactive and noninteractive, and certainly not good interactivity versus bad interactivity, but it's clear that interactivity is inherently algorithmic at its core. There is a set of inputs (the current state of the world, the actions of the player, and so on), a system that decides what outputs to produce from the inputs (have an NPC kiss the player, have an NPC shoot the player), and a set of those outputs (the rendering of the smooch, a bit of text saying, "You're dead"). The algorithm that decides what to do at any given moment has to be described to the computer. Depending on the complexity of the algorithm, there are many ways of doing this, ranging from having some high-level visual flowchart system where designers connect boxes with inputs and outputs, all the way down to writing assembly code on a DSP. However simple these descriptions may seem, they're all computer programming, and this is the inescapable fact of embracing interactivity and games: You must tell a computer how to respond to the various inputs, and you tell a computer how to do things via programming. Getting back to the conventional wisdom that games shouldn't be founded on technology, if I regard "technology" as "programming," then games are founded on technology, as they must be. I'm not saying games should be founded on fancy graphics tricks, as is so often the case these days. However, designing and tuning the algorithms at the heart of the game how it reacts to the player and how proactive it is should be the fundamental task of game design. These algorithms determine how the game feels to play. Which leads me to my next heretical statement: Game designers must learn to program. Still with me? No, I don't mean that every game designer has to be a C++ wizard who dreams in curly braces, but game designers must be able to think and solve problems algorithmically and have a very clear understanding of what's easy and what's hard to do on a computer. Sure, game designers can tell programmers what to implement, but, as all programmers know, there's a world of difference between "what to implement" and "how to implement." The more vague the description of the "what," the more decisions get made during the "how." Those decisions directly affect the gameplay. The more precise the designer is with the description, the closer he or she comes to real programming, and the more control he or she has over the game design itself. Learning to think algorithmically is not a burden for game designers. On the contrary, it liberates designers from the whims of programmers. As my colleague Jon Blow once put it, programming is the last mile of game design. It grows to be much more than just the last mile when we begin to consider game designs that are not built of simple, hard-coded paths but are procedural by their very nature. Eventually, the graphics engine will not be a differentiating factor. All that will matter is the algorithms that make one game play differently from another. Those algorithms must be designed. To the game designers who want to do more than tune the damage a weapon inflicts, to designers who want to take games into the realm of interactive storytelling and richer emotional experiences, I say: Study up. The art form needs you.