Author: by Kim Swift

[As Valve re-releases an update of Portal for Xbox Live Arcade, Gamasutra is proud to present a Game Developer magazine-reprinted article by the creators of the 2007 Game Developers Choice awards' Game Of The Year, discussing the creation of the GlaDOS-domineered cerebral action-puzzler. This article originally appeared in the January 2008 issue of Game Developer magazine.]

To our genuine delight, Portal became one of the most notable games of 2007. Though Portal's development path was by no means perfect, during the two years we spent creating the game, we refined what we think is a terrific process.

A rigorous playtesting schedule, iterative story design, and a marketing strategy that helped mitigate some of the game's riskier elements all contributed to a fresh, enjoyable experience for players -- one which remained accessible despite its unconventional narrative and gameplay mechanics.

Getting Started

Perhaps the most unconventional element of Portal's development was the way in which the project arrived at Valve. All of us on the Portal team (with the exception of our writer, Erik Wolpaw) were students at DigiPen Institute of Technology, a university focused on video game development.

As a part of the curriculum each year we had to form teams and create a game from scratch using our own code and artwork. The requirements for the games range from a text-based game for our freshman year to a fully 3D game with simulated physics for our senior year. For our final game project, seven of us got together and created a game called Narbacular Drop.

We knew that we were going to be graduating soon, and we needed a great project to put on our resumes. When trying to come up with the game design for our project we focused on creating a game that was simple and unique.

Simple, because from our previous school projects we learned that there are never enough hours in a day to do what you'd like. Unique, because we figured we could get more attention for a new idea, and since we were in school there was no risk in trying out an original concept.

After throwing around a few ideas we were able to come up with the game design for Narbacular Drop, the predecessor of Portal. In that game, you were able to create two interconnected portals, a red and a blue, and place them dynamically around the level; using them to solve challenges and traverse the various maps in the game.

Nuclear Monkey Software's Narbacular Drop

Every year, DigiPen holds a job fair for graduating seniors, during which they bring in developers from across the country to take a look at students' projects -- and hopefully offer them interviews.

During our job fair, Valve sent over a couple of representatives who took a look at Narbacular Drop, and they subsequently invited us to come to their offices and demonstrate the game for Valve founder and managing director Gabe Newell.

We ecstatically accepted and the following week we found ourselves in one of the conference rooms at Valve, with Gabe Newell sitting with rapt attention on a couch. About fifteen minutes into our demo, Gabe stopped us and asked what we planned on doing after we graduate. After we answered, Gabe offered us a job on the spot to make the game in full using the Source engine.

Needless to say, we all accepted the offer and started working on Portal in July 2005. Working at Valve straight out of school certainly required some adjustment. One of the wonderful things about Valve is how intelligent and helpful everyone is. We've learned many things that have helped us to become better game developers.

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.

A week after the meeting, Erik came back with some sample dialog he'd recorded using a text-to-speech program. It was a series of announcements that played over the newly-christened "relaxation vault" that appears in Portal's first room.

Everyone on the team liked the funny, sinister tone of the writing, and so Erik continued to write and record announcements for other chambers, while still searching for the story proper.

At some point, however, it became apparent that these announcements were providing playtesters with the incentive to keep playing that we'd been looking for all along.

Better yet, in the sterile, empty test chamber environment, players were actually becoming attached to the alternately soothing and menacing computer guide. We'd found the narrative voice of Portal.

After this insight, the rest of Portal's story fell into place quickly. The facility would be owned by Aperture Science, the scrappy, unethical scientific rival of Half-Life's Black Mesa.

The guide, now named GLaDOS, would simply talk to players throughout their experience -- praising them, taunting them, and, whenever possible, trying to make them feel guilty for the nonstop acts of defiance and mayhem that game players are conditioned to commit routinely in game environments.

Our hope was that by the end of the Portal, players would know GLaDOS better than any boss monster in the history of gaming. Though we knew at some point the player would have to meet and destroy her, we thought it would be even more satisfying if players got a chance to cause her some emotional pain along the way.

Even though you literally break her to pieces at the end, the entire game is a long process of tearing her down; she becomes increasingly more vitriolic and desperate as the player progresses.

What started out as a seemingly burdensome constraint -- a total lack of human NPCs -- eventually turned into one of the strongest parts of the game. Navigating the environment is Portal's primary gameplay challenge; In effect, the environment is your enemy. GLaDOS's disembodied omnipresence gives that enemy a voice and personality.

Porting Portals

These successes are not to say that the game was a cakewalk. The first challenge we faced was to take the portal technology we'd developed for Narbacular Drop and make it work in Valve's Source engine.

Source is a huge code base, and while it offers a lot more functionality than our homespun Narbacular Drop engine, it required that we undertake a massive redesign.

When we first started working on Portal, we tried to get a hacked version of portals up and running as quickly as possible so we could begin testing our maps. This system basically involved a teleport and the camera/monitor system that already existed in Source.

Quickly, we realized that we needed a more robust method for rendering the portals and allowing the player and other objects to move seamlessly between them. This required us to dig a little deeper into the Source engine's rendering and physics code, and we had to program our own portal system.

Basically, we had to tell the Source physics system to make a temporary hole on only one side of a wall, and that everything behind the portal is connected to geometry in another part of the map. Getting this to work and optimizing the solutions to run in real-time was a major challenge.

After we implemented the bare bones of getting a working portal system we had to figure out how to tackle some of the more complicated problems. For instance, how do you deal with one of our weighted cubes sitting halfway in a portal?

The player and other objects needed to be able to interact with both sides of the weighted cube and have that interaction be convincing. This also comes with interesting edge cases such as an object being able to actually collide with itself.

LOD Runner

Another problem we ran across was the need to change distance-based systems such as level of detail (LOD) for models, because with our game, distance is relative to the portal locations. This means that the distance calculations became a choice of three lines connecting two points, rather than just one line.

Also, line of sight can pass through a single portal more than once to reach its target. The Source Engine does many pre-computed visibility optimizations for culling. Allowing users to bridge visibility leaves with portals added another level of complexity.

For better rendering, we implemented a stencil buffer drawing method for portal views, which gave us a lot of flexibility for handling the portal recursion depth.

This allowed us to render an infinitely deep number of portals (limited only by performance), which made our "infinite" hallways look pretty neat.

Stencil drawing also helped us solve the problem of integrating properly with other technology in the Source engine like HDR blooming.

Since we have to render our scenes an additional two times for our portals we poured a lot of our effort into making portals render as fast as possible, such as special view frustum culling based on the portal's edges, and render list optimizations for portal drawing.

The Orange Box

When we started working on Portal, we didn't know that it was going to be packaged inside The Orange Box with Half-Life 2, the Half-Life episodes, and Team Fortress 2. In the end, though, we're certainly glad it was. We took plenty of risks with Portal; the game is short; it features a new gameplay concept, and it's a puzzle-based game with a story.

Under normal circumstances, it would be extremely challenging to market an experimental project like Portal. Placing the game in The Orange Box alongside a well-known franchise allowed us to present a new concept to a wider base of players than we could have if it were only sold as a standalone game. In retrospect, packaging a new franchise as a smaller game amongst two well-known IPs is a low-risk way of testing its potential.

Though two years is a short development cycle in comparison to some other games, it was definitely plenty of hard work. Now that we're at the end of the Cinderella story of Portal's creation, it's just incredibly gratifying to hear how many people have enjoyed the game, and that all of our efforts have paid off.

Despite the common wisdom that gamers simply want to play the same basic concepts over and over again, Portal is happy proof that, when approached in the right way, original gameplay and narrative elements can produce fun, memorable, and most importantly for everyone's ongoing employment, successful games. The medium still has a lot of unexplored territory, and we're certainly looking forward to striking out into the unknown.

Game Data

Portal

Publisher: Valve
Number of Full-Time Developers: 8
Number of Contractors: 0
Length of Development: 26 months
Release Date: October 10, 2007

Platforms:

PC Windows
Xbox 360
PlayStation 3 (Developed in conjunction with EA)

Development Hardware:

AMD and Intel CPUs
DirectX 8-9
ATI and Nvidia GPUs
256-4GB RAM

Development Software:

Softimage XSI
Visual Studio 2005
Adobe PhotoShop and Illustrator
Perforce
ZBrush
Sound Forge
Havok