This article originally appeared in the November 2005 issue of Game Developer magazine.

While building Half-Life, which shipped in November 1998, Valve created a method of decentralized design called the Cabal Process (described in this article on Gamasutra), which used a small cabal of a few people from various disciplines to tackle the design.

Classic Postmortem: The making of Half-Life 2

on Gamasutra), which used a small cabal of a few people from various disciplines to tackle the design. Needless to say, when design began on Half-Life 2, we had great interest in applying the same structure and principles to its development, too. However, the greater scope of the sequel posed some problems for the Cabal Process, so we had to tweak it until it worked for us again. This article discusses the revised Cabal Process used to make Half-Life 2.
PROJECT SCALING

Half-Life 2 was a project with ambitious goals. We nearly tripled the team size, and embarked on a huge technology push on all fronts. Acting, physics, AI, sound, rendering, and networking systems were all built from scratch. During the technology push, an expanded version of the original Half-Life cabal met for months, attempting to create a complete design document similar to the first one. Design work during the early phase of development progressed very slowly because we found it difficult to predict what kinds of designs our technology would enable once it was finished. To make matters worse, the resulting design relied on many game elements that were purely theoretical.

By the time the Source technology had matured, we found ourselves in a position similar, in some ways, to where we were at the start of the Cabal Process for Half-Life , but very different in others. In terms of design, we were better off. We had a full story timeline, detailed story snippets, all the major character profiles, a set of locations and drawings, and a fairly clear idea of what technology we would have for the final game. In terms of production, though, we only had a bunch of raw material in the bank: some weapons, some cool monsters (and some not-so-cool monsters), and pieces of interesting levels. However, as with Half-Life , at this stage of development, the technology was not being taken advantage of. You couldn’t play the game all the way through, and none of the levels were tied together in a coherent fashion.

Once we knew what our engine could do and had enough raw material in the bank to use as constraints to drive the design, the Cabal Process began to work as efficiently for us as it had during the development of Half-Life .

The problem now was, given the much larger scale of the game and larger number of people working on the project, the Cabal Process itself became a bottleneck. It couldn’t produce content fast enough. As a result, we created three nearly independent design cabals, each responsible for designing and producing roughly one-third of the game, plus dedicated cabals for art, sound, and acting.

BACK IN THE SADDLE AGAIN

Each cabal consisted of four or five people, half level designers and half programmers. While developing Half-Life , we decided that this was the ideal size. Larger cabals resulted in diluted design meetings and smaller ones risked a dearth of ideas. We included both programmers and level designers because most design iteration occurred through changes to AI, game code, or levels. Each cabal also included one engine programmer who would develop new technology required by the designs. For productivity reasons, we wanted each team member to have a “demanding customer” on the same cabal, someone who consumed that person’s work. Level designers were customers of programmers in that they used the gameplay elements and AI created by the programmers. Programmers were customers of level designers in that they needed levels as a venue to refine their code. The members of each cabal shared an office to reduce communications overhead and, as we discovered, improve prioritization. People were far less likely to get sidetracked by non-critical tasks if their teammates sat nearby to serve as instant triage.

The Half-Life cabal included artists and a writer, whereas Half-Life 2 ’s multi-cabal structure prompted us to treat artists and writers as shared resources. We created an art team, an acting team, and a sound team (actually just a single sound designer). The art team collaborated with the design cabals on the look of the environments, monsters, and characters in the early stages of development and made the levels look great once the gameplay in those levels was stable. The sound team worked with the design cabals to produce stand-in sounds during gameplay prototyping and to create a final sound treatment of the levels after the design stabilized. The acting team collaborated with the design cabals to seed levels with mission goals and story rewards, and they produced any animations the levels required. The acting team also served as an independent fourth design cabal for the storyheavy sections of the game, such as Kleiner’s Lab, Black Mesa East, and Breen’s chamber.

