Cabal Design Process

The Cabal is a design process for games that was used by Valve. There is a very interesting story that tells about this design process at http://www.gamasutra.com/view/feature/3408/the_cabal_valves_design_process_.php -- RalphJohnson

ca�bal (noun):: "the artifices and intrigues of a group of persons secretly united to bring about an overturn or usurpation especially in public affairs; also : a group engaged in such artifices and intrigues" [Merriam-Webster online dictionary, http://www.m-w.com/home.htm]

Some of my favourite quotes

"Since none of us believed that we were getting any closer to making a game we could all like, [...] we decided to start over and rework every stage of the game."

: One thing I've noticed that differentiates a game programmer from your average application programmer is that she actually plays her own game and consequently cares about the game. Moreover, game programmers play games on the weekend(and during lunch, after work, weeknights). I don't know many application programmers that tinker with payroll systems in their basements.
: See: PlanToThrowOneAway, ThrowOneAwayInPractice, RewriteCodeFromScratch
: See also: DogFood

"It became very clear the technology itself was only a small part of the work. Integration, training, and follow-through were absolutely necessary to make the technology useful to the game. Writing the code was typically less than half the problem."

: See: WholeTeam

"the Cabal process avoided most ... personal conflicts ... problems were identified in a relatively objective manner of play-testing, ... solutions were arrived at by consensus or at least by an individual peer, ... an authority that everyone could rebel against just didn�t exist."

: See: CodeOwnership -- this is a very compelling argument against it.

"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?"

: See ... umm, I dunno, maybe LimitsOfHierarchies ?

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.

: I love how Valve realizes that engineers are only a resource to solve a greater problem. The goal is to produce a game; engineers are only used to build tools that other people need to solve problems.
: See ... ProgrammingIsaSmallPart ...

I could go on, but I won't. Read the article.

(moved to ProgrammingIsaSmallPart )

During Cabal sessions, everyone contributed but we found that not everyone contributed every day.

I think this is an interesting quote and this design process is interesting given the discussion on ChiefArchitect. Games have a strong tendency to have single god-like designers. Strange that the game of the year for 1998 didn't. -- JasonYip

One of the interesting aspect of the projects process was that the process its self was very dynamic and evolved in parallel with the project, it starts off as ProcessLite? and evolves into a full ceremony process by the end, reminiscent of the SelectPerspective? and the CapabilityMaturityModel. --MartinSpamer.

Apparently Maxis also uses an iterative design process, http://gamespot.com/gamespot/stories/news/0,10870,2814094,00.html (BrokenLink 2004-11-15, but archived at http://web.archive.org/web/20011218210347/http://gamespot.com/gamespot/stories/news/0,10870,2814094,00.html).

Our design process at Maxis is very different from that of other studios, and that's how we've been able to create such hit products recently. The secret to our success is what we call an iterative design process, wherein we constantly reevaluate a specific game's design as we develop it.

(I like the name, "Cabal Design Process." I added the formal definition of the word "cabal," to be helpful. -- JeffGrigg ;-)

"We eventually got into the habit of placing a number of unrelated requirements into each area then doing our best to come up with a rational way to fit them together. Often, by the end of the session we would find that the initial idea wasn't nearly as interesting as all the pieces we built around it, and the structure we had designed to explain it actually worked better without that initial idea."

Tell me this would work in the real world, building applications for business or industry. Oy.

This would probably work about as well for consultingware as XP would work for programming games: that is to say, it would crash and burn. See http://www.joelonsoftware.com/articles/FiveWorlds.html and ExtremeProgrammingForGames.

"The final result was a document of more than 200 pages detailing everything in the game from how high buttons should be to what time of the day it was in any given level. It included rough drawings of all the levels, as well as work items listing any new technology, sounds, or animations that those levels would require.

"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."

Put that in your XP pipe and smoke it!

I think having a professional writer on staff counts as XP's user stories. Both have the needs of the user in mind, and know how best to achieve what they need.

Hmm. You may think that having a professional writer on staff "counts" as some part of XP, but that doesn't explain away the success Valve had with their design process and its completely different direction from XP. There are many processes in motion; some may not work too well, but others do fine. Extreme Programming is just one process in motion, folks. Cabal is another one. Both are successful to some degree. LiveAndLetLive?, eh?

You'll note that later they also state that that 200 page document was not sufficient to answer the 10 or so questions that came up about almost every item in that document. The document was in effect a promise of further discussion, a way to avoid completely specifying all 100+ levels until it was necessary to make forward progress. No, it wasn't user stories, but it was the same intent as a user story, coding standard, etc.

This might be a good thing to look at as far as scaling XP up, however.

For decades we've been doing programming alone in a cubicle. Then we discover PairProgramming works far better. A few people are experimenting TriProgramming (with exactly 3 programmers) and other PairProgrammingVariationsAndAlternatives. Perhaps this Cabal thing is the NextBigThing. I think the most interesting feature is that only half (?) of a particular Cabal are actual programmers. -- DavidCary

---

When I first came to this page I was expecting to find something on the CabalDesignProcesses? AntiPattern that feature in of some of the supposedly public standards design processes like W3C RFC's. Where if you are not part of the Cabal your contributions are simply ignored or even belittled. --MartinSpamer

The CabalDesignProcesses? (in this sense) also figure prominently in so-called free software and open software. What the hell is free about a cabal I have no idea.

CategoryGameProgramming CategoryCollaboration CategoryLeadershipPatterns