hn-classics/_stories/1999/7761030.md

created_at	title	url	author	points	story_text	comment_text	num_comments	story_id	story_title	story_url	parent_id	created_at_i	_tags	objectID	year
2014-05-17T20:53:05.000Z	Valve’s Design Process For Creating Half-Life (1999)	http://www.gamasutra.com/view/feature/3408/the_cabal_valves_design_process_.php	danso	142			25					1400359985	story author_danso story_7761030	7761030	1999

While Half-Life has seen resounding critical and financial success (winning over 50 Game of the Year awards and selling more than a million copies worldwide), few people realize that it didn’t start out a winner — in fact, Valve’s first attempt at the game had to be scrapped. It was mediocre at best, and suffered from the typical problems that plague far too many games. This article is about the teamwork – or "Cabal process" — that turned our initial, less than impressive version of Half-Life into a groundbreaking success.

Paving the Way with Good Intentions

Our initial target release date was November 1997 — a year before the game actually shipped. This date would have given Valve a year to develop what was in essence a fancy Quake TC (Total Conversion — all new artwork, all new levels). By late September 1997, nearing the end of our original schedule, a whole lot of work had been done, but there was one major problem — the game wasn’t any fun.

Yes, we had some cool monsters, but if you didn’t fight them exactly the way we had planned they did really stupid things. We had some cool levels, but they didn’t fit together well. We had some cool technology, but for the most part it only showed up in one or two spots. So you couldn’t play the game all the way through, none of the levels tied together well, and there were serious technical problems with most of the game. There were some really wonderful individual pieces, but as a whole the game just wasn’t working.

The obvious answer was to work a few more months, gloss over the worst of the problems and ship what we had. For companies who live and die at the whim of their publishers, this is usually the route taken — with predictable results. Since Valve is fairly independent, and since none of us believed that we were getting any closer to making a game we could all like, we couldn’t see how a month or two would make any significant difference. At this point we had to make a very painful decision — we decided to start over and rework every stage of the game.

Many of our scripted sequences were
designed to give the player game-play clues as
well as provide moments of sheer terror.

Fortunately, the game had some things in it we liked. We set up a small group of people to take every silly idea, every cool trick, everything interesting that existed in any kind of working state somewhere in the game and put them into a single prototype level. When the level started to get fun, they added more variations of the fun things. If an idea wasn’t fun, they cut it. When they needed a software feature, they simplified it until it was something that could be written in a few days. They all worked together on this one small level for a month while the rest of us basically did nothing. When they were done, we all played it. It was great. It was Die Hard meets Evil Dead. It was the vision. It was going to be our game. It was huge and scary and going to take a lot of work, but after seeing it we weren’t going to be satisfied with anything less. All that we needed to do was to create about 100 more levels that were just as fun. No problem.

So, Tell Me About Your Childhood

The second step in the pre-cabal process was to analyze what was fun about our prototype level. The first theory we came up with was the theory of "experiential density" — the amount of "things" that happen to and are done by the player per unit of time and area of a map. Our goal was that, once active, the player never had to wait too long before the next stimulus, be it monster, special effect, plot point, action sequence, and so on. Since we couldn’t really bring all these experiences to the player (a relentless series of them would just get tedious), all content is distance based, not time based, and no activities are started outside the player’s control. If the players are in the mood for more action, all they need to do is move forward and within a few seconds something will happen.

Conceptual artwork for
ceiling-mounted monster
that was dangerous to both
the player and the player's enemies

The second theory we came up with is the theory of player acknowledgment. This means that the game world must acknowledge players every time they perform an action. For example, if they shoot their gun, the world needs to acknowledge it with something more permanent than just a sound — there should be some visual evidence that they’ve just fired their gun. We would have liked to put a hole through the wall, but for technical and game flow reasons we really couldn’t do it. Instead we decided on "decals" — bullet nicks and explosion marks on all the surfaces, which serve as permanent records of the action. This also means that if the player pushes on something that should be pushable, the object shouldn’t ignore them, it should move. If they whack on something with their crowbar that looks like it should break, it had better break. If they walk into a room with other characters, those characters should acknowledge them by at least looking at them, if not calling out their name. Our basic theory was that if the world ignores the player, the player won’t care about the world.

A final theory was that the players should always blame themselves for failure. If the game kills them off with no warning, then players blame the game and start to dislike it. But if the game hints that danger is imminent, show players a way out and they die anyway, then they’ll consider it a failure on their part; they’ve let the game down and they need to try a little harder. When they succeed, and the game rewards them with a little treat — scripted sequence, special effect, and so on — they’ll feel good about themselves and about the game.