Does Knowing How to Program AI Help with Its Design?

Alex J. Champandard on January 15, 2008 is looking for sponsors to provide prizes (e.g. books, T-Shirts, software, games) for the best contributions to its weekly developer discussions. If you’re interested in trying this out for a month, don’t hesitate to contact me.

For most game developers, whether working in AAA studios or on independent games, finding a balance between design and code is a daily affair. It doesn’t have to be a struggle, but in practice, things can often get ugly!

On that subject, Grassroots Gamemaster posted an interesting comment recently [1]. Now, I try to read all comments on the blog as if their author was enlightened. Most often, I learn something new in the process! This one, however, was particularly difficult to wrap my head around:

“The problem with a programming focus is that it detracts from the core work of game design — which is… um… game design. Programming is not game design. Programming is interpreting game design into computer language. Game design is a different thing altogether.

It’s the same reason why film directors don’t operate the camera. It’s not their job. They have to direct the film. If they get lost in the technical details of photography it will distract them from what they are supposed to be doing.”

When Programmers Ruled the World!

Shortly after reading the comment, I stumbled upon this quote from Soren Johnson’s old homepage, who until recently worked as both a designer and a programmer for Fireaxis. (He’s now working on Spore along with approximately 25% of the employees at EA!) Anyway, here’s what he had to say:

“I was then given the opportunity to be the lead designer on Civilization IV while still writing the game and AI code. (Actually, in my mind, designing is easier if you are able to do the programming as well.)”

No doubt I personally see things from a very technical perspective, but I fully agree with Soren. It doesn’t only make sense to become technical for career purposes, but there are many other reasons I think it’s helpful for development too:

  • With AI technology today, non-technical people still have a very hard time creating anything useful on their own. Going beyond adjusting parameters requires coding skills.

  • When you work with your problem and solution directly, you become more creative in the same way a sculptor gets feedback from working with the clay. Right now, you need to know the underlying program to be able to do that.

This explains why all the best game designers today were coders in the past (Sid Meyer, Will Wright, Peter Molyneux, David Braben, etc.) It’s also the reason that the best independent games are made by coders who act as designers. As a counter example, Shigeru Miyamoto is not a programmer…

Is Technical Knowledge a Handicap?

From the other perspective, having very technical designers that don’t get involved with development can be a recipe for disaster! They can end up second guessing you despite not having touched the codebase since its creation… Then, if the programmer wants to make a change based on direct experience with the code, he/she may end up wasting time by arguing with the designers or worse, in a fruitless power struggle. (A surprisingly number of big studios witness these problems at some stage.)

That said, when designers are less technical, they have no choice but to delegate and not get too involved in the details. This in turn, can be much more fruitful, leaving them time to maintain the overall vision of the project. What do you think?

Does knowing how to code the AI help with its design? Does it help design the game as a whole?

Discussion 6 Comments

Andrew on January 15th, 2008

I'm sure there are arguments for both sides, but unlike film, TV and radio, game production and design still requires a lot of hands on work, not "direction". The designer [i]isn't[/i] a director at all, and in many cases, there are designers specific to an area - such as game statistics, levels, and cutscenes. And many film directors [i]do[/i] operate the camera - they do preliminary shots, train views on handycams, work with their camera crew to perfect their vision. They know the limits of film, the lighting needed, the problems with space or sets, because they do some of it! Poor directors don't know any of it and end up with rubbish, or at least need a very very persuasive camera crew. You might as well argue that the directors should not act in the films they direct - yet several have. Many lower budget ones also film some shots. I am sure Alfred Hitchcock's cameo's wouldn't happen in the perfect director-world? Or Orson Welles would have had another play Citizen Kane? So, the analogy is bad, and I think it's a valuable skill as any other would be to a designer - you might as well say they should never draw, never do music, never do level concepts, never do the writing since they "interfere" with the goal. The very best directors and designers understand all areas of their art, and since much of design can come down to scripting/programming, programming can be one area they suffer if they don't know - as much as many other areas. If they demand that the worlds be huge - yet don't realise that it'd require 4GB of memory to store all the dynamic information or somesuch limitation - they might fruitlessly stand by their vision while no one can actually implement it!

Doug on January 15th, 2008

I agree with Andrew. While you can take it too far the other direction (games written by programmers for other programmers ;)), doing any work without understanding at least the basics of the medium you are using is crazy. That said, I find your list of the best game designers today interesting. All of them date back to the 1990s (some to the 1980s). I wonder if the next batch of great game designers (or even the current ones) will come from such a programmer-heavy background.

