Developer commentary/Portal 2

	This is a quote article.
	This article is a transcript of all of the quotes from a given character or entity. Unless noted otherwise, these transcripts are sourced directly from the official scripts, closed captions, or internal text data with only minimal modifications for typos and formatting purposes.

The following is a list of all of the developer commentary from Portal 2's commentary mode.

Commentary

Title	Filename	Speaker	Subtitle
WELCOME TO PORTAL 2	com-welcome	Gabe Newell	Hi, my name is Gabe Newell, and welcome to Portal 2. When we released the original Portal in 2007, it was an experiment to see how gamers would respond to a different kind of gameplay and storytelling experience. Portal went on to win a bunch of awards, sell many copies, and, most importantly, resonate with gamers in a way that no other Valve title has. The challenges for us in building Portal 2 were to live up to people's expectations, to take you back to the world of Chell and Aperture Science, and to surprise gamers again not with more of the same, but with more of the new. And, I think, it will be, mostly, a pleasant surprise. To listen to a commentary node, put your crosshair over the floating commentary symbol and press your use key. To stop a commentary node, put your crosshair over the rotating node and press the use key again. Some commentary nodes may take control of the game in order to show something to you. In these cases, simply press your use key again to stop the commentary. Please let me know what you think after you have had a chance to play Portal 2. I can be reached at gaben@valvesoftware.com. I get about 10,000 emails each time we release a game, and while I can't respond to all of them, I do read all of them. Thanks, and have fun!
BIG DOOR	com-bigdoor	Scott Dalton	The size of the gigantic transition seal lock was a happy accident. We knew the connection between old Aperture and new Aperture had to be a big set piece. The first model built was about five times bigger than everyone expected, but people started to like it. We joked that it should be a bullet point on the Portal 2 box: "Features the biggest door in games ever!" We decided it would be fun to play with the player's expectations and put a puny looking door behind it, along with a few small props.
JANITOR BOB	com-janitor	Ivan Simonici	We had to come up with old-looking versions for all the important gameplay props, such as button panels, doors, cubes - basically everything the player could interact with. We came up with this fictional character - Janitor Bob. He'd be the guy who had to maintain all of old Aperture. A guy who doesn't understand anything about science but can fix everything with duct tape and a screwdriver. He would use everything he could get his hands on. The result might not look pretty but it would work. So whenever we got stuck designing props for chapter 3 we'd ask ourselves: "Well, how would Bob build it?"
THE EYE HAS IT	com-eyehasit	Karen Prell	How do you make a giant mechanical eyeball express life and emotions, let alone give the impression that he's talking when he has no mouth? The animator's understanding of human behavior came in handy for bringing Wheatley the personality sphere to life. Talking is so much more than just moving a character's mouth. You have to use body language, head attitudes and rhythm of movement and eye focus to indicate a character's feelings and motivations. Slow, smooth head moves, a steady gaze and a relaxed eye aperture indicate that Wheatley is calm. Short, sharp head turns, rapid blinks and glancing around indicate nervousness or deceit. Add a tightly constricted eye aperture and a little shiver to show fear. Tilting the body away while keeping the eye focused on the player signals an attempt at cleverness that ultimately only fools Wheatley himself. Suspicion is communicated by squinting his eyelids and handles, which function as very expressive eyebrows and cheeks. It's also fun to remind the player that Wheatley is a machine. When hacking, his eye and body segments become perfectly centered and spin mechanically, inspired by the spinning tape reels on old Univac computers. And when he wants to look far in front, he flips his eye all the way over to the other side of his head. This animation approach combined with the writing and vocals makes Wheatley quite a unique and entertaining character--part human, part machine, all eye, and no brain.
MASH-UP	com-mashup	David Sawyer	Having built up the expectation that Wheatley is going to kill the player, we still wanted the actual moment to be a surprise. By this point players are entirely comfortable with faith plates, and the simple subversion of expectations as Wheatley punts you sideways, is a fun and surprising moment. We added the bouncing box with the intention that players attempt to time their jump to catch the box, focusing their attention on the expected result of their jump and heightening the surprise.
CRUSHERS	com-crushers	Cayle George	We had a bunch of levels that used the crusher panels in ways that made the test chambers more dangerous. After showing some of these levels in press demos, we got feedback that viewers were getting the impression that Portal 2 was going to be too difficult since players would have to time events such as running or falling through a portal with not getting hit by a deadly crusher. We decided to save these for the escape, when Wheatley tries to hold you off.
PREPARING FOR WHEATLEY'S LAIR	com-lair	Alireza Razmpoosh	When playtesting the final boss battle, we found players were confused about what to do when they entered Wheatley's lair. Our solution was to train the player by having them break glass paint pipes a level earlier. This lets them learn the mechanic without any time pressure before they have to fight Wheatley. This also trains the player to redirect the bombs Wheatley throws at them.
ELEVATOR FATIGUE	com-fatigue	Marcus Egan	We found that playtesters were getting fatigued at solving so many complex test chambers in a row. So, instead of a routine elevator ride to the next puzzle, we added a long funnel ride with some destruction to give players a short break while reminding them of the facility's state of disrepair.
CHEATING THE SPEED OF LIGHT	com-cheating	Phil Co	We wanted to be scientifically accurate in this puzzle, figuring that there'd be a slight delay before you'd see a portal on the moon, since light takes 1.4 seconds to travel the distance. But playtesters would shoot the moon and instantly turn away, thinking nothing had happened. They didn't realize they actually had shot the moon. We tried and rejected a few different approaches to communicate the effect, including a cheat involving quantum entanglement, before settling on the current solution to this problem.
STATE OF DECAY	com-decay	Kelly Thornton	Starting out in the ruins of the test chambers from the first Portal was our goal pretty much from Day One. We wanted to give players a sense of nostalgia for what they had played, but also make it very clear that things had changed. Not only in a fictional sense, but in a graphical one as well. We needed to bridge the gap between the first game's simpler art assets to the much more complex look of Portal 2.
PORTAL CAROUSEL	com-carousel	Alex Vlachos	This room is meant to teach players the fundamentals of portals connecting them to two places in the world. As the blue portal moves around the world, the orange stays rooted. In the original Portal, this room had the portals moving by themselves on a timer. This led to most people simply staring through their orange portal waiting for the blue one to end up in the right place. We felt that altering this to make the players decide where the portals came out was more instructive and meant that players who already knew how to use portals could solve this puzzle both quickly and with authority.
SMOOTH JAZZ	com-jazz	Mike Morasky	This map was one of the first of the older Portal maps that we beat up and decayed to bind the two games together. The 'smooth jazz' joke is probably the oldest one in the game. The team discovered through playtesting that smooth jazz was funny to all ages, genders and cultures.
WHEATLEY AT E3	com-e3	Thorsten Scheuermann	This interaction with Wheatley was the first that we hooked up for our initial showing at E3. It demonstrated how Wheatley would be an actor in the world, and how the player would not only be interacting with him directly, but also using him to interact with the Aperture facility.
CATAPULT INTRO	com-catapult	Kristopher Katz	This was the first test map we created when we started to experiment with the Aerial Faith Plate puzzle element. The map underwent many visual refinements, but it's one of the few puzzles that remained almost completely unchanged from its first form.
INTRODUCTION DESTRUCTION	com-destruction	Gray Horsfield	The container ride destruction sequence provided some unique technical challenges. The dynamics you experience are actually computed as two separate but nested simulations. The first is a coarse scale simulation designed as a stress element analysis pass. This pass computes the overall gross motion of the container itself, and computes the collisions and break points based on path keyframe data and a network of constraints. As the container bumps and crashes along, the constraints start breaking, and the room progressively starts to come apart. There are over three hundred rigid bodies and nine hundred constraints in this rig, all individually configured for properties like tensile, friction and collision response. The coarse simulation portrayed gross motion that captured the main dynamics of the ride, but not the fine details. The product of the coarse simulation was then used to deform spline-based surfaces representing the container geometry, which in turn were parents to fine debris as anchored rigid bodies. As the surface deformations increase, anchors are broken and the fine debris rigid bodies are released into the simulation. The fine simulation also includes the interior furniture, and the model detailing. The two simulations were then connected using cache data and were driven together by a series of scripts. Due to the computational complexities of having two nested simulations, we had to come up with some solutions to some interesting mathematical problems. One problem was that the nested nature of the simulations resulted in some instability in the fine debris calculations due to floating point computing limits. The solution employed for this was to compute the fine debris on a stage where the root transform of the coarse simulation was essentially cancelled out and stored for later use. This allowed us to more accurately detect the fine interactions between the debris and the environment. Post simulation, the root transform position and inertia were reapplied to the details. We solved the problem of trying to compute the player within this highly dynamic environment by putting them in a virtual room that has all the base shapes of the rendered container, but is simply used to compute player navigation. (It’s hidden somewhere else in the map.) The viewpoint of the player is then parented to coarse simulation transform, resulting in the final rendered frame. At the end of the ride the player is teleported into the actual game space. The simulations were iterative, enabling us to sculpt the dynamics in parallel with the gameplay design. In the final product there are over 1200 rigid bodies, 900 constraints, and 1000 joints. With all the iterations combined, the actual run time spent computing the simulation was 92.4875 days.
REFERENCE MATERIALS	com-reference	Adam Foster	While making Portal 2, we explored our way through vast quantities of reference material. Inspirations included photos of NASA’s Apollo and Shuttle programs, CERN’s particle accelerators both modern and obsolete, industrial robots, derelict Soviet space shuttles, overgrown temples, Brussels metro stations, seedy American motels, junkyards filled with rocketry equipment, Chinese apartment blocks under construction, Polish shipyards, neutrino detectors deep underground in nickel mines, corporate headquarters from a variety of eras, commercial nuclear reactors, experimental fusion reactors, rain-sodden book depositories in Detroit, peculiar cameras, forgotten space probes, you name it.
KILL YOUR TELEVISION	com-monitor	Zachary Franks	In each of Wheatley's test chambers there is always a monitor with Wheatley on it. While placing the monitor in this level, one of our designers thought it would be funny if the monitor was the target of the faith plate and would get broken if the player or the box flew into it. We thought the gag worked well and decided to make every monitor breakable.
NONLINEAR PROGRESSION	com-nonlinear	Greg Cherlin	The original layout of this chamber started out much more linear; essentially a sequence of rooms that the player had to progress through somewhat blindly – not knowing what the next goal might be until they got there. Early versions contained an extra puzzle beyond the reflector cube, but due to the linear path, it took players so long to get to it, that they were confused about which elements were still relevant. This drove us to make the level nonlinear. To make it easier for players to visualize the puzzle, we condensed the overall test space and moved the exit near the start. This helped the players see where they had to go and which objects would help them get there.
MISLEADING FIXATIONS	com-mislead	Jess Cliffe	While testing this map, we often saw playtesters fixate on the excursion funnel and try to use it to get to the other side, forgetting that they had a portal gun. To remedy this, we added the destruction event that happens just before this chamber. This requires the player to portal through the floor and out of a wall to cross a gap. Once the player enters the test chamber, they are presented with the exact same scenario, but in a different context.
EXCURSION FUNNEL	com-funnel	Dave Saunders	In this excursion funnel ride, playtesters would often end up shooting the wrong portal at the critical moment and killing themselves. This ruined the moment for players, who often didn't quite understand why their excursion funnel hadn't been redirected. As a solution, we now detect when the player places the wrong portal in hopes of saving themselves; we help them out by moving their other portal under the excursion funnel source. This effectively makes the section foolproof, by allowing the player to shoot either portal to save themselves.
WORLD PORTALS	com-worldportals	Eric Tams	Much of the fun in Portal is based on the joy of the "Ah Ha!" moment when you learn something new. The game needs a very specific pacing to ensure these moments. If things are too easy then you are robbed of that moment since it feels like you didn't accomplish anything. If it's too hard then players feel stupid instead of smart when they finally realize that one small part of the puzzle that they were missing. Unfortunately trying to create that delicate balance leads to a lot of shuffling of levels and a lot of revisions and tweaks to existing levels. When we started the project making any big structural change in a level or the order of levels would lead to hours or even days of busy work trying to reconnect things and make sure they lined up again. If we ever wanted to ship something the size of Portal with the finely tuned balance we desired then we needed a way to be able to make big changes to the layout of the game without paying the cost of making everything line up again. We needed a way to bend space. We needed to think with portals. Using portals to connect different areas in the world we could make any type of impossible space work out. You could look through a hallway into the next room but the hallway might be on the other side of the map and the room you are looking into might be in a completely different orientation. We could seamlessly insert an elevator, a huge expansive vista, a room that was bigger on the inside than the outside, or even create an infinite fall by connecting a shaft back into itself. Soon every connection between any space was a portal. We would even switch them on the fly. Even a simple door worked like the cartoons - just a facade painted on a wall that seamlessly opened somewhere else entirely. Once the game settled down we were able to finalize our path and remove all of the world portals. There's only one impossible space left in the whole game - see if you can figure out where it is.
BLOBULATOR	com-blobulator	Olivier Nallet	The first implementation of the blob was integrated in the Source engine back in 2007. Over the years, the code has been significantly optimized, but was still way too slow to run on game consoles. The blob was a key feature of Portal 2, even though we did not know if we could make it work for consoles. In summer 2010, we were still considering using a completely different tech for consoles--one that would certainly not look as nice. On the 360, even with a very low quality blob, we were barely within our performance budget. But we really wanted to have the same high quality blob among all platforms. Meanwhile, the code was poorly suited for PS3 SPU. We ended up re-writing all the blob code so it would take better advantage of multiple cores and SPUs, giving us quality blobs on all platforms while staying within performance and memory constraints.
FLIGHT PATHS	com-flight	John Guthrie	The catapult trajectory lines seen here allow us to visualize where the catapult will deliver a player or a physics object. We can differentiate the speed and trajectory for players and other objects. The yellow lines are for physics objects, and green is the player's trajectory. Sometimes we need to have a different value to accommodate the shape of the objects being catapulted. What works for the player may not work for an object, and vice versa. For instance, it was common for a box to make it to a ledge while the player would smack into the side and then fall into the slime. The visualization tools helped us debug these types of problems
HOTEL HELL	com-hotelhell	Randy Lundeen	The idea of being stuck forever in a state of stasis that looked like a crappy old motel room had been in our minds for a long time, but we weren't sure exactly how we wanted to rip you out of it. There was some debate over whether the opening sequence happened inside the player’s head or not. There was an alternate opening where Aperture had hooked-up all of its cryo-stored test subjects to an incredibly boring hotel room simulator, which Wheatley would then wake the player from. Eventually this was discarded as too difficult to explain in the short time allotted, and we opted to change the hotel room to a “container ride on a rail”. This allowed us to show the player, rather than tell them, about how they and other test subjects have been stored, show some of the scale of the facility and even hint at how much time has passed. We also get to gradually reveal all of this through the destruction of the container itself as it moves and bangs into things. Overall, this gives the player a much more dynamic and visceral introduction to Portal 2.
STORY REMNANTS	com-remnants	Kyle Monroe	The writers went back and forth over whether or not Wheatley had tried escaping with other test subjects before waking the player up. It was an interesting idea, and you can still hear remnants of this story arc in some of the dialogue. But at the end of the day, it was just too expansive a concept to sell. So it’s hinted at, but not overtly mentioned until the end.
SLOW BURN	com-slowburn	Elan Ruskin	GLaDOS originally was a lot more cutting in these opening rooms, given that she’s talking to someone she perceives as her murderer. Playtests revealed, though, that it was a bit grueling getting brow-beaten by GLaDOS this early in the game, so her arc was rewritten to give her more of a slow burn towards the player.
MANY TO ONE	com-manytoone	Doug Wood	Wheatley was originally envisioned as a group of spheres that you’d discover as you explored the facility behind the scenes. We ditched this idea for two reasons. For one thing, ‘behind the scenes’ levels were required to highlight the introductions of each of these new spheres and these levels have their own unique logic. The number of spheres we wanted would have made for far too many of these types of levels, resulting in a very un-Portal-like game. Also, we were spending so much time introducing these new characters that we had no time to get to know any of them before they were swept offstage for the next one. Eventually we realized it’d be a lot more satisfying to really get to know one sphere instead of briefly meeting six. Some of these characters were eventually recycled as corrupt cores for the finale.
HORRIBLE ACCENTS	com-accents	Erik Robson	The breakout sequence here was originally a lot longer, involving Wheatley talking to you in a horrible American accent, assuming GLaDOS can't hear him. Simultaneously, we'd have GLaDOS commenting on the entire ridiculous exchange, because of course she can hear him. When we playtested the concept, every player made a beeline for the opening. So we either had to ditch all the dialogue or figure out a reason for the player to stand around for five minutes even though they could escape at any time. We ditched the dialogue.
CAROLINE	com-carolyn	Dario Casali	The character of 'Caroline' came about because we wanted somebody for Cave to play off of. Though we had originally envisioned a put-upon Scientist character called Greg, it would have been wasteful to hire an actor for just one or two lines. Instead, we hit upon the idea of economizing by using GLaDOS-actor Ellen McLain. Out of nowhere, we suddenly had an opportunity for a GLaDOS origin story.
POTATOS	com-potatos	Jay Pinkerton	The character of PotatOS was actually the hardest one to crack for us, and was the last character to get recorded. We’d always wanted to switch things up for the sequel, so that GLaDOS would become your unwilling buddy cop partner against a new threat, but this ended up being far more entertaining as a concept than in execution. It’s one thing to have an omnipotent villain chastising you while you’re testing. It’s quite another to have a little potato on your gun doing the same. Playtesters wanted to tear her off the gun, and we didn’t blame them. So we were faced with the unsettling prospect of making dry, robotic supervillain GLaDOS more human and relatable. This ended up being one of the hardest writing jobs in the game.
BIRDBRAIN	com-birdbrain	Erik Wolpaw	One of the larger plot holes that PotatOS introduced was: She’s your buddy now. She’s got the same goals as you. So why isn’t she helping you solve the tests? The real answer is, obviously, that if she did help you solve the tests there’d be no game. One solution we we came up with was for the bird from Act 3 to keep swooping in and pecking bits of her off your gun. As the bird kept eating the part of her that knew how to solve the tests, PotatOS would actually get dumber over time. For technical reasons, this ended up being impossible to execute, so we ended up finding another solution. Some of us though will always have a place in our heart for the bird solution.
EVIL WHEATLEY	com-evil	Noel McGinn	Finding the right balance for Evil Wheatley was difficult, because we still wanted him to be the bumbling idiot from the first half of the game, but at the same time, there had to be some sense that he was dangerous now, otherwise there wasn't much tension for the big finale. Fortunately, Stephen Merchant did a great job of intercutting funny bumbling Wheatley with occasional outbursts of power-mad, villainous Wheatley.
PUNISHER	com-punisher	Joel Shoop	There was a lot of debate over how to properly punish Wheatley at the end of the game. Killing him seemed too severe, given how much we’d grown to love the character. On the other hand, simply letting him out of the GLaDOS body with a slap on the wrist seemed unacceptably anticlimactic. Having him sucked out into space with the Space Sphere seemed like a happy middle ground that everybody could get behind.
ROBOT WHIMSY	com-whimsy	Mike Belzer	In our original robot designs, and the first animation tests, we started with the premise that, being robots, their movements should have limited 'personality' and be a bit more mechanical. The feedback of our game testers, and the reaction of fans through the trailers, convinced us that a more whimsical approach to animation would lead to a better experience. So we moved away from a sterile approach and found a whole new range of possibilities, as we began to explore their personalities and gestures.
ORANGE BOT	com-orange	Keith Lango	The orange bot has been described as finicky, and you can see elements that are somewhat birdlike and even reminiscent of the Odd Couple's Felix Unger. The 'gotta pee' idle dance was born out of the idea that current bipedal robots are constantly needing to readjust in order to find their balance. Because Orange's design is rather unstable, the motion design solution was kind of a perpetual motion needed to maintain his balance.
BLUE BOT	com-blue	Christen Coomer	If the Orange bot is the Odd Couple's Felix, then Blue is Oscar. Blue was meant to be an early and rather rough prototype robot--representing GLaDOS’s first attempt at making a bipedal testing bot. Compared to the sleek lines of Orange, he is much less elegant. For motion inspiration, we looked to some of our favorite real life robots, such as the Big Dog robot from MIT and the towel-folding robot from Hitachi.
DECORATING APERTURE	com-decor	Laura Dubuk	This chapter gave us a great opportunity for visually telling the backstory of Aperture Science. We accomplished this with signs, props and materials. In this area, we get a glimpse of what Aperture Science must have been like in its heyday. We used rich, warm colors and materials like carpeting and marble to indicate that Aperture had a lot of money at one time. Cave Johnson and his staff were just starting out in their enterprise and everyone was eager to do science. This stands in contrast to the stark, cavernous environment outside and the materials you see in the Aperture Labs from later decades. As the player makes their way through more recent areas of the lab, the materials become cheaper, with an abundance of plastic and linoleum showing that Aperture had fallen on harder times and could no longer build high-quality offices for its workers.
NEW SOUNDS AND OLD	com-newsounds	Tim Larkin	The newer and older versions of Aperture show their distinct personalities in sound as well as visuals. The doors, floors and buttons, as well as soundscapes, reflect the aging, outdated 70’s feel. The sounds contain hints of the decaying metal and wood. The newer but unstable Wheatley chamber soundscapes become more foreboding and perilous the further you venture into them. The atmosphere of uncontrolled destruction continues to intensify till the end.
PREDICTING WITH PORTALS	com-prediction	Dave Kircher	The levels in Portal 2 are much more complex than in the first game, and as a result we’ve had to beef up the player movement algorithms. The player is represented as an axis-aligned box in the world, which creates a problem for portal teleportation because portal teleportation is almost never axis-aligned. To improve how we handle this, we trace the player as the axis-aligned bounding box they would use on each side of a portal simultaneously and merge the results into something usable. We have to predict quite a bit more than previous Source Engine games because portals and projected entities change the way the player moves through the world. Prediction itself is a mind bending headache when dealing with portals. We’re already dealing with a non-linear space. Now we also have to deal with non-linear time in a non-linear space.
HUB DESIGN	com-hub	Matt T. Wood	In laying out the structure of our Hub, we had a number of challenges that were new and specific to co-op play. We have to assume that each player has made different progress throughout the game, playing with different partners, and starting in the neutral center of the hub was a way of making sure that they had a chance and place to coordinate. Players needed a way to agree on where to go, and way to visualize each other's completion data. As they played, they needed concrete feedback on how much progress they had made. In seeking solutions, we felt it was important to keep the player in the gamespace rather than resorting to menus and UI that would take them out of the game. Therefore, players can clearly see their status over the doors, and they navigate by walking the course in the 3D space. GLaDOS is there to connect the experience to the singleplayer game, while holding the player's hands a bit to keep the co-op goals and feedback clear.
RETURN TO THE HUB	com-hubreturn	Gautam Babbar	Our initial goal in designing the hub was to provide players with a lot of choices, so they could to sample a variety of game types. The idea was that if they got stuck or needed a break, they could pick another test chamber or another mechanic to explore. In reality, this prevented us from doing sufficient training and limited the overall scope of the puzzles. With such a flat structure, it was much harder to layer old mechanics onto new ones, because we couldn't guarantee that players understood what they needed to know to solve a puzzle. By going linear, we could guarantee prior knowledge and provide a much better experience, more satisfying pacing and a story that gathered momentum over a long period of time.
STEALING THE CORE	com-stealing	Ted Backman	We have a taunt where one robot steals the other's core. When implemented, it was the only taunt that required one person to initiate. Because of this we were afraid that it would be used for griefing. We were in the process of rethinking our approach when early playtesters rated this as their favorite taunt. It was also the most used team taunt because it only required one player to initiate, and was easier to use than the others. We ended up changing all the other team taunts to emulate the way stealing the core works.
PING TOOL	com-pingtool	Josh Weier	Early on we realized that trying to tell your partner where to go, where to look or where to place a portal was going to be really hard. Even with voice chat, saying 'over there' doesn't give enough information to your partner within the 3D space. Players kept wanting to get up and point directly at their partner's screen. We developed the ping tool to address this problem. Because the ping tool was so important, we decided to train players in its use before we did anything else. We held back on the vast majority of player actions and let the players focus entirely on the ping tool. This is why the co-op bots start separated in a tube, without even the ability to walk or shoot a portal.
PING CONTEXT	com-context	Iestyn Bleasdale-Shepherd	Most players don't realize that the ping tool is context sensitive. When they are playing voice enabled, players usually rely on the look portion of the ping tool. Without voice, icons such as 'press the button' or 'stand here' become much more important.
SYNC UP	com-sync	Brian Jacobson	It is important to give co-op players a way to coordinate their action. Seeing how our players naturally wanted this ability, we decided to support it with the ping timer, and ended up designing some puzzles around it. Due to lag and other issues, syncing up actions over voice chat turned out to be rather difficult. Therefore we created the countdown timer as a way for players to keep in sync. It's completely predictable. Both players see the GO at the same instant, and the clocks run in sync even if they are on different systems.
HAND OFF	com-handoff	Chris Boyd	Something that really surprised us was how often playtesters stated that they loved the basic experience of handing off a cube to their partner. Players didn't expect such a fundamental physical interaction to just work in a game. Before trying it for the first time, they would discuss their plan as if it were some unique or special new game mechanic. When it just worked, they were overjoyed.
DYING ALL THE TIME	com-dying	Andrea Wicklund	Normally in games, when players die, they see this as a big failure. But in Portal, death is a normal part of the puzzle solving experience. In co-op, death not only happens more frequently, but it can happen at the hands of your partner (purely accidentally of course). We felt it was important to not only make death "no big deal," but to make it fun. Early on, we tried some elaborate death animations--such as showing your robot slowly getting crushed under a giant crusher. These were awesome to watch, but they quickly became repetitive. Also, after a very short while, players grew afraid to take risks. The fear of having to wait a long time before trying again prevented them from simply playing and experimenting in a spirit of fun. We had to find the right balance where death was quick enough to be a non-penalty, and elaborate enough to be visceral and satisfying--a fun pay-off for creative play.
DISASSEMBLY DEVICE	com-disassembly	Danika Wright	Since the co-op characters can die at any time, we needed a way to rebuild them quickly and often. Therefore in co-op, we replaced the elevators that connected test chambers in singleplayer, with disassembly machines. These are meant to reinforce the idea that since the robots are disposable, being destroyed is no big deal. In the robot world, it happens all the time!
AIRLOCKS	com-airlocks	Garret Rickey	Airlocks were introduced mainly as a way to allow players to focus on individual puzzles. In some of our early investigations, areas contained puzzles that were meant to be solved as a group, as well as others that were for individual solution. But we found that if players could move freely between them, they logically assumed that the individual puzzles were part of one big puzzle. This had bad results. For clarity, we created these airlock-like spawn rooms that act as checkpoints between puzzles. Once both players enter the airlock, we lock off access.
WORLD IMPOSTERS	com-imposters	Gary McTaggart	In Left 4 Dead 2, we authored simple, fogged, black versions of the world as monolithic models to avoid the CPU overhead of rendering the world again for water reflections. This worked well for the Left 4 Dead 2 outdoor environments where most light comes from the sky. But Portal 2 is almost entirely indoors, so the color and value of the world geometry is apparent in the water reflections. Since the Portal 2 world geometry is relatively simple, we automatically build a version of the world geometry that has a single texture that combines both lighting and surface shading along with another texture with just surface shading. The latter texture is used when rendering dynamic lights. These textures are at the same spatial resolution as the light maps and get packed into a single large atlased texture per level. Drawing this simple world imposter model takes very little CPU time, which was a limited resource on Portal 2 due to the many portal views, split-screen views, and water reflection views that we needed to render. We initially planned on using the world imposters only for water reflection rendering, but we ended up using it to improve performance in split-screen mode where it is used for rendering distant portals and portals that are two levels deep. We also use the world imposters to render water in full screen co-op mode, to give us some performance overhead, since the co-op mode has more portal views to render than single-player mode.
GEL SOUNDS	com-gelsounds	David Feise	With the gel sounds for Portal 2 we wanted to create something whimsical that would add to the player’s enjoyment of the mechanics, without crossing over the line into ludicrousness. For example, our initial pass at the blue gel 'bounce' sound included a rubber playground ball, a pitch-bent harp string and a processed mouth harp. The resulting sound captured the idea of fun, but was off the charts on the goofy scale. After several iterations we settled on the current, less over-the-top sound which features a piece of metal bar bouncing like a diving board and a heavy dose of synthesis. It’s not as wacky, but hopefully it’s still fun.
GESTURE WHEEL	com-wheel	Andrew Burke	In our first implementation, gestures were automatically selected based on the player's context. For example, Blue might do a special gesture when standing on a floor button. Players became bored of seeing these gestures so quickly that they stopped using them before discovering any of the special contexts. Because of this, we decided to give players control of gestures as a way to express themselves, but when shown the full set from the start, they were overwhelmed by all the choices. By awarding gestures as the game progresses, we allow players to familiarize themselves with each gesture in turn. Leaving visible empty slots in the gesture wheel lets players anticipate that they'll be rewarded with cool new gestures as they progress. The gesture wheel provides quick access so that players can feel comfortable tossing out a gesture during down time, letting them pick the perfect moment to share a high five.
HIGH-FIVE	com-highfive	Matthew Scott	We noticed that after playtesters had solved a difficult puzzle together, they'd sometimes pause before funneling through the exit door to repeatedly jump up and down in excitement. We realized that these meeting points would be the perfect time to allow players to high-five each other and celebrate their victory in style. Our first interface attempt had one player initiate a high five by holding their hand up and waiting, the other player could join in by selecting the same gesture. If they were standing in the correct positions relative to each other, they would pull off a high five. But learning the correct places to stand was too difficult. So we decided to automatically move the bots into the correct positions for the high five. Sometimes, however, the player who wanted to high five would be left hanging as the other player ran ahead without accepting. Increasing the time that the initiator waited with his hand up gave the other player time to return and accept, but being frozen in place for more than a few seconds was too frustrating. So finally, we made players auto-accept the team gestures. Now, when the mood strikes either player, the game always ensures a successful celebration.
HUGS	com-hugs	Keith Lango	For a while, we were on the fence about whether to keep the team taunt 'hug' in the game. Some felt it wasn’t suitably robotic, while others had a concern that it perhaps showed too much emotion for these characters. But once it was animated for a trade show trailer, many of our concerns were washed away by the positive reaction of the fans. It was a huge success.
ROBOTS VISUAL DESIGN	com-robotvisual	Tristan Reidford	Visual design of robots began with lots of concept art. The initial round of concepts explored all kind of forms from human to the more abstract. We found ourselves gravitating toward shapes that reminded us of the sphere and turret in the original Portal. Whilst keeping with the established portal design aesthetic, we were keen to create all new characters, and, being a duo, it was important that they were their own separate designs, rather than identical copies of each other. Unlike, for instance, Team Fortress 2, where a clean silhouette is essential for communicating the nature of a character, we had an opportunity here to play with designs that were a bit messy, with things sticking out of them, so they looked half manufactured, half improvised. Once we had agreed on rough designs in 2D, we began to build the shapes in 3D, and this is where the next level of improvisation and experimentation occurred. Usually, a model will be designed and built in 3d and then rigged for animation, but here we allowed the rigging process to inform the models. We wanted to celebrate the mechanics of robots. We allowed function to dictate form, and in terms of detail they started to design themselves once you start thinking about motors, ball joints, actuators, and all that sort of thing. The classic duo is often made up of the two contrasting body types--short and squat next to tall and wiry, and it's not hard to see Laurel and Hardy, C3P0 and R2D2, in these characters. Even though we had the freedom to make our silhouettes a bit untidy, it was still important that they remain readable as anthropomorphic bipeds. We wanted players to feel free to make mischief for their partners, in a typically human way, but without creating any kind of gore. The robots were perfect for this.
TURRET BUILDING MACHINE	com-turret	Aaron Nicholls	We felt that most players of Portal, ourselves included, wanted more opportunities to look behind the scenes of Aperture--and not only into deserted crawlspaces, but into the vital heart of the factory. The turret factory was a way for us to satisfy this desire, while also answering the nagging question of where all the stuff in the facility came from. Because we constantly allude to the turret creation process throughout the game, it is satisfying from a story standpoint, to finally stand before the machine you've been hearing about. By showing how turrets are made, it's easy enough to extrapolate a similar creation path for all the other items that Aperture generates only to be consumed by the endless process of product testing. We designed an entire life cycle for the poor doomed turrets, from creation, product testing, error detection, packaging, and their ultimate unpackaging prior to being recycled. In fact, the turrets never make it to shipping. As soon as a turret is completely finished and packed in a box, it is immediately sent to the un-boxer, where it goes on to recycling and begins its life anew. Thus we show Aperture continually building and repurposing its items in the most inefficient way imaginable. We never got around to building the actual unboxer, but what we pictured was that it was located immediately below the boxing machine. And while the turrets would be reduced to their components, the boxes would be discarded and end up in a steadily growing mountain of unrecycled packing materials.
FRANKENTURRETS	com-frankenturret	Matt Charlesworth	The Frankenturrets were an attempt to show one of the ways Wheatley has been spending his time since he threw the player down into the Underground. Using his limited brain, it didn't seem like he could have come up with a lot, so the idea of using objects he'd have access to seemed appropriate. The turret and the cube are the two most iconic portal objects and the frankenturret is little more than a crude combination of those two objects. The hermit crab animation when you pick the cubes up began as a necessity because we really needed to make them act like cubes when you held them. It ended up being so cute that it became a simple job of making the turret widen its eye and shake its head a little, to convey to the player that these things were disrupted, and had no idea who or what they were anymore, and also to make the player feel sympathetic towards their plight. We used a combination of in game physics pushes and canned Maya animation to allow the player freedom to move them wherever they wanted, line up races between them, or even set them up so they would walk, inevitably to their doom, into a fizzler.
WHEATLEY MODEL	com-wheatleymodel	Richard Lord	The Wheatley model was designed as a mechanical version of the original Portal 1 personality sphere. Originally they filled a very similar role to that in Portal 1, so we needed one base model which could hold a lot of different expressions. Experimenting with different rigging ideas we came up with the onion skin design where a number of spherical plates could slide around inside each other all supported on a small motion platform mounted on a gyroscope. This meant that no matter what expression Wheatley was pulling, he always retained his spherical shape. The modelers and the animators collaborated closely on these early tests to make sure the design supported the range of expression needed to satisfy any personality sphere that got designed. Lots of ideas were thrown out, such as a small internal robot arm that Wheatley could pull out of one of his ports and pull himself around with. We were careful to make the mechanics look plausible, but we had to cheat the eyelids, since they ended up being a physical impossibility. There was no way all that geometry could fit into the space around his eye without clipping out the other side, but they were such an essential feature of the model that we resorted to crushing them up inside the eye where the player can't see them.
VACUUM TRANSPORT	com-vacuum	Jeremy Bennett	Vacuum pipes cropped up occasionally in the original Portal, but this time we wanted to show that this was the main way that Aperture transported all of its supplies about the facility. It felt very true to Aperture, in that it seemed like an inefficient and ridiculously expensive solution to their transport problems. We also wanted it to feel more violent and physical than before, with objects constantly ricocheting against the sides of the pipes. It was as if Aperture had no real control over the system, and no real care for the things they were transporting. After all, they have thousands of the things.
ARMS ASLEEP	com-arms	Matt Wright	When the player first encounters the robot arms, we wanted to convey that they were still coming back online. The idea was that GLaDOS was just waking up and hadn't yet fully regained control of them. Slowly, over the course of the first few levels of this act, she gets more sure of herself, and her ability to alter and mess with the lab increases. The arms presented a number of challenges, the key one being interaction with the player. It was easy for the player to get stuck behind or inside of the models if they did something too complex. So we had to limit most of the arm action to the walls or ceilings of the test chambers, and we restricted their use on a larger scale to areas where we could be sure of the player's location.
ELEVATING VIDEOS	com-elevideo	Ido Magal	With the vacuum tubes such a big part of Portal 2, we designed the new elevators to work within them. We liked the idea that this made the player feel about as important to Aperture as the cargo moving through the tube, and it also gave us plenty of opportunities to show how the system could go wrong, such as when the tube gets blocked, or when cargo rains down on the elevator. The videos began as attempts to visualize some of GLaDOS's dialogue, but evolved into a means of relaying information about the larger world of Aperture. It seemed very likely to us that Aperture would boast to the test subjects about the devices they were testing, and show them the clever ideas they had put into the products. The videos also serve as a reward for completing the test chambers, and a way to make the elevators visually different from one another to prevent repetition.
FAITH PLATE	com-faith	Marc Nagel	The faith plate was originally a robot arm model which we hurriedly placed into the maps to see if the gameplay was fun. Over time it became apparent that playtesters were struggling to tell the faithplate apart from the standard arm, so we replaced it with a new design. It was meant to be a simple heavy weight which was flung upwards, propelling the player. The length is meant to imply a direction, so the player knows the intended flight path before they step onto it. We experimented with foot marks and treadplates on the design, but it quickly became confusingly busy, so we kept the design simple.
STALEMATE	com-stalemate	Torsten Zabka	The stalemate resolution button is the earliest configuration of the robot arms we tried. Playtesters enjoyed it, but it took us a long time to find the right place for it in the game. It clearly needed to be defending something, and for a while it defended a paranoid personality sphere who had built a huge encampment of defenses to stop you from getting to him. When the idea for the stalemate button came up, we knew it had finally found its home as part of GLaDOS's last desperate attempt at self-preservation.
GLADOS WAKES	com-wakes	Matthew Russell	Originally GLaDOS was built to curl up and disguise herself as one of her rings, potentially explaining how she had survived the explosion at the end of Portal 1. But this wasn't a very dramatic reveal, so we threw it out in favour of spreading her out over a greater distance. This also made her more recognizable as GLaDOS when you initially crossed the room. The actual wakeup animation was a combination of simulated animation with a layer of hand keyed animation over the top. A two-stage model was created for this scene. The first stage had separate pieces and connecting cables that would be drawn together by running a physics simulation so that the pieces would interact with the environment. Physics simulations were also used to break apart the objects GLaDOS crashes into while she writhes around. At the point where GLaDOS rises free of contact with the ground, she switches instantaneously to a fully connected model with controls for hand-keyed animation. From this point, the animator enhanced GLaDOS' awakening by hand, choreographing the violent chaos of her re-emerging consciousness while at the same time conveying the weight of a machine the size of an airliner. Once the hand-keyed animation was done, a final simulation pass was run to animate the cables and dangling parts of GLaDOS' body. The scene was produced very rapidly for an E3 deadline, and a traditional rig for the sequence was never fully realized. This made it difficult when we extended the sequence after E3 to add further animation, but we accomplished it by bearing in mind that GLaDOS herself is pretty broken at this point. The last part of the sequence requires the player to lose control of their view while being immobilized by a giant mechanical pincher. Once the controlled camera takes over, a careful alignment and time synchronization was required to make all the hand-animated models and camera interact with each other. Each of the stages in this wakeup scene contain a variety of processes that are very challenging to achieve live in a game engine.
TAG: THE POWER OF PAINT	com-tag	Brett English	Similar to the way the student game Narbacular Drop became the original Portal, the paint mechanics in Portal 2 come from a student game, Tag: The Power of Paint. The repulsion gel in Portal 2 is modeled after the bounce paint from Tag, but was redesigned to fit better within Portal. The original bounce paint always bounced the player at a fixed height and activated whenever the player touched the paint. We changed the repulsion gel to reflect the player's velocity, such that they will bounce back up to the height that they fell from. This mechanic lends itself better to puzzles involving portals because players have to think about gaining and preserving height. We also changed the repulsion gel to only activate if the player jumps off of, or falls on to the gel. This was done because players would often accidently walk onto repulsion gel they didn't see and then trigger an unwanted bounce. This was a particularly nasty problem in Portal 2 because the player couldn't get rid of paint once it was applied; whereas in Tag the player can erase paint at any time they want.
PORTING PAINT	com-porting	Ted Rivera	While re-implementing the paint mechanics from our student game, Tag: The Power of Paint, in the context of Portal 2, the biggest change we made was to exclude the paint gun. In Tag, our paint gun allowed the player to paint the environment freely in an abstract outdoor environment, but in our gameplay experiments, that was very difficult to constrain without contrivance in Portal 2's indoor spaces. It also changed the game's pacing significantly, since being able to run at high speed around a level covering everything in paint is lot more fast paced, energetic, and often scattershot than Portal's more cerebral gameplay. Perhaps most importantly, there's a certain elegance in the simplicity of manipulating all the game elements using only the portal gun. Adding a new gun would inherently add complexity and force us to start from square one training the player how to use this new tool, instead of focusing on the game's namesake. Instead, we decided to use the established mechanism of the delivery tubes and have players redirect the flow of the paint with their portal guns. This felt like a good compromise.
FIZZLING OUT	com-fizzling	Tejeev Kohli	We needed a puzzle that would demonstrate the different effects that the fizzler has on the game. This map was consistently the one that most of our playtesters would get stuck on and we tried various things to make the puzzle easier to understand. Originally this room had 2 fizzlers in it and was divided up into three distinct areas. This proved to be too complicated and almost none of our playtesters could solve the puzzle. We removed the second fizzler and simplified the layout of the room quite a bit but most of our playtesters were still getting stuck on it. We identified the problem to be the space above the fizzler. Originally this space was completely open, but that didn’t effectively convey to the players that they needed to shoot a portal above the fizzler. We then tried putting glass with several holes in it above the fizzler. This was slightly more effective as players would know that the holes are there for a purpose and would try to solve the puzzle by shooting portals through the holes. The map was still not testing well though, as players could not figure out which side of the fizzler they needed to be on when they shot their portals. We then changed it to have only a single hole through the glass, moved down to the eye level of the player, so that shooting the portal from either side of the fizzler would be a valid solution. This change tested really well and we started seeing most of our playtesters make it through the level without getting stuck on it for a long time.
EMANCIPATION GRID	com-emancipation	Bronwen Grimes	We originally planned to use the same emancipation grid effect we'd used in Portal 1. We were surprised to hear during several of our early playtests that players thought this map was the first time they'd encountered one. Players walk through at least one emancipation grid in almost every map. Playtesters also weren't able to report the grid's properties. That indicated to us that we needed to better communicate when an interaction was occurring. Our challenge was to create an effect that was more noticeable to players, but didn't look so solid or so threatening that players wouldn't attempt to walk through it. We chose to keep the cool color scheme, and reinforce the non-threatening nature of the field by mimicking the kind of water caustics you'd find in a shallow swimming pool. To communicate that the grid blocks portal placement, we added flashes whenever the player shoots one. To warn players that the grid will destroy objects brought through it, we added a vortex effect that increases in intensity as objects get near. Once these changes went in, playtest feedback demonstrated that players noticed the emancipation grids earlier and had a much better understanding of their function.
SPEED PAINT	com-speed	Bank Charnchaichujit	Propulsion gel carried over almost exactly the same as the speed paint in the student game, Tag: The Power of Paint, except that it is slightly more than twice as fast. Propulsion gel combined well with the existing mechanics of Portal, such as flinging, and it also went well with the repulsion gel for long jumps. We had to tweak the player's control on propulsion gel to feel right in the Portal universe, and also added a slight funneling effect to help guide the player when they are speeding into a portal.
CRAZY BOX	com-crazybox	Sergiy Migdalskiy	One of the things that the student game Tag: The Power of Paint didn't allow was painting of other objects, since this would have been too trivial in that game. In Portal 2, however, moving paint around became a puzzle in and of itself, so we began to create puzzles that depended on painting objects. Bouncy boxes and turrets were an obvious choice, and adding this mechanic extended our toolbox to include objects whose basic properties of movement could be changed by the player.
PORTAL PAINT	com-portalpaint	Vitaliy Genkin	Portal paint was the last paint we added to the game, and for a long time we weren’t sure of the best way to use it. We experimented with the delivery method and found that it was most effective when it was deployed in large quantities. Another important factor was the angle of application. Dropping the paint at an angle allowed the player to play more freely with the paint, which gave them the liberating feeling of breaking the rules by being able to place portals where they couldn’t before.
ARG	com-arg	Adam Foster	N/A
THE ASCENT	com-ascent	Chris Chin	The lake map marks a total reset to the aesthetics and scale of the environments up to this point in the game. You come into the underground cave compressed and as you progress further into the map, your eye is drawn upwards by the elevator tower, sparking cables, falling debris, and finally the test spheres which recede vertically into nothingness. This looking upwards gives the player sense of the vastness of Aperture before GLaDOS and a visual sense of the daunting climb they will have to make to get back to Wheatley. The open areas encourage the player to explore their surroundings and take a break from the intensive puzzle solving of the test chambers.
WRITING FOR CO-OP	com-cowrite	Chet Faliszek	Writing GLaDOS for co-op introduces some interesting problems. In single player you can count on players paying attention and being caught up in important moments. In co-op, you can count on the two players chatting about what they just did as GLaDOS delivers an important line. To help with this issue, we broke up the story beats into smaller sections so players don’t become impatient. We also repeat the points multiple times to insure the message sinks in even if you missed it a few times. Lastly, we also give players room to talk. For example when you die, there is a two second beat for you to laugh or yell before GLaDOS speaks. It is important to give those places for players to speak because the best part about co-op is the shared experience.
BONK HEADS	com-bonk	Jeep Barnett	This puzzle requires one of Portal’s trickiest logical leaps. Early playtesters often took longer than their patience would allow, and were nearly ripping out their hair by the time they’d finally solved it. But almost everyone insisted that the payoff was by far their favorite moment in all of co-op. We significantly reduced the average solution time by adding a puzzle just before this where two cubes repeatedly collide, but this almost completely robbed the appeal from what was once a high moment. So, instead we decided to make a few subtle adjustments and leave players with the responsibility to make the final leap. First we added a puzzle four chambers earlier, to teach players to fling by cutting their hard light bridge and falling into a surface directly below. We then subconsciously prime the thought of midair collision by having players repeatedly ricochet weighted spheres against a hard light bridge. Finally, we designed this room’s layout, lighting, and decals so that players would see the entire space as a symmetrical whole and visualize the bots' fling path. By planting shards of the idea in their heads, we allow players to own that exciting dual collision epiphany while keeping their sanity intact.
TRUST PUZZLES	com-trust	Eric Tams	Several puzzles in the game require the players to take on distinct, intertwined roles. We called these asymmetric chambers 'Trust Puzzles,' because one player is often placing their life in the hands of the other. When one player accidentally kills the other it almost always ends in laughter. So much laughter, that we sometimes had to question if it really was a legitimate accident. These puzzles also require players to stay in constant communication, which naturally leads to some great moments of cooperative bonding. While some teams found these stressful, for many partners, these puzzles were their favorite type. But everyone agreed that they added needed variety and a nice change of pace. And by swapping roles, each player can get an entirely different experience within the exact same puzzle.
CUBES V. SPHERES	com-cubes	Matthew Scott	Weighted spheres first appeared in one of Portal 1's advanced chambers. For Portal 2, we accidently made them bouncy and it was too much fun chasing them to change it. In co-op, we wanted players to use teamwork to catch an object, and while a cube might have landed safely, a sphere will bounce and roll out of bounds. So, in this chamber we drop a bunch of spheres as a fun visual reward, and we wanted to trick players into saying 'balls' over the microphone.
NEW CHELL	com-chell	Realm Lovejoy	We thought of making a whole new character for Portal 2, but we didn't want to lose the relationship between GLaDOS and Chell that began in Portal 1. Once we decided to stay with Chell, we wanted to improve her look: updating her leg springs and jumpsuit to have a more functional design. At the same time, we didn't want players to not recognize her, so we kept a lot of the iconic elements like the color orange. She has folded down her jumpsuit to show she has essentially rolled up her sleeves and shed some of the Aperture label...she is awake again to test, but stronger and more determined than ever.
PROJECT LIL	com-lil	Marc Laidlaw	Project Lil is our codename for an internal push to make our comments more accessible to the whole Valve community. It was pointed out to us in mail from a fan that in some of our previous commentary, the designers referred unfailingly to the gamer as a 'he.' Although in natural speech, most of us normally tend to say "they" and "their" rather than "he" and "his," some stuffy overactive minion of the grammar police went through and revised all those usages to make them conform to an oppressive gender-biased rule. However, research shows that "they" and "their" is a perfectly acceptable and even older form, and we are happy to fall back on it and let people talk the way they normally talk, and screw the so-called rules that alienate our fans. Thanks, Lil.
VOICING THE BOTS	com-botvox	Bill Van Buren	It took a while for us to dial in the right approach for the co-op bot vocalizations. Initially we recorded some in-house vocal performances and processed them heavily with the resulting sounds being very robotic. However, as the animations being created for the bots were so broad and expressive, we soon realized we were going to need to try a different sonic approach. After a few more in-house experiments, we brought in Dee Bradley Baker, who we had worked with to create the voices for some of Left 4 Dead’s Special Infected. We worked with Dee to come up with two distinct vocal and character approaches for the bots and recorded a range of responses for each. Afterward, two of our sound designers each took on one of the voices and came up with a unique sound-processing approach to create a distinct sonic personality for each bot, that still allowed the energy and expression of Dee’s performances to shine through. In the following samples you can hear what they sounded like in Dee’s original performance, and the result after the sound designers got through with them.
WHEATLEY ATTACKS	com-wheat_attacks	Kutta Srinivasan	Wheatley used to have different kinds of attacks, other than lobbing bombs. At one point, we tried attaching several turrets to him that he could point at you. This proved too punishing, however, and they were removed. We also tried crusher panels that Wheatley could try to smash you with. This, once again, proved too punishing since players were focused on what Wheatley was doing and would often get hit by a crusher they weren't looking at.
WHEATLEY'S AS LEVEL DESIGNER	com-designer	Aaron Barber	Wheatley's first test was really fun to make because we wanted it to feel like he was a first-time level designer. We see a lot of maps where people try using different textures or lights to write words or put their names on the walls.
WHEATDOS	com-wheatdos	Michael Marcus	Our initial idea for this version of Wheatley was to replace GLaDOS's eye with Wheatley's, but it wasn't a big enough change to see the difference. Instead we put Wheatley onto GLaDOS's rig, and gave him a puffed out look, like he's trying to make himself look big, using wall tiles.