Despite the large structural changes to the Cabal Process, there still were many aspects of the original process (as described in our previous article) that remained intact. The way each cabal generated designs remained largely unchanged. We preserved our edict, “He who designs it, builds it,” in the belief that the best designs are influenced by the realities of production. People who are very cognizant of all the tradeoffs inherent to a given implementation are going to make better design choices. We continued to discourage a sense of sole ownership because we believe that having more hands on a given section of the game ultimately produces higher quality. Our playtesting techniques remained the same, and we continued to use them as a way to settle design arguments. As with Half-Life , the cabals were completely responsible for meeting the quality standards in the levels they owned.

The result was that we had six teams, all of whose work—models, materials, sound, animation, lighting, story, and game design— had to come together in the levels themselves.Clearly, managing this process was going to be tricky but essential for us to succeed.

There were some obvious problems, of course. How would we manage and reduce the cost of the many interdependencies between our six teams? How would we allow every team to apply important constraints to the design? How would we create a consistent design and level of quality in the face of three independent design teams? These problems were eventually solved on a case-by-case basis.

KEYFRAMING PROSE

Half-Life 2 contains more than three hours of acting, and recording the dialogue for these scenes wasn’t always easy. In some cases, it required flying to Los Angeles, exploiting a limited window in an actor’s busy schedule, and using a fixed number of studio sessions, after which we would be on our own. In an ideal world, we would have gone through a more traditional screenwriting process, but that would only have been possible if we knew in advance where our game design process was going to take us. We couldn’t leave all the acting until the end because then there wouldn’t be enough time to improve it; so story and gameplay had to develop concurrently.

At first, the two seemed inextricably linked, which presented an interesting challenge: How would we give the gameplay cabals, whose process (and result) was fluid and unpredictable, the freedom to experiment while presenting a stable enough framework on which we could hang a story? We eventually settled into a process whereby story provided keyframes that served to constrain the game design. For example, in designing the Route Kanal and Water Hazard chapters, we knew the player would start on the run from City 17 forces outside Kleiner’s Lab and finish at Black Mesa East, far from City 17. The story elements that fell between those two story keyframes were purposely left vague until later in the process when the gameplay had solidified. As long as the gameplay cabal satisfied the constraints of the story keyframes, the cabal was free to take the gameplay in whatever direction seemed most promising without fear of leaving the story in an untenable position.

Once a chapter’s gameplay was finalized, the responsible gameplay cabal and the acting cabal met to draw up a list of places within the chapter where story elements could be added. Some were required by the gameplay, such as the delivery of short-term mission goals or the explanation of a game mechanic. Others were important for the story or for player motivation, such as the reinforcement of a larger overarching goal (like reminding the player that they had to get to Eli’s during Route Kanal). Finally, some were story-based rewards that served to enrich the player experience. Even with this process, the story still had to be supple enough to respond to unexpected gameplay demands, such as when Ravenholm moved from before Black Mesa East to after, once the potential of the gravity gun to enhance Ravenholm was realized.

INSIDER ART

The art burden of Half-Life 2 was an order of magnitude greater than that of Half-Life . Half-Life 2 used more than 3,500 models, nearly 10,000 materials, and individual maps as big as 20MB (compared to Half-Life ’s 300 models, 4,000 materials, and 3MB map files)—a tremendous investment in visual quality. In order to produce this many art assets with a relatively small team of artists, we had to optimize the art production pipeline and insulate it from gameplay changes as much as possible.

The art production for a chapter began with the creation of concept sketches, which were developed early in the cabal’s design process once the general setting was established. In many cases, the concepts were developed even earlier based on the broad story design, in which case they served to inspire the game design. Once the concepts and gameplay were deemed compatible, the concepts were developed into styleguides— maps devoid of gameplay that would serve as a template for building final production maps. The styleguides both influenced and were influenced by gameplay prototypes that were developed simultaneously. For example, the buggy’s handling characteristics influenced the scale of the coastal landscapes in which it was used and vice-versa.

AGENT ORANGE

