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 -- 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,]

Some of my favourite quotes

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

See: WholeTeam

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

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

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,,10870,2814094,00.html (BrokenLink 2004-11-15, but archived at,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 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

View edit of December 13, 2014 or FindPage with title or text search