Is Brainstorming Bad?

Yes. It is. Also, no. It isn't. How's that for cryptic?

We've been doing a lot of brainstorming at work lately and I figured I'd do a short little blog on brainstorming requirements, pitfalls, and an effective brainstorming style. Maybe someone can learn from all of the crap we had to iron out to get our process working effectively. Also as a *bonus*, I stole a sweet tip from author Jesse Schell about making lists. I won't touch on individual brainstorming (or thinking as it should be called), I'll only be talking about group efforts in this blog post.

Requirements

First, the definition :

Brainstorming - a conference technique of solving specific problems, amassinginformation, stimulating creative thinking, developing new ideas,etc., by unrestrained and spontaneous participation in discussion.

So what is required to begin brainstorming? Strictly from the definition, you need the following:

1. A specific problem set. Or, no specific problem set.

If there is certain problem(s) to be solved during the brainstorming session, it is very important to identify the problem set before you begin. Brainstorming is about spontaneous discussion and as such can easily become derailed if not refocused from time to time to be on subject.

On the other hand, if there is no specific problem to be solved, then it should be clear to everyone in the brainstorming session that there are no boundaries for spontaneity. This will prevent the stifling of ideas of others, no matter how absurd they might initially come across.

2. A group of two or more people

3. Unrestrained participation in the brainstorming session

A few other things you'll need aside from those mentioned in the definition:

1. A medium to record ideas with, preferably one that everyone in the brainstorming session can edit/view

2. An open mind

Everyone has ideas. Some are good, most are bad (including your own). The only way to effectively brainstorm is too get ALL of the ideas into the discussion and determine as a group which ideas are optimal solutions to the problem set. This means you must not discourage participation by hammering on an idea you might think is bad. Instead, think of ways to refine the idea into something that the entire group is happy with. Eventually, with enough processing, the bad ideas will be ironed out into good ones or discarded entirely.

Pitfalls

I figure its best to first talk about the problems encountered when brainstorming, then offer a particular style to help prevent some of these problems.

Blocking Ideas - The nature of brainstorming provides that one person may voice their idea to the group at any given time for any given time. Unfortunately, ideas that are being withheld to allow said person to speak can be lost if not expressed for an extended period of time.

