Playtesting is Everything

We were introduced very quickly to the cornerstones of Valve's development process: Playtesting and application of playtest observations to game design. While creating Narbacular Drop, we didn't playtest the game until the last month of its development. Our playtests revealed several problems and bugs, but it was far too late to actually fix most of them.

When developing Portal, on the other hand, we started playtesting our game almost immediately. We had a very rough version of the first room of the game up and running the first week we started at Valve.

There wasn't much to that first room, and in fact, it didn't even really have a puzzle (other than waiting for a portal to appear and then walking though it).

Even so, we began having other people playtest it. Testing this early let us start making efficient, playtest-driven changes to the level from the very beginning of development.

Every week (or any time we created a significant new piece of content), we would bring in someone that hadn't played the game before. We'd sit them down, tell them to play the game just as they would at home, and then watch them play from beginning to end.

Actually observing someone play your game gives you much more information than simply having them fill in a questionnaire after they've finished playing. You can clearly see when a player is having fun, is confused, happy, sad -- everything. Watching them lets you monitor their moment-to-moment experience. This instant feedback was invaluable for tuning the game in addition to uncovering plenty of code bugs.

This particular testing method was beneficial in a number of ways. It allowed us to be objective about new content and often gave us ideas of how to fix problems. It even provided the inspiration for new puzzles, as we witnessed playtesters solving puzzles in ways that we hadn't previously considered.

After watching a playtest, we would begin working on improving our levels and gameplay based on what we had observed during the playtest.

This rapid iteration on our maps helped us create a very smooth difficultly ramp. If more than one playtester had problems in a certain area we would break out problem-solving concepts into separate sections.

For instance, in one of our maps there is a section where you have to reorient an energy ball through a portal twice to direct it into an energy ball socket to activate a sliding platform.

Valve's Portal

Originally, this was our first introduction to puzzles that involved redirecting energy balls. Several of our playtesters would get stuck in this section for a very long time and get really frustrated.

So we broke this concept out into another two sections which involved redirecting an energy ball only once. We tested this progression of three sections, and by the time the players got to the final section they managed to grasp the concept much quicker than early playtesters were able to.

A Puzzle Game with a Story?

One of the many things that we discovered during our playtests was that, fifteen to thirty minutes into the game, the experience started to get a little dry. We decided that the game needed some flavor and an entertaining narrative, so we turned to Valve staff writer Erik Wolpaw to help us.

Before the writing started, we met with Erik and discussed our list of narrative constraints. Since at the time we were using some Half-Life art assets, and because we wanted to leave ourselves the option of someday using the portal gun in a Half-Life game, we decided that the story should in some way connect to the Half-Life universe.

Practically speaking, we didn't have sufficient time or staffing to add any human characters, which would have required an impressive amount of animation work and scene choreography. That meant the story had to be expressed without the benefit of any visible extra characters.