128 lines
6.3 KiB
Markdown
128 lines
6.3 KiB
Markdown
---
|
||
created_at: '2014-05-17T20:53:05.000Z'
|
||
title: Valve’s Design Process For Creating Half-Life (1999)
|
||
url: http://www.gamasutra.com/view/feature/3408/the_cabal_valves_design_process_.php
|
||
author: danso
|
||
points: 142
|
||
story_text: ''
|
||
comment_text:
|
||
num_comments: 25
|
||
story_id:
|
||
story_title:
|
||
story_url:
|
||
parent_id:
|
||
created_at_i: 1400359985
|
||
_tags:
|
||
- story
|
||
- author_danso
|
||
- story_7761030
|
||
objectID: '7761030'
|
||
year: 1999
|
||
|
||
---
|
||
![](https://www.gamasutra.com/features/19991210/half.gif) 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.
|
||
|
||
![](https://www.gamasutra.com/features/19991210/birdwell_01.gif)
|
||
|
||
**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.
|
||
|
||
![](https://www.gamasutra.com/features/19991210/birdwell_02.gif)
|
||
|
||
**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.
|