Initial gameplay prototyping for each chapter took place on orange maps. Orange maps use an orange grid texture for walls and a gray one for floors and ceilings, and using them solved a number of issues we ran into early on.

First, it prevented level designers from investing in the art for an area before the core game mechanics had been validated through playtesting. Effecting this practice dramatically reduced the iteration cost and avoided any early commitment to the look of an area. It also solved the problem of prematurely critiquing art when team members were supposed to be critiquing a gameplay prototype. Finally, it allowed the art team more freedom to experiment with visual themes, since they could do so independent of the gameplay prototypes.

Successful gameplay prototypes and styleguides were used as the basis for building the final levels. Once those playtested successfully, they were handed off to the art team for an art pass. During the art pass, all level designer-created stand-in geometry was replaced by final models. Final materials were applied to the level, lighting was adjusted or recreated from scratch, and auxiliary elements, such as fire, fog, and skyboxes, were added.

Through this process, the playable level was made to more closely match the vision of the original concept art without breaking the gameplay. In practice, though, gameplay did sometimes break in unexpected ways, such as when playtesters refused to walk on a large suspension bridge once a realistically thin-framed model replaced the chunkier, level designer-created predecessor. Because of this inherent dependency between visual design and the communication of game mechanics, the design cabals always held playtests after the art pass to verify that gameplay still worked.

SYMBOLIC LINKS

To allow multiple teams to work simultaneously on a single level without causing stalls, we tried as much as possible to structure our tools around independent files that were connected by a system of symbolic links. Symbolic links are human readable references, resolved at runtime, that both code and content use to refer to another code or content resource. For example, we replaced direct references to raw sound files in our maps with names of entries in a sound script file instead. Each entry in the script file specified such variables as pitch, volume, and random file selection for the sound. This allowed our sound designer to replace or modify sounds without affecting level designers. Before we had symbolic links, level designers had to hand off maps to the sound designer and not work on them until the sounds were finished. Also, by using level-specific sound names for level-specific sounds, the sound designer could change sounds without disturbing other maps.

Our acting sequences used symbolic links to indicate where actors would walk or look in a level. Facial animation, animation blending, and sequencing of a scene’s events could then be authored while another person worked on the world geometry. This technique was also used to script citizen dialogue, allowing our writer to quickly iterate it.

Though these are just a few examples, we pushed symbolic links into as many areas of the pipeline as possible. The general strategy was to increase the number of iterations by specialists by reducing iteration cost, since we believe that more iteration results in a higher quality product. Lower iteration cost also reduced the cost of experimentation, which is really just another kind of iteration. This technique also allowed us to make changes far closer to shipping than previously possible because the interdependencies were removed.

GLOBAL CONSISTENCY

All our chapter designs began with the same core set of design principles, many of which were derived from Half-Life , but some were new. The team wanted to extend the direction of HALF-LIFE without losing sight of what we felt were the things that made it successful. The overarching goal was to create an immersive first-person experience, so we accepted some principles as constraints up front.

Despite the fact that each design cabal followed the same high-level principles, design inconsistencies were a natural consequence of the multi-cabal structure. The designs of the individual cabals reflected the strengths and weaknesses of the various members—therefore each group developed different game mechanics and made different decisions about, for example, the level of difficulty, density of experience, and the relative proportions of combat to puzzles. Our toolset was so large that cabal members tended to prefer designs that used tools they were most familiar with. One team had a rendering specialist, while another had an AI specialist. Some level designers were great at developing combat, while others excelled at optimizing performance. Some were great at authoring terrain, others were best at working with entities, and still others had better artistic sensibilities than the rest. So how did we produce a cohesive game despite all these disparities?

Concept art: Poison zombie

First, we tried to achieve an economical design. Each cabal was encouraged to ask the question, “How well does this element leverage our other gameplay elements?” as a framework for evaluating design choices. This led naturally to a more cohesive experience, since the same elements tended to be used throughout the game.

