Interface or Yummy Candy?


There are some things that we can (almost) all agree belong to the realm of Interface. That is, the experience should be as low-profile as possible because no-one wants to interact with that experience itself. It is just a necessary evil we have to go through in order to get to the thing we actually want (the Yummy Candy).


The process of using the mouse and keyboard in tandem in order to get these words on the web site is a good example. If I could make it so, the process of getting my thoughts to the web site would be instantaneous and invisible to me. The Yummy Candy payoff is having expressed my idea.


If you could perfectly determine on a given project what should be Interface, and what should be Yummy Candy, that would vastly clarify many design decisions. Problem is, people differ even on that most fundamental level.


Playing Age of Empires, I thought that having to micromanage the villagers was Yummy Candy. In my mind, a significant parameter of the game competition was managing one's own attention, and keeping track of everything under pressure. Many others thought this was Interface, and so the sequels featured build cues and more intelligent villager behavior.


An even more extreme case is MOO3, where the design comes close to relegating almost every decision to the Interface category, so that it is possible to win just by clicking the "Next Turn" button over and over. I see what they were trying to do. They wanted people to be able to go after whatever Yummy Candy they each individually wanted to go after, and leave the rest to Interface. Maybe it was just the specifics of implementation that made it fall flat.


Is hitting the piñata just an Interface to the candy inside? For some, yes, and for some, no. Just try your best to assure that you're not making people bang on your Interface over and over before they get any of your game's Yummy Candy to fall out.

Orthogonal Game Elements

A criteria for good game design which seems obvious but is easy to forget in the heat of brainstorming. Fight games forget this all the time, by adding more attacks instead of coming up with ways to multiply the potential of the game. The reason I mention it was I was browsing Ion Storm's web site yesterday and Harvey Smith gave the subject a thorough going over.

The Jamie Test - Step 11

Build Consensus

Going ahead a few steps. Chris's post - which, incidentally, seems to have doubled our readership (Go Chris! I hope your career will survive being blacklisted by Derek Smart) - got me thinking some of the same old thoughts.

I had an English teacher in high school who told us that nothing good ever came out of a committee. This woman also told us that the human body undergoes a weight loss immediately after death -- no doubt the departure of the soul -- and that she was visited by Jesus in her bathroom. Still, she isn't alone in her thoughts; a lot of people look down their noses at 'design by committee.'

I was reading the same post-mortem that Chris read, which talked about the failure of 'design by committee.' I think the wrong lesson is being learned here; much like when you're playing Texas Hold 'Em and you decide not to draw to the inside straight and, lo and behold, the inside straight comes up, and you rebuke yourself, and you say next time I'm going to draw to the inside straight. Wrong lesson. The project in question had a number of problems and 'design by committee' was not what sunk it. This was a project in which a lot of the team members knew the project was in trouble the whole time. If there was any 'design by committee' going on, either these members of the team weren't on those committees, or the committees were not effectively building consensus.

There's a number of ways committees can fail:

Wrong people making the decisions. (Wrong people in the committees.) Frequently you'll have a group of managers as the only ones making decisions and they forget to include the people who are actually going to do the work and know their jobs. So you're handing out job assignments to people who haven't bought in to those assignments in the first place. (I saw this in action with Minority Report. I happened to be in the room when a programmer didn't want to implement a design his boss was suggesting. The boss said, "The consensus is we should do it this way." I said, "It's not consensus if the programmer doesn't agree." "I meant it's the consensus of the leads," the boss said. This was one minor point that surely was not to blame for Minority Report's failure, but if every single aspect of the project was handled that way it could be a problem.) Another possibility, the client (usually the publisher) is not in on the committees either, and will try to control the project retroactively. And finally, people join the team after decisions have already been made; do you rehash all the decisions up to this point? Or do you just shove the old decisions down their throats?

Fear of hurting each other's feelings. At some point, brainstorming has got to end, and hard decisions have to be made, otherwise you will end up with bloatware, as every single person's pet feature is put into the game. It probably is the real problem that the people were complaining about in that post-mortem I mentioned; it's also a problem that we experienced on the team I work on. Our original design document outlined whole systems of features that were tangential to the focus of the game - not quite toasters for cars but headed in that direction. The only thing that got those features cut was that we ran out of time. If we'd been more vigilant in our design, we could have cut sooner, and the resources that did go into those features could have been spent more usefully.

