Thursday, March 4, 2021

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



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.

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.

of our scripted sequences were

designed to give the player game-play clues as

well as provide moments of sheer terror.

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.

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.

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.

Source link

Leave a Response