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.
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.
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.
creature was initially designed as a friendly character, but play-testing
revealed players’ tendencies to shoot first and ask questions
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.
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.
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.
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.
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
Good Deed Goes Unpunished
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.
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.