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. We weighted
our groups heavily toward people with a lot of group design experience,
well ahead of game design experience. Even so, in the end almost everyone
was in a Cabal of one sort or another, and as we got more comfortable
with this process and started getting really good results it was easier
to integrate the more reluctant members. For current projects, such
as Team Fortress 2, the Cabal groups are made up of 12 or more
people, and rarely fewer than eight. The meetings ended up being shorter,
and they also ended up spreading ideas around a lot quicker, but I’m
not sure I’d recommend that size of group initially.

Just about
everything in Half-Life was designed by a Cabal. This at first
seemed to add a bit of overhead to everything, but it had the important
characteristic of getting everyone involved in the creation process
who were personally invested in the design. Once everyone becomes invested
in the design as a whole, it stops being separate pieces owned by a
single person and instead the entire game design becomes "ours."

This "ours"
idea extended to all levels. Almost every level in the game ended up
being edited by at least three different level designers at some point
in its development and some levels were touched by everyone. Though
all the level designers were good at almost everything, each found they
enjoyed some aspect of level design more than other aspects. One would
do the geometry, one would do monster and AI placement, our texture
artist would step in and do a texturing pass, and then one would finish
up with a lighting pass, often switching roles when needed due to scheduling
conflicts. This became critical toward the end of the project when people
finished at different times. If a play-test session revealed something
that needed to be changed, any available level designer could make the
changes without the game getting bottlenecked by needing any specific
individual.

By
placing traditional combat action in more challenging environments
we were able to intensify the feeling of tension and suspense.

This idea
also extended to all code, textures, models, animations, sounds, and
so on. All were under source control and any individual was able to
synch up to the sources and make whatever changes were necessary. With
a little bit of self–control, this isn’t as random as it sounds. It
had the added benefit in that it was fairly easy to get a daily record
of exactly what was changed and by whom. We would then feed this information
back into the play-test cycles, only testing what had changed, as well
as helping project scheduling by being able to monitor the changes and
get a pretty good estimate of the stability and completeness of any
one component. This also allowed us to systematically add features throughout
the process with minimal impact. Once the technical portion was completed,
the engineer assigned to the feature was able to synch to all the source
artwork and rebuild any and all files (models, textures, levels, and
so on) affected by the change.

The
Workers Control the Means of Production

Even with
all emphasis on group activity, most of the major features of Half-Life
still only happened through individual initiative. Everyone had different
ideas as to what exactly the game should look like, or at least what
features we just had to do. The Cabal process gave these ideas a place
to be heard, and since it was accepted that design ideas can come from
anyone, it gave people as much authority as they wanted to take. If
the idea required someone other than the inventor to actually do the
work, or if the idea had impact on other areas of the game, they would
need to start a Cabal and try to convince the other key people involved
that their idea was worth the effort. At the start of the project, this
was pretty easy as most everyone wildly underestimated the total amount
of work that needed to be done, but toward the middle and end of the
project the more disruptive decisions tended to get harder and harder
to push through. It also helped filter out all design changes except
for the ones with the most player impact for the least development work.

Placing
the player in a
soldier-vs.-alien conflict
helped reinforce the illusion
of an active environment,
and let Valve show off
its combat AI with minimal
risk to the player.

Through
constant cycle of play-testing, feedback, review, and editing, the Cabal
process was also key in removing portions of the game that didn’t meet
the quality standards we wanted, regardless of the level of emotional
attachment the specific creator may have had to the work. This was one
of the more initially contentious aspects of the Cabal process, but
perhaps one of the more important. By its very nature, the Cabal process
avoided most of the personal conflicts inherent in other more hierarchical
organizations. Since problems were identified in a relatively objective
manner of play-testing, and since their solutions were arrived at by
consensus or at least by an individual peer, then an authority that
everyone could rebel against just didn’t exist.

On a day-to-day
basis, the level of detail supplied in even a 200-page design document
is vague at best. It doesn’t answer the 1,001 specific details that
each area requires, or the countless creative details that are part
of everyday development. Any design document is really nothing more
than a framework to work from and something to improve the likelihood
that work from multiple people will fit together in a seamless fashion.
It’s the Cabal process that helped spread around all the big picture
ideas that didn’t make it into any document —things that are critical
to the feel of the game, but too nebulous to put into words. It also
helps maximize individual strengths and minimize individual weaknesses
and sets up a framework that allows individuals to influence as much
of the game as possible. In Half-Life, it was the rare area of
the game that didn’t include the direct work of more than ten different
people, usually all within the same frame.

In order
for highly hierarchical organizations to be effective, they require
one person who understands everyone else’s work at least as well as
the individuals doing the work, and other people who are willing to
be subordinates yet are still good enough to actually implement the
design. Given the complexity of most top game titles, this just isn’t
practical — if you were good enough to do the job, why would you want
to be a flunky? On the other hand, completely unstructured organizations
suffer from lack of information and control — if everyone just does
their own thing, the odds that it’ll all fit together in the end are
somewhere around zero.

At Valve,
we’re very happy with the results of our Cabal process. Of course, we
still suffer from being overly ambitious and having, at times, wildly
unrealistic expectations, but these eventually get straightened out
and the Cabal process is very good about coming up with the optimal
compromise. Given how badly we failed initially, and how much the final
game exceeded our individual expectations, even our most initially reluctant
person is now a staunch supporter of the process.

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.

The
first incarnation of the game’s main character, now known
affectionately as
"Ivan the Space Biker."

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.

Ken
is senior developer at Valve and has contributed to a wide range of
projects in the last 15 years, most recently on animation and AI for
Half-Life. Previous projects include satellite networking, cryptography,
3D prosthetic design tools, 3D surface reconstruction, and in-circuit
emulators. Oddly enough, Ken dropped out of studying EE to pursue a
fine arts degree at The Evergreen State College, which he considers
far more relevant to creative thinking than any silly differential equations
class. You can reach him at kenb@valvesoftware.com.