We used team-wide playtests to expose game mechanics created by one cabal to the other cabals so that they could identify and share the successful game mechanics, spreading them throughout the game. For example, the Ravenholm cabal enabled the gravity gun to interact in specialized ways with particular objects (such as the sawblades). This inspired the Citadel cabal to make the super gravity gun. The energy balls resulting from that work were later used by the Follow Freeman cabal to open the Nexus gates. Later still, they were incorporated into the alternate-fire for the Combine assault rifle.

These team-wide playtests also helped highlight the inconsistencies in other areas, such as quality of visuals, combat, and puzzles and so forth. When one cabal saw that another was producing better work, the two groups were quick to come together and discuss the techniques they were using.

Because certain design elements, such as weapons and monsters, crossed cabal boundaries, it was sometimes hard to change those elements without breaking another cabal’s levels. We solved this problem for weapons by forming a weapons cabal, which comprised representatives from the three gameplay cabals and included both hardcore FPS and less expert players so that the needs of both player types were considered. The weapons cabal’s goal was to produce a varied and balanced palette of weapons, wherein each had a unique function but no obvious best weapon emerged (at least not until we wanted it to). The weapons cabal tuned weapon placement within the game timeline to eliminate clumping and droughts, so players would get a steady flow of new weapons as they progressed through the game. The weapons cabal also worked with each design team to make sure the weapons had an interesting introduction, with enough incentive shortly thereafter for players to use learn how to use the weapon.

Many of our project management decisions were also made with global consistency in mind. The gameplay cabals had weekly reviews with cross-cabal resources (management, art, animation) to help propagate design decisions. These reviews had the goal of helping each cabal operate with similar scope, schedule, deliverables, and methods.

We used comparative metrics where available (how many maps per level-designerweek are you trying to ship?) to analyze each cabal’s output. Code was constantly published—in order for one cabal to use it, it had to be made available to all—and shared as another means of propagating design choices. We did our best to synchronize the deliverables across groups, which increased the effectiveness of team-wide playtests and other cross-cabal feedback mechanisms. It forced the teams to solve similar problems at the same time, and it fostered positive competition. No cabal wanted to be behind or have lower-quality levels when it came time for the playtest.

A SECOND GO AROUND

Even before production began, we planned to do a quality pass over the entire game once we hit alpha to evaluate all our choices within the global context of the game. It quickly became apparent that we would also need to use this second pass to solve consistency problems that had not been solved during the first pass over all the levels. This second pass, which ended up taking only about four months, resulted in a huge improvement in the quality of the game.

At the start of alpha, the game’s quality was fairly variable, and it had wildly varied pacing. Transitions between chapters were often nonsensical, as it was hard for one design cabal to predict what another was doing at the beginning of the adjoining section. There also were fairly large inconsistencies in the level of difficulty from chapter to chapter. Some of these problems were fairly straightforward to fix. Chapter transitions, for example, were trivial to smooth out once each cabal could see what was on both sides of the transition. Of all the inconsistencies, the most difficult one to solve was ensuring consistently high quality across the entire game.

To evaluate the game as a whole, at the beginning of alpha, the entire team took a break from building the game to play through the entire experience, sending feedback for general discussion. As a means of distilling the disparate feedback into a consistent actionable message, a new group called the Cabal Cabal was formed, a team that included one member of all six teams, as well as a few others, and which met daily throughout the weeklong, teamwide playtest to critique, chapter by chapter, the entire game.

The Cabal Cabal’s goal was to provide feedback to the other teams so each could maximize overall quality. The final decision of how to respond to the feedback was left up to each responsible design cabal, with each cabal allocating its resources where it felt the best results could be achieved.

The Cabal Cabal focused its discussions on the high and low points of each chapter. The high points were identified for polish and amplification, as these presented the easiest opportunities to maximize quality. Opportunities for crosspollination of highly popular game mechanics or experiences were noted, which helped us not only leverage our best elements, but also improve our design economy and consistency.