List of speakers

• Gabe Newell
• Scott Dalton
• Ivan Simonici
• Karen Prell
• David Sawyer
• Cayle George
• Alireza Razmpoosh
• Marcus Egan
• Phil Co
• Kelly Thornton
• Alex Vlachos
• Mike Morasky
• Thorsten Scheuermann
• Kristopher Katz
• Gray Horsfield
• Adam Foster
• Zachary Franks
• Greg Cherlin
• Jess Cliffe
• Dave Saunders
• Eric Tams
• Olivier Nallet
• John Guthrie
• Randy Lundeen
• Kyle Monroe
• Elan Ruskin
• Doug Wood
• Erik Robson
• Dario Casali
• Jay Pinkerton
• Erik Wolpaw
• Noel McGinn
• Joel Shoop
• Mike Belzer
• Keith Lango
• Christen Coomer
• Laura Dubuk
• Tim Larkin
• Dave Kircher
• Matt T. Wood
• Gautam Babbar
• Ted Backman
• Josh Weier
• Iestyn BleasdaleShepherd
• Brian Jacobson
• Chris Boyd
• Andrea Wicklund
• Danika Wright
• Garret Rickey
• Gary McTaggart
• David Feise
• Andrew Burke
• Matthew Scott
• Keith Lango
• Tristan Reidford
• Aaron Nicholls
• Matt Charlesworth
• Richard Lord
• Jeremy Bennett
• Matt Wright
• Ido Magal
• Marc Nagel
• Torsten Zabka
• Matthew Russell
• Brett English
• Ted Rivera
• Tejeev Kohli
• Bronwen Grimes
• Bank Charnchaichujit
• Sergiy Migdalskiy
• Vitaliy Genkin
• Chris Chin
• Chet Faliszek
• Jeep Barnett
• Matthew Scott
• Realm Lovejoy
• Marc Laidlaw
• Bill Van Buren
• Kutta Srinivasan
• Aaron Barber
• Michael Marcus