RobinB on January 15th, 2008

Also, it is easy to see what you can and what you cannot do with a camera on a set, while this is an entirely different matter with programming, especially AI wise: It is often not easy to see for non-programmers what will be hard and what will be easy to implement for the AI/game mechanics; for a designer it might seem hard to always know what the shortest path to a point on the map is and on the other hand he might think that it shouldn't be too hard to give every NPC a unique emotional model. Ok, that example might be a bit over the top, but it is important to know what is possible/easy and what is not. (However, being open to new ideas is important too). Ah, and by the way: Stanley Kubrick often shot scenes himself for his movies!

ToddM on January 16th, 2008

I would agree with Grassroots Gamemaster that game design is not game programming. It requires different knowledge, a different focus and a different set of skills. People who are excellent programmers don't often make good game designers, and vice versa. It's rare to find people who are very good at both. But I think there's little question that although game design and game programming are very different, knowledge of one improves the other. Understanding the technical details of artificial intelligence programming informs the designer of implementation details, which can improve decisions in the design. Similarly, knowledge of game design issues can improve decisions in the implementation when programming. But I expect that good designers and good programmers already know this, at least subconsciously. Good programmers aspire to understand software architecture and design better, and good designers look to understand the technical and implementation details of their design. Therefore, to the extent that a designer can contribute to the implementation of her design is a good thing. And it is similarly beneficial for programmers to participate in the architecture and design of the software to the extent that they are able to contribute to it. However, I would still agree with Grassroots Gamemaster that getting lost in the technical details of the implementation would be detrimental to the designer. Just as getting lost in the design issues would be detrimental to the programmer. Both positions ideally require some freedom from each other, so that they can maintain a healthy perspective. The issues raised in the "Is Technical Knowledge a Handicap" section seem to resonate this. I suspect that the reason that great game designers of the past were also programmers, and that the reasons that your comments in "When Programmers Ruled the World" section ring true, is primarily a product of the historical evolution of game design. Game design and programming have historically been performed by the same people. Today's great game designers couldn't be other than yesterday's programmers. However, I agree with others that as game development continues to grow in complexity, leading to more and more specialization in development tasks, larger and larger development teams, and to more higher-level tools for development, tomorrow's game designers are a lot less likely to have as deep a technical background as yesterday's game designers. But I expect those who are good will still push down into the technical levels beneath their natural level of expertise, and to still gain similar benefits, even if they're not reaching down to as low a level as those before them. Of course, this is still a ways off. Today's best designers have also cut their teeth on the technical details of lower-level implementation, and are still active as programmers and architects for the most part. And there is still quite a bit of gray area in the definitions of roles on game development teams, and value to being proficient at more than one level.

diegix on January 21st, 2008

I partially agree with everyone. Personally I think there should be different stages in a game development. I think the designers shouldn't take into account technical constraints in the early stages of game design, generating the general idea of what the game should be and lots of ideas (some of them totally crazy and to be implemented in the next-next-next-gen). However when the game is close to be finished I think most of game design decisions must have the technical limitations very present and the designer will probably be able to refine the design better if they know what is possible and what's not. Having said that, I don't think being a programmer limits you as a designer or the other way around. However, having some programming skills gives you an structured thinking and working that designers usually don't have. This helps a lot to focus a meeting or a functionality review and get some results out of it. On the other hand designers tends to be more creative and think out of the box which is a desired characteristic also for programmers to solve things in a smart and creative way. IMHO, it's not that the better designers are the ones that once were programmers, but maybe it's easier that programmers are interested or have to do some work in design (either in their company or in personal projects) than designers start to program in C++. So the best designer is a good mix of both worlds and there are more programmers that has become designers than the other way around

Dave Mark on January 27th, 2008

I think some of this is genre-specific as well. If you take a "spreadsheet game" like a Civ 4 or even an RTS, much of the game design is actually unit design. Much of unit design is the mathematics of their abilities and how those abilities interact (e.g. combat). Laid over that is the AI of the units. Given those major points, values, math and AI, a lot of that needs to have a solid base in the programming aspect. If you are working an RPG, however, much of the design work is story, mood, ambiance, and interaction. Those fall solidly into the purview of designers rather than programmers.

If you'd like to add a comment or question on this page, simply log-in to the site. You can create an account from the sign-up page if necessary... It takes less than a minute!