Low points were typically sections of the game that were frustrating, confusing, empty, or simply very rough. Sections of the game that were relentless to the point of being fatiguing were broken up with puzzles or downtime while sections that felt empty were filled with additional content. Some low points were too costly to fix, which led to a final round of cuts. These amputations were really painful because anything cut this late in the project had been invested in heavily. This taught us that the only thing more painful than an early cut is a late one, so it’s best to be decisive in the beginning. But we reminded ourselves that we cared far more about that content than our customers would, since they would only see the final product. It was also comforting to remember that cutting content meant the rest of the game would receive more attention and thus achieve a higher quality.

MULTIPLE ITERATIONS, MAXIMUM GAINS

Many of us were surprised at the large improvement in quality between the game at alpha and the game after we finished our second pass, given the relatively short amount of time it took. We now consider multiple iterations to be a key to Half-Life 2 ’s success and a mandate for future projects, the major benefit being that it allowed us to make far better decisions.

During the development of both Half-Life and Half-Life 2 , we found that decisions made later in the project were always better than decisions made earlier. Some were better simply because they were better informed by the experience we had in making the game up to that point. For example, work on the Citadel began only six weeks before alpha, and unlike the rest of our chapters, we didn’t already have a plan for what major gameplay element was going to be used. The prototype of all gameplay elements in the Citadel levels took a single day, and our first pass on that chapter was finished in three weeks. The reason the super-gravity gun was created was that we knew at that point in development that the gravity gun was a highly successful element in our game. Development was extremely efficient because we knew the engine well enough to choose game mechanics we could implement very quickly.

Other decisions couldn’t possibly be made until later in the project because they required more of the product to exist around them before they could be made. For example, the qualifier “good enough” (and its dreaded opposite, “not good enough”) proved especially elusive during the early production phases of Ravenholm and Nova Prospekt (the first two chapters produced), but became clear and well understood once the game was assembled as a whole. Balancing the level of difficulty as well as maintaining an appropriate pace were two other problems that couldn’t even be addressed until we saw the game as a whole.

Obviously, making certain decisions too late in development can wreak havoc with a shipping schedule. We used time as the primary constraint on how issues could be resolved to avoid this problem. The closer we were to shipping, the less acceptable it became to make changes with broad dependencies. For example, in the prototype phase, new technology or AI could be added, spaces could be defined, and levels could be reordered. After the art pass, changes to the world geometry and the general lighting scheme were constrained. After alpha, the game mechanics, art assets, level progression, characters, and most dialogue were fixed and could only be altered for cases in which the repercussions were isolated and well understood. Our investments in symbolic links really paid off during this phase because it allowed us to make a large number of fairly significant changes with low cost.

FRUITS OF LABOR

Creating Half-Life 2 was a tremendous learning experience for everyone on the team. Behind commercial success, perhaps one of the more creditable signs that our process succeeded is that everyone on the team is genuinely proud of the product we created, and excited to repeat the process. Hopefully some of the many lessons we learned creating Half-Life 2 are generally useful and could be applied to other projects. Here are some of those lessons that we feel are most important:

Decentralize your design. Make rough, but global decisions early (weapons, story, basic monster behaviors). With investment comes constraints; minimize investment until you hit critical mass of quality, then iterate until good becomes great. Don’t design using theoretical mechanics. Validate designs first using prototypes. It doesn’t have to look good at all (use “orange” maps) and perhaps can be prototyped in your previous generation technology. If you have a one-year schedule, try to reach alpha in eight months to give yourself a few months to iterate your design anew. In our experience, every week of work after alpha is worth well over four weeks of work prior to alpha. Create demanding customers for everyone on your team—it’s a great technique for improving efficiency and prioritization. In the traditional tradeoff of scope, quality, and time, reduce scope to get better results through iteration. Attempt to reduce pipeline stalls by carefully thinking about where those stalls occur in your production pipeline. Use symbolic links to eliminate pipeline stalls and allow as many low-cost late changes to your work as possible. Processes are cheap and disposable— try to measure how they are succeeding or failing to achieve game and company goals. Don’t be afraid to change a process if it stops working.