Gamasutra: The Art & Business of Making Gamesspacer
The Cabal: Valve’s Design Process For Creating Half-Life
View All     RSS
October 25, 2014
arrowPress Releases
October 25, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

The Cabal: Valve’s Design Process For Creating Half-Life

December 10, 1999 Article Start Previous Page 3 of 4 Next

Pearls Before Swine

By the second month of the Cabal, we (the "swine") had enough of the game design to begin development on several areas. By the third month, we had enough put together to begin play testing.

A play-test session consists of one outside volunteer (Sierra, our publisher, pulled play-testers from local people who had sent in product registration cards for other games) playing the game for two hours. Sitting immediately behind them would be one person from the Cabal session that worked on that area of the game, as well as the level designer who was currently the "primary" on the level being tested. Occasionally, this would also include an engineer if new AI needed to be tested.

Other than starting the game for them and resetting it if it crashed, the observers from Valve were not allowed to say anything. They had to sit there quietly taking notes, and were not allowed to give any hints or suggestions. Nothing is quite so humbling as being forced to watch in silence as some poor play-tester stumbles around your level for 20 minutes, unable to figure out the "obvious" answer that you now realize is completely arbitrary and impossible to figure out.

This creature was initially designed as a friendly character, but play-testing revealed players’ tendencies to shoot first and ask questions later.

This was also a sure way to settle any design arguments. It became obvious that any personal opinion you had given really didn’t mean anything, at least not until the next play-test session. Just because you were sure something was going to be fun didn’t make it so; the play-testers could still show up and demonstrate just how wrong you really were.

A typical two-hour play-test session would result in 100 or so "action items" — things that needed to be fixed, changed, added, or deleted from the game. The first 20 or 30 play-test sessions were absolutely critical for teaching us as a company what elements were fun and what elements were not. Over the course of the project we ended up doing more than 200 play-test sessions, about half of them with repeat players. The feedback from the sessions was worked back into the Cabal process, allowing us to preemptively remove designs that didn’t work well, as well as elaborate on designs that did.

Toward the middle of the project, once the major elements were in place and the game could be played most of the way through, it became mostly a matter of fine-tuning. To do this, we added basic instrumentation to the game, automatically recording the player’s position, health, weapons, time, and any major activities such as saving the game, dying, being hurt, solving a puzzle, fighting a monster, and so on. We then took the results from a number of sessions and graphed them together to find any areas where there were problems. These included areas where the player spent too long without any encounters (boring), too long with too much health (too easy), too long with too little health (too hard), all of which gave us a good idea as to where they were likely to die and which positions would be best for adding goodies.

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.


Another thing that helped with debugging was making the "save game" format compatible between the different versions of the engine. Since we automatically saved the game at regular intervals, if the play-testers crashed the game we would usually have something not too far from where they encountered the bug. Since these files would even work if the code base they were testing was several versions old, it made normally rare and hard to duplicate bugs relatively easy to find and fix. Our save game format allowed us to add data, delete data, add and delete code (we even supported function pointers) at will, without breaking anything. This also allowed us to make some fairly major changes after we shipped the game without interfering with any of our players’ hard-won saved games.

No Good Deed Goes Unpunished

Until the Cabal process got underway, technology was added to Half-Life freely. It was assumed that "if we build it, they will come," meaning that any new technology would just naturally find a creative use by the content creation folks. A prime example of this fallacy was our "beam" effect, basically a technique for doing highly tunable squiggly glowing lines between two points; stuff like lightning, lasers, and mysterious glowing beams of energy. It was added to the engine, the parameters were exposed, and an e-mail was sent out explaining it. The result was … nothing. After two months only one level designer had put it in a map. Engineering was baffled.

During the Cabal process, we realized that although the level designers knew of the feature, they really had no clear idea of what it was for. The parameters were all very cryptic, and the wrong combinations would cause the beams to have very ugly-looking effects. There were no decent textures to apply to them, and setting them up was a bit of a mystery. It became very clear the technology itself was only a small part of the work and 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.

Article Start Previous Page 3 of 4 Next

Related Jobs

Digital Extremes
Digital Extremes — LONDON, Ontario, Canada

University of Central Florida, School of Visual Arts and Design
University of Central Florida, School of Visual Arts and Design — Orlando, Florida, United States

Assistant Professor in Digital Media (Game Design)
The College of New Jersey
The College of New Jersey — Ewing, New Jersey, United States

Assistant Professor - Interactive Multi Media - Tenure Track
Bohemia Interactive Simulations
Bohemia Interactive Simulations — Prague, Czech Republic

Game Designer


Arturo Nereu
profile image
I loved the concept of your Cabal.

I think that group design (involving the main areas of the development team) is a good way to:

- keep everyone on the same track

- hear ideas from everyone even if they are not game designers.

Thanks for sharing!

Bernie M
profile image
Half-life was a success because it had a story. And a very geek friendly at that: LHC getting loose, playing a badass nuclear scientist. Other Quake clones did not. Even Unreal was lame with little to no background story but fortunately Tim Sweeney could transform Epic Megagames into a middle-ware company.

Anyway, good job Valve!

paolo marino
profile image
Great article, thanks.

I'd love to be able to see (even just a portion of) the Cabal brainstorming notes and of the final design document to better understand the "format" you used to capture so many elements on paper (and make these understandable to others).

Any chance for that?

Arnaud Begue
profile image
Same here.

It's a really good article. I'm pretty young in the video game industry and that kind of stuff will be really useful for me, so if you can provide an example to see more in detail the organization of the Cabal, it will be really great.

George Menhal III
profile image
Besides Half-Life 1 & 2 and Portal, I think Valve's games are overrated.

I still think Half-Life 1 is the best game they ever made.

Gavin Clayton
profile image
I remember reading this over lunch break when I was in my mid 20s. Still a great article but thanks for making me feel old, Gamasutra. ;)

Alvaro Vazquez de la Torre
profile image
Thanks a lot for the article, Ken, it's quite useful!

I can add an element to be aware of to this 'Cabal' structure. In Ryse Son of Rome we tried a similar approach at the beginning, but it wasn't successful. Aside from other reasons, having a fixed delivery date (Xbox One launch title) was the process killer. The people involved on the mission groups, as we called them, were so concerned about the lack of time that focused solely on their respective discipline checklists. Eventually only level designers pushed for quality.

Vincent Pride
profile image
It's really hard to imagine design by committee working all that great. If Valve talents are so good and able to get such interesting and award winning games done in groups, I can only imagine what masterpieces every single one of them could create as an indie.

Nikolay Kushnar
profile image
> 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

The woe of every Fortune 500 company meeting I've been to.