Part 5 of 10: Ivory Tower [previous parts]

In what may seem like a paradox, the most down-to-earth developers can be the most prone to Ivory Tower thinking.

When a project I worked on adopted the Design to Sell approach, one upside to it was that it prompted us to think about features in terms of cool uses. It’s amazing how creative anyone can become, as soon as you ask them to think of something "cool". We would hold informal meetings, during which we would share raw ideas, joking and laughing, writing down the best ones, because we couldn’t keep up writing down all of them. We would come up with pagefuls of notes anyway. Then a prototype would implement them with as little modification as possible. The resulting gameplay samples were, in most cases, awesome.

Some people did ask: “all right, guys, but how do we actually use all this stuff in the game?”. But this question was judged to be too abstract. Generally speaking, it’s fairly easy to engage people in a conversation about game mechanics, but discussing its dynamics seems to be too much for most. Anyone can have dozens of good ideas, but few can see how those ideas fit together, especially when you discuss a general principle, rather than a specific instance.

The resulting problem we experienced was similar to the issue which haunted the project that was "designed to succeed". In theory, players could do lots of cool stuff, but it wouldn't show up in actual gameplay, for a variety of reasons. Some of our ideas were special cases. Some were too specific and thus not replicable. Some were impractical, as in performing a difficult 30-hit combo when you can just drop a nuke on someone’s head. Some didn’t seem to match the setting; for instance, we had many ideas involving misuse of heavy industrial equipment, but we didn’t have industrial facilities in that game. In short, those were all cool ideas, but they didn’t fit.

The problem with Ivory Tower is that it makes perfect sense under given set of assumptions, but the assumptions don’t hold in practice. Our error was to assume our ideas could sustain themselves, rather than requiring us to support them with proper design.

What we needed was a kind of user’s manual for level designers. An example guideline we needed to develop was something like this: “here’s a cool sniper rifle; but when you put it in a level, you also need to provide large open areas with enemies appearing at long distances”.

We didn’t do that, and not every idea was as straightforward as a generic sniper rifle, so most of them never lived past the prototype stage. In a way, they stayed “on paper”. Ironically, we didn’t explore their usability, because it was an abstract problem that seemed like a case of Ivory Tower thinking.

Lesson Learned: Anyone can have a good idea. The trick is to know what to do with it. Exploring and developing usage patterns is a vital part of a feature’s prototyping process.