False consensus. Drucker talks about the social experiment where a group of people, in a circle, are asked if two different lines are the same length. Every member of the group but one is a plant; they agree that the different lines are the same. When it gets to the test subject, he almost always caves and agrees with the rest of the group. This phenomenon is what allows a whole group of people to collectively agree on the same bone-headed decision.

Not the best ideas The ideas that go in are not the best ideas but the pet ideas of the most persuasive people. (Often the most persuasive people will be people in lead positions, granted a sort of unconscious bias.) According to Carnegie, persuasion has little to do with the 'rightness' of your argument, and more to do with how you argue.

Nothing gets done Spending eternity in meetings without doing any actual work. When thesis and antithesis compete, it takes a while to come up with synthesis. At the beginning of our latest project we spent half our time in meetings for the first few months. I think the time was well spent but one could argue that we'd have more to show if we just dove in and started making stuff.

That's quite a list, so you may want to switch to The Boss Decides method of making decisions. What this gets you is a trade-off: you're less likely to be bitten by the "fear of hurting other people's feelings" problem and the "nothing gets done" problem, but you're more likely to be bitten by the "false consensus" problem (a bone-headed consensus of one) and the "wrong people making the decisision" problem and the "ideas are not the best ideas but the ideas of the most persuasive." (In this case, the boss.) In my opinion, the fact that you now have someone Responsible running the show, whom you can fire when he fucks up, doesn't really make up for the fact that you've increased the likelihood of fucking up.

My suggestion is this: if you are in a leadership position, take the risk of abandoning yourself to consensus building. (It's hard. There have definitely been times where everybody except me wanted to do one thing and I insisted on another. I now feel that the correct thing for me to do in those cases was keep hashing it out until we achieved synthesis.) If you're not in a leadership position, make yourself heard and try to encourage others on your team to be heard as well.

How do you build consensus? There's a short guide here that I just found via Google. And if you want it spelled out in excruciating detail, and don't mind wacky space cadet stuff, then take a look at the McCarthy's "Decider Protocol" in their Core system here.

These systems solve items 2 through 4, and make some effort to mitigate item 5. What they do not solve is having the wrong people in the meetings. (Our programmer team rapidly achieved consensus when we proposed that we should all get more RAM. There was nobody from budgeting or purchasing in the meeting.) This is a problem I do not yet know how to solve. Must research.

If you still think 'design by committee' is a bad idea, consider this: like Chris said, the Half-Life guys did it. But they took three years to ship, you point out. Well how about this: the Deus Ex guys did it. In my opinion, Deus Ex is the biggest success story in all of recorded videogame development: quality delivered in a timely manner on a reasonable budget. From their post-mortem:

Should you get to name your character or not? A holy war almost broke out on the Deus Ex team about this. "If you can't name your character, it's not an RPG," said some. "If we don't name the character, how do we write and record compelling conversations and create a cool story?" said others. "Story isn't the point…" "Yes, it is…" and on and on and on. We compromised: we gave the player character a code name and back-story but let the player select his real name, which came into play in various ways (though never in speech).

Not a compromise at all, but synthesis. They practice consensus. And so should we.

Chris would say something like, "You're missing my point, Jamie. I never said design by committee was bad, I just said there has to be someone with whom the buck stops." I would argue that since, the world of business being what it is, buck stopping people are built into the system. Whoever your pimp is, they're going to want to know who the "one in charge" is, and that person is going to be considered responsible for the results of the entire team. What concerns me is this unhealthy fascination we have for the org chart. The system wires us to spend a lot more time thinking about who is in charge than we should. Because the system does this to us, and because at some level we like it (who doesn't want to see a nice fat "Technical Director" credit on the game they shipped?) we need to fight this tendency to actually make a true consensus happen. Don't worry about figuring out who is in charge of whom; worry about figuring out how to get the best ideas into your game.

Site Name Change May Be In Order

Saw a movie poster for League of Extraordinary Gentlemen yesterday. They're calling it LXG. LXG??? LXG?!?!?!?! What the fuck? What the fucking fuck? Looks like some marketing suit out there thinks they're making an X-Men thing. I guess after From Hell, I shouldn't be surprised by the butchering of Alan Moore's work. But God! Some people just don't Get It. I say to whoever is making that movie: Good job. You've alienated your hardcore fans and probably the casual moviegoing audience as well.

And now our thirty or so loyal readers will be associating this site with a lame movie instead of a cool comic book.