By Ken Birdwell for Gamasutra, back in 1999:
By late September 1997, nearing the end of our original schedule, a whole lot of work had been done, but there was one major problem — the game wasn’t any fun. At this point we had to make a very painful decision — we decided to start over and rework every stage of the game.
The first incarnation of the game’s main character, now known affectionately as “Ivan the Space Biker”
Fortunately, the game had some things in it we liked. We set up a small group of people to take every silly idea, every cool trick, everything interesting that existed in any kind of working state somewhere in the game and put them into a single prototype level. When the level started to get fun, they added more variations of the fun things. If an idea wasn’t fun, they cut it.
When they were done, we all played it. It was great. It was Die Hard meets Evil Dead. It was the vision. It was going to be our game.
The second step in the pre-cabal process was to analyze what was fun about our prototype level. The first theory we came up with was the theory of “experiential density” — the amount of “things” that happen to and are done by the player per unit of time and area of a map. Our goal was that, once active, the player never had to wait too long before the next stimulus, be it monster, special effect, plot point, action sequence, and so on.
The second theory we came up with is the theory of player acknowledgment. This means that the game world must acknowledge players every time they perform an action. Our basic theory was that if the world ignores the player, the player won’t care about the world.
A final theory was that the players should always blame themselves for failure. If the game kills them off with no warning, then players blame the game and start to dislike it.
Valve then created a “Cabal” to tackle the game design. The goal of this group was to create a complete document that detailed all the levels and described major monster interactions, special effects, plot devices, and design standards. Cabal meetings were semi-structured brainstorming sessions usually dedicated to a specific area of the game.
During Cabal sessions, everyone contributed but we found that not everyone contributed everyday. The meetings were grueling, and we came to almost expect that about half of the group would find themselves sitting through two or three meetings with no ideas at all, then suddenly see a direction that no one else saw and be the main contributor for the remainder of the week. Why this happened was unclear, but it became important to have at least five or six people in each meeting so that the meetings wouldn’t stall out from lack of input.
Letting players see other characters make mistakes that they’ll need to avoid is an effective way to explain your puzzles and add tension and entertainment value.
We also ended up assigning one person to follow the entire story line and to maintain the entire document. With a design as large as a 30-hour movie, we ended up creating more detail than could be dealt with on a casual or part-time basis. We found that having a professional writer on staff was key to this process. Besides being able to add personality to all our characters, his ability to keep track of thematic structures, plot twists, pacing, and consistency was invaluable.
Practically speaking, not everyone is suited for the kind of group design activity we performed in the Cabal, at least not initially. People with strong personalities, people with poor verbal skills, or people who just don’t like creating in a group setting shouldn’t be forced into it.
Tips for a successful cabal
- Include an expert from every functional area (programming, art, and so on). Arguing over an issue that no one at the meeting actually understands is a sure way to waste everyone’s time.
- Write down everything. Brainstorming is fine during the meetings, but unless it’s all written down, your best ideas will be forgotten within days. The goal is to end up with a document that captures as much as is reasonable about your game, and more importantly answers questions about what people need to work on.
- Not all ideas are good. These include yours. If you have a “great idea” that everyone thinks is stupid, don’t push it. The others will also have stupid ideas. If you’re pushy about yours, they’ll be pushy about theirs and you’re just going to get into an impasse. If the idea is really good, maybe it’s just in the wrong place. Bring it up later. You’re going to be designing about 30 hours of game play; if you really want it in it’ll probably fit somewhere else. Maybe they’ll like it next month.
- Only plan for technical things that either already work, or that you’re sure will work within a reasonable time before play testing. Don’t count on anything that won’t be ready until just before you ship. Yes, it’s fun to dream about cool technology, but there’s no point in designing the game around elements that may never be finished, or not polished enough to ship. If it’s not going to happen, get rid of it, the earlier the better.
- Avoid all one-shot technical elements. Anything that requires engineering work must be used in more than one spot in the game. Engineers are really slow. It takes them months to get anything done. If what they do is only used once, it’s a waste of a limited resource. Their main goal should always be to create tools and features that can be used everywhere. If they can spend a month and make everyone more productive, then it’s a win. If they spend a week for ten seconds of game play, it’s a waste.
The Cabal: Valve’s Design Process For Creating Half-Life (via HN)
Sockrotation 