Illusion of Productivity - Members of groups are likely to feel that their group is more productive than others. Also, individual members of a group tend to feel like they contribute more to the group than they actually do. For example, an article in the Journal of Personality and Social Psychology (and I won't bother to cite this wiki-fact properly) states that members of a group claimed to present 36% of the groups ideas on average when in fact they had only presented 25%.

Social Matching - This happens when individuals in a group feel that they are over-contributing (or under-contributing) to a group discussion because they are not "matching" the level of activity that another member of the group is. The group member tries to reduce their level of input to match the groups, therefor overall reducing their productivity. Unfortunately, this tends to happen to over-contributors far more often than under-contributors because over-contributing is much more noticeable and sometimes socially unaccepted.

The Ownership Dilemma - People are less likely to contribute ideas to a group because they are ultimately less proud of the result. Owning an idea is very fulfilling and it is lost when group communication is brought into play. This problem is generally overlooked as it isn't seen as detrimental to brainstorming sessions. While that may be the case, it certainly prevents people from maximally contributing to a session.

An Effective Technique

In no way is this a complete list of possible techniques used to effectively brainstorm. With a process as entirely malleable as brainstorming, no two groups will use the same techniques. Instead, this should serve as a foundation for brainstorming techniques that your group can use to build on.

Voting (closely related to nominal group technique, also combined with electronic brainstorming. This is how we brainstorm at Techtonic Games) - Voting on things can be tricky, but if done correctly it can effectively whittle down a pile of misshapen, disfigured crap ideas into a brilliant, chiseled, golden idea sculpture. The technique goes like this:

1. Everyone jots down a ton of ideas (keeping the problem set in mind, of course). Using a shared electronic document is a fantastic way to stay organized and work simultaneously.

2. The ideas are then "Distilled" which means voted on and reduced from large crap pile to small gold pile

3. If no ideas make it into the small gold pile, the group returns to step 1

4. Re-Evaluation of the gold pile of ideas is done as a group. Some ideas may be re-presented from the crap pile to be assimilated into the gold pile. Some ideas may be removed from the gold pile and tossed into the crap pile.

5. Ideas are voted on once more and trimmed down to only the best. Brainstorming now refocuses on expanding on the selected ideas.

What are the benefits of brainstorming in this manner?

Blocking of ideas is completely eliminated. Since everyone is presenting their ideas simultaneously, there is no waiting time where ideas can be lost.

Social Matching is partially combated. At least during initial idea development, there is no way for group participants to know how much each other group member is contributing to the session.

Increased Productivity. While I don't have a reference to cite for this fact, I can tell you from experience that this is true. Brainstorming sessions that involve this technique are four times shorter than ones that do not (from my guesstimates).

Hopefully this helps any producers / designers out there trying to organize their first brainstorming session.

Right, and the bonus tip (credit Jesse Schell): "Number Your Lists." It's that simple. Take a look at these two lists:

• Banana
• Woodcutting Axe
• Stealth Detector
• Ping Pong
• Hawaiian Shirt

1. Banana
2. Woodcutting Axe
3. Stealth Detector
4. Ping Pong
5. Hawaiian Shirt

Now which list could an item disappear from and you'd actually notice? Don't the items in the numbered list seem more important to the whole? If you were trying to talk about an item in each list, but you couldn't use the items name, how would you do it? Also, if you wanted to talk about a particular range of items in either list, how would you do that?  Interesting how that works...

No Feedback? No Game.

I just reread one of my favorite game design blog posts titled "The Chemistry of Game Design" by Daniel Cook. If you haven't read it over on Gamasutra yet, check it out.

It got me thinking about skill atoms and generally just about feedback loops in games. Designing challenging and complex systems is one thing, but without feedback the systems are fruitless. Content is great, but who cares how long a game can be played if the player cant measure their successes! Before I get into that though, here's a little information about feedback loops.

A basic feedback loop goes as follows:

- The player performs an action.
- The game responds to the action with a perceivable effect.
- The player deciphers the response from the game, ultimately deciding if their action had a positive impact in the game. This is where the player either has fun or fails to have fun (which is not directly dependent on success).
- Having learned from the action, the player performs another action.

Feedback is more important than most budding game designers realize. Removing a single element of feedback can break the enjoyment of a game entirely. The examples that can be given here are endless, I'll just hit a few.

Imagine playing Geometry Wars with no score indicator. How does a player measure their success if they can't tell they are improving?

How about your favorite MMO, only when you slay a monster it just stands there instead of playing a satisfying death animation. It doesn't drop loot either, you've simply accomplished the task of "winning."

It isn't always visual feedback that is important either. Imagine playing Call of Duty without any sound or damage indicators. How would you find out which direction you were being shot from? The game would be frustrating to no end!

The rewarding part of playing a game is just that - the reward. Whether it be a nugget of story, a few thousand points, or a shiny new skill atom to use to solve the next puzzle, without feedback you cannot have a fun or engaging game.

So how do you ensure that your game design has the appropriate level of feedback?

Make sure to think about each and every skill required to play your game. Be sure to draw diagrams (Skill Chains) and playtest after each new skill is iterated on. Ask yourself the following questions:

- What skills must the player learn to be successful in the game?

If you have trouble with this one, try listing all available actions for the player (Jump, Attack, Move, etc.). Then, for each action you list, create a sub-list of all the ways the skill can be used (Jump on to platforms, Jump to dodge projectiles, Jump to see over things). These are the "skills" that the player has to learn to complete tasks in the game.

- For each skill in the game, how can the player gauge if they are successful at that skill?

Players should be able to immediately understand if an action they took furthered their mastery of a system in the game. If there is no way to gauge how successful an action was, the action loses meaning and the player is likely to not repeat it.

- Which skills do you expect a player to have BEFORE they start playing your game?

In a perfect world of game design, an intelligent tutorial detects its users level of experience with similar games and adjusts itself to teach only the missing basic requirements before the player can jump into the game and start tackling meaningful and challenging objectives. Unfortunately, this isn't possible since your target audience is likely composed of players of varying levels of skill. What you can do though is design a skippable and repeatable tutorial that doesn't waste much time with "the very basics." Unless your game has complex navigation or an extraordinary control scheme, you shouldn't waste much time here. Maybe I'll do a blog on tutorial design later...

- When does a skill become repetitive and why?
"Burnout" is what happens to a player when they have mastered a skill and its use is no longer rewarding. Designers should try to identify when and how this happens and offer rewarding use of the skill beyond mastery when possible.

- How can feedback ensure a rewarding experience for continued use of a skill after mastery? 

Sometimes feedback alone can be enough to keep a skill rewarding enough to be used far beyond mastery. A good example of this is in "Costume Quest" by Double Fine Productions. The battle system in Costume Quest is a fairly simple, traditional turn-based battle system with not a whole lot of anything new. One thing that is fantastic about the system though, and I believe it to be what makes the system fun even though I have already  mastered the system long before playing Costume Quest, is that every time the player makes an attack or defends they are prompted to perform some button combination or timing event. If the player is successful, they make a much stronger attack or defend more damage. There is on screen feedback in the form of numbers and animation as well as audio feedback which is a pleasant chirp. What feels really good about this system is that, even though it is repetitive, there is constant positive feedback when the player is successful. It allows the player to gauge their use of learned skill and allows for reward far beyond burnout.

The most important thing to take away from this essay is this:

Players rely on feedback to judge their success at a game. Without feedback, even the most polished and intricate systems cannot be mastered and therefore are not rewarding for the player. A simple game with exceptional feedback is infinitely more fun than a complex and confusing set of rules that offers little to no feedback. Concentrate on designing good feedback for the simplest systems before moving on to more complex ones.

Thanks for reading!