[MUSIC PLAYING] COLTON OGDEN: All right. Good afternoon, everybody. Thank you so much for coming to today's talk. My name is Colton Ogden. I'm the course instructor for GD50, which is CS50's new Introduction to Game Development course. We started this last spring and we've been having lectures every week so far for the last semester. Last week we took a look at Portal, which is a famous game by Valve, whereby you get a gun that can essentially shoot these portals that defy the laws of space onto different services in the game. Walk in and out of them and teleport through them and see through them. And there are a host of interesting challenges associated with implementing a game like this. Now last week we looked at a simple version of it in Unity, but today we are joined by Dave Kircher and Tejeev Kohli of Valve Software who actually were on the Portal team and implemented all of the interesting sort of design and technical decisions that went about making it work and making it fun and believable. So without any further ado, this is the "Portal Problems." Thank you. [APPLAUSE] TEJEEV KOHLI: Hi. So we're just going to run through. Both me and Dave were actually students when we were hired by Valve, and we were hired to recreate the work we did as a student project for Valve for Portal 1 and for Portal 2. And today we just wanted to talk to you about some of the issues we had trying to create the mechanic for portals, and then also some of the design, both the technical and some of the design issues that we had to tackle and work on to make the mechanic work properly. So Dave is going to start off and then I'll jump in later. DAVE KIRCHER: Hey, folks. As he mentioned, my name is Dave Kircher I was hired on specifically to work for Portal. So I'm going to go ahead and preface. We're jumping through a lot of topics today and jumping very quickly, so this is a very video heavy presentation so that we can jump quickly in and out. And I'm sorry if I go a little too fast. I'm kind of optimizing for the stream. So hopefully, if I have gone too quickly over something, you can review the stream and see it a second time. So without further ado, let's start off-- just quickly. I'm assuming that most of the people here have played Portal or at least are familiar with it in some sense. That's just an assumption. And that, for at least the technical portions, that you are at least somewhat familiarized with 3D rendering. If you're not, you may need to study up a little bit and then come back. But let's start off with just what is a portal? A portal is a discontinuity in 3D space. It's a 2D discontinuity where we basically define a 2D rectangle somewhere in space such that the front face-- sorry, the back face of the 2D rectangle is defined as the front face of another 2D rectangle. So I've got my simple little example here of this blue portal and this orange portal. We're defining them to be back to back, which gets us this result over here. So from the perspective of this little portal guy, it should look like there's another room attached with a cube in it. But we're not actually moving 3D space at all because otherwise we're trying to make sure that this perspective is true for both this guy and the cube. And then you'd have this weird overlapping space that doesn't make any sense to anybody. So we do a lot of hacks to make it seem like space is folding in these interesting ways without actually moving space. Another way to think of it is that it's a door. If you look closely at this doorway, it's a very standard door. It's a door like you walk through it, different stuff happens. But what I'm not telling you initially is that this actually isn't a door. For technical reasons, this level required a portal here because we needed this room to move. So even though it looks like a doorway, it's completely fake. And that it's a doorway that actually takes you about a half mile across the level. But it looks like a door, and so my job on the Portal series was to make sure that when we're creating portals that they feel to the player like a doorway. And if you think of them in terms of a doorway, all the interesting stuff for a portal happens on the inside of the doorway and nothing interesting happens on the outside. And it's my job to make sure that all the interesting things that are happening outside the door don't happen. Because that's all stuff that doesn't make any sense. So as you can see, I just flew across the level. And that's the other side of that door that we just looked at. And I'm walking through it and it's a doorway. So it's a door that doesn't take you a couple of inches. It takes you about a half mile across the level. Now we're into our rendering section, which is basically one of my main expertises in the portal area. So we're going be talking about quite a few things and I'm going to jump in quickly, so hopefully I don't spew it out too quickly. That's kind of my problem. So there are primarily two layers to render a portal of view. There might be more, but these are the two that I am primarily familiar with. The preliminary way that we did it with Narbacular Drop, which was the predecessor to Portal was with rendered texture. And then when we got to working on the Portal franchise, we switched to a method where you draw it all in a single pass using what's known as a stencil buffer and I'll be talking more about that in a bit. But there are tradeoffs to each method. So with a texture, you have to have separate textures per portal view. And if you have support for recursion, you have to have many, many textures pre-allocated to do this. So your memory growth gets big very fast. You have to use the Painter's Algorithm or something like it to render your portals. You basically have to figure out the deepest portal you can see into and render that one first. And then any outward ones from that you're going to render them because they're going to contain a view of that first portal. So you have to render it in that order. And I don't know if it's true anymore. It definitely was when I originally was working on the first portal. That you couldn't effectively use anti-aliasing, so you get small visual artifacts as you get close to a portal because it would be rendered as a texture that doesn't quite render the same way as the rest of the back buffer. But it is the simplest to implement, especially if you don't support recursion at all. It is super simple to do because you can ignore the Painter's Algorithm and just render all of them before you of your main view. By contrast, when you render with stencils, it renders the entire frame to the back buffer so you don't have any extra texture memory requirements. You're doing it all in a single pass. You're starting from your main view and working your way in. You actually have to nest it a little bit, so it's interesting. You are guaranteed to get homogeneous visual quality because it's a single pass. The way you're rendering the rest of your frame. But it has a lot of extra complexity of when you render them and how you render them. So this rendering portion is going to require quite a bit of spatial thinking. So I'm going to show you this video. Basically this is a layout I'm going to use a couple of times. Does this play? Hopefully-- yes, OK. This is a room layout that I'm going to use a couple of times where I've got an orange portal and a blue portal. And behind each one is a thin wall with some stuff behind it. But hopefully to help illustrate what's in front of the blue portal, you can see there's a whole bunch of blue stuff over there. So yes, that is the example layout I want you to kind of keep in your head because spatial thinking is important to actually have reference. Let this finish one more time. OK. Now this is something that pertains to both rendering with textures and stencils and I'm going to let this play once because I was advised that if I front load this too much, it sounds confusing. So while I'm playing this, I want you to look at the fact that when the orange portal is on screen and when it's not, everything inside where the orange oval is looks exactly the same for when it is and when it is not there. And so what I'm doing here is as I'm toggling between the views is I am teleporting to where the virtual camera is. That's rendering out of the orange portal. Whoops-- come on, go back. Oh, God. OK. I'm toggling back and forth. I'm looking into the orange portal, but I'm toggling to where the virtual camera is behind the blue portal. So if you remember back to when I said that we're defining the back face of one rectangle to be the front face of another rectangle, that means that they should be coplanar at all times. And so if you think of my player model in terms of walking it to the orange portal. When I'm rendering my exit view, I should end up behind the blue portal as I'm rendering out of it. So it's important to remember that all the angles carry over from that. And most importantly that whether you're rendering textures or rendering to stencil that nothing inside ever moves because it should be the exact same view angles, the pixels should be in the exact same place. If they're not in the same place, your math is wrong. And this is especially important when rendering with textures because one of the first mistakes I've seen several people do is that they render the entire screen to a texture. And then they map the entire texture to this little quadratic here and it looks all weird depending on how close or far away you are. But as long as you project the-- sorry. Trying to work with videos is not the easiest. So as long as you project where the vertices of your mesh are in screen space, you can reuse those coordinates as your texture coordinates and then it will line up perfectly. So that's the point of why it's rendering as one-to-one. You just want to make sure that you're rendering the same parts to the same part of the screen. Now I said I'd be using that previous layout a bunch and I swear I'm going to get back to there. But this is a much better layout for rendering with stencils, and so now you need to learn a new layout just for a minute. It's only used in stencils. But I've got these two portals looking at each other. They're kind of-- one stacked on top of the other, and they've got these light bridges that are just serving to show you that transparencies are kind of a special case. So I'm going to play it one more time. So you just got two portals facing each other. And even though they're tiny, it does make an infinite recursion down into the portals. So rendering with stencils. I'm kind of assuming that for this part of the talk that you have some idea what a depth buffer is. You may need to read up on that if you don't. The stencil buffer is very similar to the depth buffer in that it defines rules and operations for when we can wholesale just not draw a pixel or when we do want to draw it. And then also while we are drawing pixels, you can define several operations of how to modify the depth buffer. But for all intents and purposes, it's invisible to the user except for the end result. So stencil buffer, a lot like a depth buffer, but you're controlling the values in code instead of by vertex depth. So before we render any scene using stencils, what we're going to do is we're going to clear our stencil buffer at the same time as we clear our depth buffer. We're going to clear it to all zero values. And the stencil buffer we were working with with Portal 1-- I believe it only had two bits. I could be wrong. It might be up to eight bits, but it's not a lot of bits. So we need to be very conservative with the values we put in there. So we're going to clear it to zero. So everything in it is zero. And then we're going to render all of the OPEC objects in our scene and that's where we get to the visual I'm showing you here. So you'll notice that none of the light bridges are here. None of the cool fancy window stuff is here. So all we've done is draw in all the opaque objects. And then we take a special detour to render a portal. At this point, we've rendered this oval here. And while we're rendering the oval, we tell the rendering system to increment the stencil buffer wherever we render a pixel. So while we're rendering, all of the pixels here go from 0 to 1 and that's an important bit. So we're going to be able to use that to tell the depth-- to tell draw operations where to draw from then on. And then as soon as we've drawn the incrementing of the stencil buffer, we tell all draw operations from then on to only draw where the stencil value is 1. And we tell it to not modify anything. We're only drawing where there's a 1. And then we can basically just forget all about stencil buffers for a little bit and keep drawing. But at this point if you've been following along with the depth buffer, we've already drawn this nice little wall behind the portal. So the depth is the same as this little quad here. And so the first thing we do is we render a full screen quad with depth at maximum value, which does really effectively make this a hole at this point. And if we were to continue drawing opaque objects and things like that, they would just show up in this hole. So then we start-- after we have drawn, after we have punched our hole in depth and we've required that all draw operations have this matching stencil value of 1, then what we do is we just start over in our main scene again and just draw it again. But this time we move our virtual camera. Just the same operation as I showed you in the rendering. It's one-to-one, we just have to do a matrix transform such that we're behind the blue portal and we draw it again. And so, let's see here. I think I have a magnifying glass. So you may notice that we're in-- whoops. OK, I can't apparently zoom and use a laser pointer. So you may notice that the player model is there, and then the exact same setup as I had shown you before. It's the same set of quads and the oval again. And we do the exact same thing again. We tell it to increment so all the values in this tiny little oval here are now 2. And then at that point we tell, OK, only render pixels with a stencil value of 2 and then we can just ignore stencil buffers again. We punch the hole again, and then we recurse again. And we go into a value of 3. At this point-- I'm going to get more into detail on it later, but we stop recursively rendering to stencil buffers because otherwise we'd draw a whole bunch of scenes that we're not going to actually see. We pull a little trick that I'm going to get into. So as we've drawn all of our opaques, we would theoretically do our detour. We don't. And then we finish by drawing all of our translucent objects. And I know it's very tiny to see them there, but it will become more apparent later. I think that-- sorry, that's actually our rendering trick. And there, now we've actually drawn the translucence in that view. And I know this is very small, but it'll make more sense at recursion level 1. So as we draw our translucent objects, we're still all confined to drawing where stencil value is 2. And then once we are done drawing all of our translucent objects, we render the portal oval-- whoops, sorry, sorry. I'm going to pretend that we're drawing to the big oval here because it's easier to see. We would draw another quad at this level, sort of like a window, telling it to decrement the stencil value back to 1. I'm sorry, I need to take a step back. We need to replace depth so that there's no longer a hole there. So we draw the full screen quad with depth equal to the portal plane while still restricting to the nested view and then we decrement. Sorry. So by the time we've done decrementing, that means all of these pixels inside this first recursion are now 1 again. Every single one of them is a 1 on the stencil value. So we can continue rendering the translucence from the first recursion just like we did when we're doing the opaques. We can say just restrict your drawing to all stencil value 1. And then we finish our translucence there. We do the exact same thing again while we're going back to the main view. We fix up our depth and then we decrement the stencil values again. And then we just finish out our main scene, and now you have portals drawn using stencils. They required no extra texture memory whatsoever. So bouncing back to the scene that we had shown before this, one of the things that we had to solve pretty quickly is when you have some object in the middle of a portal, you have to be able to see it in two places at once. And the way that we do this is we literally just look up every piece and rendering geometry. It uses every texture and replicate it and teleport it every single frame to wherever the original is. And while we're replicating, this object over here. You can see that it's slightly more in front of the orange portal. So basically the rules are defined such that whichever object-- whichever side of the object has its origin in front of the portal is the master. And the origin for this cube is right in its middle, and origin is just a term that we use to define the one point in space that defines where this object is. So usually it's in the center of an object. Not always, but that means this is the real one. And this is our complete and utter fake one that we have to do for every single object that is penetrating the portal. Now when we duplicate geometry and whether we not-- whether we duplicate or not, we have another problem to solve. I'm going to let this video play. I'm going to be toggling a broken part on and off. So when the cube is not behind the wall, that's the fixed version. And when you can see it behind the wall, that's the broken version. So if you think about replicating geometry, we have replicated the entire model to this orange portal. Which means all the stuff that is supposed to be in front of the blue portal is also sticking behind this wall. Because once again, we have defined the two faces to be coplanar. So what we have to do is we have to use what's known as a clip plane to tell the rendering system, you know what? Just don't draw any pixels if the mesh is on this half of this half space. And we define the half space to be the portal plane. And we can turn this clip plane on and off as we're drawing objects inside the portal plane and that's what makes it work. Otherwise it would clip the whole world. I'm going to play the video again. It happens. So, yeah, we're just telling it, hey, you need to just ignore every single pixel that's on that half of all of space. Don't draw them. And that makes it so it doesn't seem like it's sticking out the back in weird ways that people don't understand. OK, now this is a very similar concept. Something that we coined the term "banana juice" for. Even back in Narbacular Drop because it's just confusing. And I know you're asking yourself, what in the heck is "banana juice?" That doesn't make any sense. So we decided to use a completely insane term for it. Because even our technical shorthand for describing the problem didn't accurately describe what it was. So we decided to use a term that-- it was obvious that explanation was needed. So what we've got here is I've got my orange camera and I'm looking into the orange portal here. And that means I've got my blue camera, virtual camera here, looking out of the blue portal. And if you remember back to my example, we've got this geometry that's behind the blue portal. And it's between the blue virtual camera and the portal, and if we render that, it's going to look completely broken. So "banana juice" is a term to define this broken stuff that you would see if you were looking behind the thin wall. And I have a video of it here. I believe I'm toggling back and forth between views just like when I showed you rendering as one-to-one. And that's me turning off the clip plane. This is what it would look like if we were in the virtual space and the clip planes were not enabled and then I go back to our main view. And you'll see as I move around in a second that it looks completely broken and it kind of breaks your brain if you don't understand what's going on. So that is "banana juice," and you fix it exactly the same way as with the entity clipping. You have clip models, but what we do is I'm going to replay the video here. If you're watching, this entire part of the level is now clipped. So what we do is while we're rendering a virtual camera, we just clip the entire world behind the portal plane. All of it. Everything that's back there. So that's how you fix "banana juice" too. It's not super difficult once you understand it, but I can tell you it took me about two days to figure out exactly what was going on when I originally saw it. It just didn't make any sense. So moving on again, I know we're jumping a lot and I'm sorry. We're just going to keep moving on at a quick pace. So infinite recursion is something that people kind of expected to see when they were playing portal. If you ever played the original Narbacular Drop, we didn't support any form of recursion and it was kind of a letdown. So I'm going to go into how this works. So in this view, you can see that we have this blue portal. That's our first recursion right here and it's taking up most of the screen. And then we've got this blue portal that you can see the entirety of it. That's our second recursion. And this one in here is completely and totally fake. So that one, there is no portal there whatsoever. What we're doing is we're taking whatever we see of this portal, the second recursion. We're taking that exact view from the previous frame. We're taking those pixels and then we're basically doing a fix up in case you moved your camera around. And we're applying the texture coordinates from the second portal to where the third portal would be. And by a completely fake, I mean we didn't even render this blue oval. That's just a copy of this oval right here. So it's the exact same thing as if you point a video camera at a video monitor that's showing what it's recording. You get that feedback loop. But we have access to a little bit of extra special math. That means that we don't get that weird snaking effect if you move it back and forth. We can fix it up quickly. But this video is actually going to show you about how this quickly breaks down. Because if you're thinking ahead, you might be wondering what happens if you can't see all the second portal. And the answer is that we stretch it. So as you watch the third one, it just kind of stretches off in weird ways. Which is a problem that, if we spend a bunch of time, we probably could have fixed. But in game development, sometimes you just call it good enough and move on because I bet anybody that played the original Portal never noticed this whatsoever. [LAUGHING] So another breakdown of it, which I find personally annoying and interesting at the same time. I'm just going to show the video of it first. As I'm walking, you'll notice at the third recursion, which is completely fake, you're going to see a pop. You're going to see every single time I walk through a portal, it pops around. So this is actually fairly easy to explain once you understand-- really understand how the hack works. So if you look at my visualization here, this is what the actual recursion would look like if we actually did it. So we've got a couple of portals here at these blue lines. And so inside our first portal that we're fairly close to, our field of view is really wide. And then as we get to our second portal, it gets really narrow really fast. But then as we get to the third, it narrows even more. And then the fourth, it narrows even more. But since we're cutting and pasting, the second recursion, if you look down here on this visualization, this is the hack. So we take this one, the second visualization, and copy and paste it onto the third and onto the fourth. And you can notice that this doesn't converge at all. It doesn't narrow. So we're seeing the same amount of wall around each of the recursions no matter what, no matter how narrow this magenta cone is. So as we walk through a portal, the magenta cone, we're picking a portal that's further off because now that's the second recursion after we walk through a portal. So it starts off narrow, which is closer to what it should look like at infinity. It should narrow to basically where you're seeing a blue tube. But then as we walk closer and closer to the main portal, then it's going to widen and widen and widen. And so there's just a pop where it snaps into place. So hopefully that made sense. And once again, completely changing topics because we got so many things to cover. So when we're rendering portals, we have to have a mix of rendering first person and third person. So in this case, you can see I've got my third-person model over here through this portal. Another third person model over here. And then we don't see it in the main view because I'm about to turn it on. It would look really weird if you saw the third-person view in the main view. Yeah. I mean, some games do try to fix this with very special representations. They'll try to draw just the legs or something like that. But, yes, so we have to have a complicated system to figure out when to draw third person and when to draw first person. And if you were to guess, I bet you would say, well, just render a third person every time you look through a portal. And it turns out it's slightly more complicated than that. I'm not actually going to get into the complicated version, but I'm going to show you how it's broken if you use that simple rule because why would life be easy and we would just be able to render just when we're on the other side of a portal. So in this case-- let me look up. So you'll notice in this case, I'm on a tilted angle. And this is a case where my feet are on one side of the portal and my eyes are on the other side of the portal. So it kind of breaks the original system that would say, oh, just render if you're on the other side of a portal. And so, yeah, it's a little more complicated. Not terribly. It should actually look way more broken than this, but we actually had the fix in several places. And this is a special build where I had to go back and break things and only broken it in one place. Yeah, OK. And then the last on our rendering portion. So earlier I had talked about how we need to duplicate geometry that is mid-portal. But there's also another thing that we need to duplicate, which there are screen space affects where we can query draw operations and things like that. And so one way that we use these draw operations that are in screen space is to determine how much light glare to use around these lights. And so how these work are basically we draw a quad while we're drawing the light. And then we say, OK, in a couple of frames I want you to tell me how many pixels actually drew. And we're not allowed to actually query this immediately because of pipeline reasons. We don't have the results for several frames. So we have to cache off that handle that says how many pixels did you draw and we'll get the result at some point later. Sometimes you're lucky and it's just one frame, but usually two or three frames-- you have to save it for a while. But you may notice that even though we're not replicating the geometry of the light, we're drawing two of them because they're in screen space. So that means that this query system had to be smart about it and I'm going to show how we have two separate results. Now if we had used the engine as it was originally written, there would be just one query for one light. But then that would mean that these lights would dim in unison. So we need to have separate buckets for each view of portals. And every view query that portal-- any view query that is issued while in that recursion, we have to keep it in a totally separate bucket and call it back later. And then as we walk through portals, we have to transfer those buckets. So if I were to walk into the blue portal at this point, all of those handles we have to transfer to the main view. And then all the ones that are from the main view we transfer into what was now orange because we would be walking out of this orange one if we walked into the blue. So, yeah, that is the quick set of rendering things I wanted to cover. So now I'm going to hand it off to my colleague, Tejeev, to talk a bit about design. Give your spatial thinking a bit of a rest. [CHUCKLES] TEJEEV KOHLI: So that was a lot of technical stuff about rendering of portals. And you can see it's more complex than it seems at first. The naive solution seems like we'll get you most of the way there, but then as you start putting in more things in the game and more ways to play a game, to interact with the game, you see there's a bunch of different complexities that you have to account for. And a lot of those complexities are not just in a technical sense, but also from a design sense. So I just want to talk through some of the issues that we came up with as we were making Portal 1 and 2 and some of the ways we tried to solve them. One of the first things I wanted to mention was when first coming up with the idea for portals, before figuring out if we should spend a bunch of time making this idea, this new game mechanic that most people haven't seen before. What we did was-- Dave and his team made a prototype of Portal in a 2D game engine that is used in DigiPen while they were students. And it was made in-house DigiPen 2D engine. And you can see here that it's a 2D version of Portal, but it's still got all the basic game mechanics that are used in Portal. And the main goal of doing something like this is to vet out the mechanics and see if they're still fun at their core. And part of what you do here is you playtest, right? You make this simple prototype, and you get other people to try it out and play it and say, hey, is this fun? Is this something that we should spend our next year working on as a proper 3D game? And the prototype you can see had most of the basic functionality there and kind of vetted out the idea of the mechanics to take it forward. And as we take the mechanics forward, one of the first things that you realize is this is a brand new mechanic that people don't really understand and you have a train them. Train them with how the mechanic works and also train them with sufficient knowledge so they can use that mechanic to solve puzzles, which is the core of the game. And one of the things that we did is you have to have certain sections of the game where you can be sure that the player has the knowledge that they need to progress. So a lot of this is about making sure that the levels you're designing are done in such a way that when the player finishes that level, they have that knowledge that you want them to have. And one of the ways we ensure that is through doing a lot of play testing, and play testing is something I'll talk about a little more as the talk goes on. But the basic idea of play testing is just getting someone else to play the game. And that someone else could be a coworker who sits next to you, your friend-- anyone else really. Someone you get especially to come play the game from outside the company, but usually it's just your coworkers, people that sit next to you. People that see you work on the game but don't know exactly what you're doing. And you can observe them and see what they're doing, get some feedback from them, and then use that data and iterate on the mechanic. And you can see here, this was a level in Portal 1. It was pretty early on, this level, and you could see the portals here. The blue portal here is moving on a timer. It moves from one to the next to the next. And the idea of this level was by the time players solve this, they understand that I go in one portal and come out the other. That's the basic idea here. And in Portal 1, this level did a pretty good job of teaching players that. For Portal 2, we have a very similar puzzle. I'm going to just try and play here. It's a pretty similar puzzle. The idea is the same thing. You have the three sections that the portal can go. The one change we made here was we move the portal away from a timer and moved it to a button. So this way the player has more control of where the portals are opening. There are a few reasons for this. The main one here is like the level in Portal 2 has a lot more visual noise. There's a lot more like-- it's an old level, a lot of foliage, a lot of destroyed stuff. So it's not as clean as Portal 1. And also, there's a case of Portal 2, there's a lot of people that have already played Portal 1 and are probably already familiar with the mechanics. So we don't want them to have to go through the timers and wait for all the things to happen, even though they know how it works. So this way they can just go in and show us that they know how the portals work without having to wait through all the timers. And the basic goal is the same thing. That by the end of this level, we're confident that the players understand how portals work. One of the other things that you learn through play testing is you learn what you need to teach the player. There's sometimes when you'll be making the game and there's certain things that you as a designer or as a creator won't think are challenging concepts or are things that need to be talked to players explicitly. One of those things that we noticed early on is this concept here where a lot of players kind of thought portals were one way. That you go in one and you come out the other and that's it. But they have to be taught that you can actually go in both ways. You can go in the blue one and come out the orange, or you can go in the orange one and come out the blue one. And so this puzzle specifically does that, where the blue one is the only one that'd be moving. The orange one stays stationary. First you go in the blue one, you come out the orange one, replace the blue, and then you go in the orange one and come out the blue one. The idea with this again is you have to figure through play testing is how you figure out the different things. The different discrete small things that you need to teach the player. And also try to figure out how to teach them in a way where they're figuring it out instead of you telling it to them. So for the most part in Portal 1 and 2, there's certain things that we tell the player. But for the most part we want them to figure it out and have that epiphany themselves. Because then they really learn it. If you just tell it to them, they might not take in the exact knowledge. Another thing here is this was a level in Portal 2, but we noticed through one of our play tests-- I looked through a few of our play tests that players were super hesitant to place portals on the floor. Even though this level is probably the fifth or sixth one in the game, and you've done that a few times in the game before this. But usually you are doing it way down there and doing a fling mechanic where you fly through the portal and come out. So players have placed portal on the floor before, but they haven't done it right at their feet. So we had to design a scenario here where the only way forward-- you're trapped in this black room with nothing else and the only thing you can do is place a portal on the floor there. And that's one of the things that you realize as you keep testing. You'll come across players of different skill levels and different knowledge of video games and different knowledge of how controls work. And typically you want to make sure that you're not only catering to the low end or the high end. You want to make sure that both of them can have a good time with your game. So you want to design puzzle games in a way that aren't super intrusive. If a player that sees this get here already knows that I can place portals on floor and go by. This doesn't seem like anything that's stopping him. This just seems like part of the level. But to a new player that comes in here and is like I don't know how to proceed, it takes them a while to figure it out. And then when they have that aha moment, they feel pretty smart about it. So you want to make sure that you're designing stuff in a way that isn't frustrating players that already understand the mechanics, but also isn't making players that don't understand the mechanics have to be super frustrated as well. Another thing that we had to do-- Portal 1 and 2 both have this mechanic where you go into a portal on the floor and come out one on the wall and it keeps your momentum and velocity and flings you forward. One of the things we noticed while we were working on this mechanic is that there's a lot of times when players don't exactly quite line up as they're falling through the portal. Which means that when they fall in, they're going to fall out-- they're not going to come out of the portal on the wall in the correct way. And a lot of times players won't know that they had the right solution, they just kind of messed up the execution a little bit. And we want to try and help the players in these cases, but again try to be not intrusive about it. Because you want to make sure that the players-- as they're solving puzzles, they're not thinking that they had the right solution but it didn't work the first time I tried it. So now I have to rethink the whole solution even though the solution was correct the first time. So one of the things we used-- we used a few different things to help the players out in this way. And again, with the idea of them being mostly invisible to the player. They're not always completely invisible and in some cases we have ways to opt out of them. But this is one of the things that we used. So if you notice here, the player's going to drop through the orange portal. But as you notice as I walk through-- walk forward here, I'm purposely not going to fall exactly straight. And one of the mechanics we had in the game was-- it was pretty subtle there, but I'm going to do it again. You'll see I'm walking to the side and the game kind of funnels you into the portal. So we had the special thing we used in portals, for portals that are on the floor facing mostly up. Imagine there's a cone coming out of the portal, and if you're falling from some height and if you're within that cone and the cone-- it's not super wide. It's pretty narrow. If you're within that cone, then we kind of funnel you into the center of the portal. So that when you're coming out of it, you're going to be lined up perfectly with it. And as you can see, the third time I did it there, it didn't happen. Because the way this works is that it only works if you're looking at a portal. So it works the second time, but the third time I'm going to go mostly in the same direction and it's not going to work. So that's our way of trying to make these things be non-intrusive. To where if players don't expect to go in that portal, it's not going to work. But if the player is looking at a portal and they expect to go in it, we kind of nudge them along a little bit. And you can see it here, and this is a second case of the same thing where there's a portal on the floor and the ceiling. And you can see as the funnel is working, the play is perfectly in the center of it. But I'm going to look forward a little bit and disable the funnel. And you can see the player's going to go off axis because the funnels are disabled and the player slowly went out of it. Yeah, the funnel is disabled now. And again, the idea of this is to reduce a bunch of the player frustration and to reduce a bunch of the false negatives that players get. You want to make sure that players that think they've got the solution, and if it was the correct solution, you want to kind of help them out a little bit. You don't to solve the puzzle for them. You don't want to give them, like, here's the answer. But you do want to try and help them out a little bit because that helps that makes the game a little bit more fun and reduces the frustration. So that was the help that we had for when you're entering portals. We also have the opposite and that was there in Portal 1. And in Portal 2, we introduced something that was the opposite of a helper, which we used when you're coming out of portals. So Portal 2 had this mechanic called Aerial Faith Plates, which is pretty straightforward. You step on this faith plate and it propels you to the air. And the level designers can place the faith plate on a level and can kind of control the trajectory of the arc of where the player is going to fly. And this arc is not really visible to the player, but it's pretty apparent based on the level design. So you can see in this one, I'm going to play the video as I'm talking and then maybe play it a couple of times. So the tech that was developed for these Aerial Faith Plates is something that we reuse for a fling helper. So you can see here there's all these-- I'm going to turn on some debug draw. And you can see right here. So this green arc here is the arc that's on the faith plates, but you can see there's some stuff coming out of the walls there as well. So this is a part of the level where the player is going to fling out of. He's going to fling a box out of that actually because he wanted this to work for objects as well as the player. So you can see as the box goes through here and then here, these are those faith plates. And then when the box comes out of that, we have the box follow the arc that's kind of predetermined. Because that's I think what the player is expecting at that point. They expected to have solved the solution-- solve the puzzle. But the funnel, the trigger here-- this kind of corrects the arc to make sure that it's always going to go in the place the player expects. And we also have a case of the same things working for the player. So you can see here there's two different arcs that are coming out because we doubled up the triggers over here. The way these triggers worked in the game is they won't always enable when the player touches them. They require a minimum velocity threshold. So the player has to be doing most of the work. So the player has to have figured out a way in the level through the puzzle design to get that velocity. But we know that there's some differences in physics and differences in the exact mechanism you might use. So we're just saying if you got the minimum velocity that we acquire, we're going to take it all the way there. So in this one, you can see we have two different cases. So if I just fall out of the portal, it's not going to activate any of them. If I somehow manage to get some velocity, is going to activate the fail case one and take me there. And the reason we have the fail case one is because we want to make sure that if players somehow get most of the velocity but bonk on the wall, they don't keep thinking that they can-- that's the correct way to do it. So we want to make it obvious that you failed. So again it's the same way. We have to help-- you're helping the players out but not by giving them the solution. Just by making it obvious that the thing you did was correct or wrong. And then if you do the correct way in this level, which is to get philosophy doing that, and then you make a portal there, you're going to do the correct thing and swing out of it. And again, the main idea here is to get rid of those false negatives. Especially here because there's a few different spots on the wall that you can put a portal. And we don't really want to restrict a lot of that and just put the one square on the wall. That is the solution square. Because again, if you put the portal down here or put the portal up here, the arc is going to be slightly different. So this mechanism we had just kind of corrects those arcs and makes sure that it goes in the one or two ways that we want. Another thing we added in-- this we added in Portal 2-- was highlights for your portals so you can see where your portals are placed through walls. And this is something that's super useful in levels where you have to keep track of which portal you placed over there. So you know which one to place over here. Because sometimes it's like, OK, I just got out of the blue one and the orange one's over there. So if I place the blue one-- oh, I got to do the whole puzzle again now because I placed the wrong one. So this helps a lot in just making sure that you know where your portals are so you can be like I want to come out of that one, so I'm going to place the other one. And this is something we added in Portal 2 and it was pretty helpful. And it's also helpful in the co-op version of the game. Because in the co-op one, you want to see where both the players' portals are at all times and this kind mechanic helps in that. Another thing we added to kind of help the player a little bit is a thing we call the placement helper. And this does not use a whole lot in the game, but there's a few sections in the game where we want to encourage the players to come out of a portal in a particular direction. So we have these things that we place in the level with a certain radius. And if you place a portal within that radius, we just kind of snap it to the direction-- to the center of it. But they don't a timer. So if you place one portal and you're like, oh, I actually want to place it over here, you can always opt out of it. And that's again what I was talking earlier. You want to add something-- excuse me. You want to add these helpers in a way that, for players, they're mostly invisible to most of the players. But the players that want to opt out of them have a way of opting out of them. [COUGHS] Excuse me. So you can see the first portal that's placed does get snapped, but the second one that's placed is exactly where the player wanted. And we use these in a few spots in the game, but they weren't used a whole lot because for the most part you want to have-- you want to make sure the player feels like they're in control. And one of the other things that was a lot of fun while making Portal, and Dave will talk a lot about this-- excuse me-- will talk a lot about this later is the physics of portals, or physics of objects interacting with portals. And for the most part we're trying to be super accurate with it, right? We're trying to make stuff work the way players expect in real life because that's kind of what we're trying to simulate here. But one of the things that we thought that we added here-- that we thought was more fun than accurate. So you can see the-- [COUGHING] Sorry, I'm a little bit sick. You can see here that when the box starts off, it's just resting on the floor. So it's got no initial velocity whatsoever. So when you place the blue portal down, the expectation is probably that it keeps resting there or maybe it goes in the center of the portal and just stands there. But that's not a super fun game mechanic. So here we just have it be so that objects coming out of portals have some minimum velocity. So they always have some minimum velocity. And this works in lots of other parts of the game like the paint. And you can see here that there is some air resistance that takes place and the paint does slowly come down. But once it comes down to this minimum velocity, it just stays there. And this is-- it's like completely fabricated fiction. I guess there's no real physics for this. It's just kind of like this is more fun than trying to simulate real physics. So you can see here air resistance is making it go down, like they're slowing down. But once they get to the minimum velocity, they just stay there. This is about it. So once it gets here, it's just going to stay here. It's not going to go below that. And speaking of gels, the gels actually came up-- were an idea that we had for our student game that we made while we were in DigiPen. It was called "Tag-- The Power of Paint." And in Tag, you had a paint gun that you used to shoot the different colors. And the Portal 2 mechanic was adapted from this and it's pretty similar. But one of the things we did get rid of for Portal 2 was the idea of having the paint gun. Because one of the core ideas we had while working on Portal 2 was that any mechanics we add to the game should really work with portals and should really interact at a core level with portals. So we thought instead of using a gun to move the paint around, it will made much more sense to use the portals to move the paint around. And that was kind of core not just with the gels, but with any new mechanic we added to the game. Was that portals is the core idea of the games. Everything we do should kind of center around how portals work. I'm just showing you the different colors we had in Tag. One of the colors that we added in Portal that wasn't there in Tag was the portal gel. And this was again going with the idea of how do we make the gels and the portals interact better. So this one just lets you spread around white paint so you can put portals anywhere that the paint can go. And this is a pretty cool mechanic in that it allows for a lot more open-ended level design and a lot more player freedom. Because you can play portals essentially anywhere now. Because for a lot of the game we're restricting where the players can put portals on the black surface or the white surface. And this just allows-- you can just put white anywhere and put portals anywhere. We didn't use this a whole lot because it is pretty open-ended and it does break a lot of puzzle designs. But there are a few cases where we use it in a pretty open-ended way and have the player just kind of have fun. Spend some time painting the whole level and then figuring out what to do. And these kind of levels usually have a couple of different solutions because we don't know where the players are going to paint. So we just put a bunch of different ways to get to the exit and players. Some players figure out all the knobs. Some players find the first one and just go there. And it helps to break up the pacing a little bit from the conventional puzzle design with the specific spots where here are some white spots, here are some black spots. So it helps break that up a little bit. One of the things that didn't make it through from our student game was the sticky gel that you saw in the student version. So this is going to look a little bit broken because this is from a really old version of Portal 2 because the sticky gel got cut pretty early on. And you're going to see some stuff here that doesn't really make sense, but just go with it. So you can see we used purple instead of blue here. So you can jump on-- you can walk on walls and stuff, which is pretty cool. So here you can see there's blue paint coming out of there but you can't see the actual paint blobs because there are invisible for some reason. I couldn't figure it out. But you can see the actual paint on the walls, on the floor. So this is just an idea of the kind of puzzles we were trying to come up with using sticky paint. There's an extra portal there for some reason. Ignore it. This is a really old version of the game. So this is the kind of puzzles we are trying to come up with. Of combining the different paint colors and portals together. But we did end up cutting this feature though. There were a few different reasons. One of them was obviously it is quite disorienting. You can see going up a wall and trying to figure out where the ceiling is, where the floor is. Especially in a lot of these levels where they're mostly just black and white. It gets pretty disorienting and we had more than a few play testers complain about that. But the other big reason that we cut it is because it didn't really interact well with portals. You don't really want to walk into a level and have the pots already placed for you. And there's no real good way to make pots on the entire wall without having to place the portal like 50 times. And also it didn't really interact well with the portal player physics and portal physics, and Dave will talk some more about the player physics through portals. And this is one of the things that you can see. We had a paint gun for a little bit, but we ended up cutting it. So you can see I'm painting the wall over here and I'm going to walk on the wall. But as I enter the blue portal, you can see oh, it's not going to let me go through. But if I go through this way, it works. And that's just one of the things that's like, well, we've got to solve this. We've got to ship like this. We've got to solve the problems. And we spent some time trying to work on these issues. But at some point, you realize that you're not guaranteed to solve these problems no matter how long you spend on them. So at some point you've got to just be like, OK, I don't want to spend an extra month or two trying to fix these problems not knowing if you'll get there. And plus there's other reasons why the mechanic isn't working out. So let's just stop working on this and work on other stuff instead. Another thing we ended up cutting-- this is from Portal 1 that was present in Narbacular Drop was the ability to place portals through portals. And it's a pretty confusing thing and that was the main reason we cut it because most players just thought it was way too confusing. Because you're placing the blue portal by looking through the orange portal here. So the blue portal is-- he's pointing through the orange portal here and facing the blue portal over here because the other blue portal is behind them. It's just like-- it's too confusing. And also it doesn't-- there's not a lot of puzzle design that you lose by disabling this feature. The thing you do gain is players aren't getting super confused and also you're not necessarily cutting a bunch of puzzles that you can't make now. So this feature got cut as well. And this is something that we didn't really cut, but we stopped using in Portal 2 that was used a little bit in Portal 1 was the idea of a double fling. And I'm going to show it here. So double fling is basically placing a portal while you're falling out of a portal. And it's one of those things that it works pretty well. It's a pretty cool mechanic. And it was used in a few spots in Portal 1. A couple of puzzles required it, like this puzzle here required you to do this double fling. But one of the things we noticed was a lot of players have difficulty in executing a lot of these super hyper-sized, high-precision movements even though they know what the solution of the puzzle is. So players will walk in this room and figure out, OK, I've got to do this, I've got to do that, and this is going to work. But then a lot of players have trouble walking out of a portal, making a portal as quickly, and it adds a lot of stress. And we wanted to move away from a lot of the twitch movement based stuff and towards more of a kind of, aha, I got it. That kind of stuff. And once you get it, we don't want you to spend a bunch of time in making sure you get the precise movements right. So this feature we didn't really cut it. It's still a mechanic that works in Portal 2, but none of the puzzles in Portal 2 required it anymore. And once we added the level editor, a lot of the puzzles people are making do require it and a lot of players like it. But it's not something that we thought we wanted to make everyone have to do. Another thing that we changed from Portal 1 to Portal 2 was these energy balls. These energy balls at the time-- part of the reason we used them in Portal 1 was because they were there in Half-Life and it was an already created mechanic that we had that we could just keep from them. But the basic mechanic is these things fire-- these things fire this ball that bounces around and it needs to go in this receptacle here under my gun right now. And it should go in this receptacle here and once it goes there, it finishes the puzzle. There are a few issues with this mechanic, though, in that there's a bunch of timing element involved here. Because the ball takes time to travel. And also if you get hit by it, you die. Which, I mean, it's fine. It's a game mechanic But for Portal 2, we just thought, how can we improve on this idea? And the thing we came up with was using lasers instead of the energy balls. Lower the volume a little bit. So here you can see it it's the same level from Portal 1 and you can even see the energy ball dispenser going away and being replaced by a laser because we want to make sure the player is like, GLaDOS is improving these mechanics now and got better versions of it. So the laser effectively is very similar to the energy ball. It goes in one and you want it-- it goes in over here and you want it to go to the receptacle over there. The big advantage here is that the reaction is instant. So if the player got the solution or not, it's instantaneous. You don't have to have situations where you place the exit portal and now you have to wait for the ball to go all the way across the level and see if it lines up or not. This way it just instantly does it. Plus it also opens up a bunch of different game play opportunities because now you can use multiple relays in the same level. You can have the cube that redirects the laser. So overall it felt like an improvement over the energy ball. And talking about lasers, so far we've been talking about a bunch of these smaller decisions we've made to solve these smaller problems as they kept coming up, like entering exiting portals, making sure things are lined up or not, improving on the specific game mechanics. But one of the things that you need to do when you're trying to make a whole game is to see how these mechanics come together and how you can combine them together to make a whole game. To make a few puzzles that increase into difficulty, complexity, and go towards some crescendo. And one of the ways we did that is by kind of using this kind of process that I'm going to go through. And we used it a couple of times both in Portal 1 and in Portal 2. And there's a few different mechanics that we used the cycle over and over for. And that's kind of how the entire game track is designed. So it starts off with an introduction, and the introduction is the puzzle we just showed you. That's the intro puzzle for lasers and it's really straightforward. It just shows you the mechanic. You go through one portal, come out the other, goes into the receptacle. It's really straightforward. Introduces the mechanic. Most people would get tripped up on this. From there, we then try to saturate the player with that same mechanic. We introduce different twists on that same-- without introducing a whole new mechanic, we just introduce different versions, different tweaks on that same idea. So this room still only has lasers. But now we've introduced relays and cubes. And you can experiment, figure out how to connect the three lasers together. Figure out how to move the cube, figure out how to move the laser through the portals. But still it's only lasers. Nothing super complex yet. Then we give you more of that. We give you more of just the same mechanic. Here there's two things firing lasers and two things you've got to connect. And so it's the same idea. It's like just using lasers, but not super complex. Just building on the complexity little by little. Followed by a puzzle that's like, OK, this is a puzzle that's going to teach you all about lasers. By now you've seen lasers in a few different ways. This one, once you get this, you understand how lasers work. You know everything there is to know about how lasers work. So this puzzle here-- excuse me-- that's two cubes and three things firing lasers, and on the other side of the puzzle there's three things-- you've got to connect them. And this puzzle is very difficult, but by this point, you've been slowly introduced to different ideas of how lasers work and this one is taking them all together. And then once we've done that, then we start combining them. Then we start taking, OK, now you've got a laser and a different cube and a bridge. And by this point you've seen a whole separate-- we've done the whole introduction, saturation, graduation track with bridges as well. So by this point, you go in there and, OK, I know how bridges, I know how lasers work. How do they work together? How do I combine them together? And then we start escalating from there. And then you go into this puzzle that has a bridge, has a laser, has a turret, has some cubes coming out, has a catapult, has a bunch of this stuff. But by the time the player gets here, they're not really overwhelmed by it because they have been introduced to all these mechanics separately and also smaller combinations of them. So that when they get to this point where there's a bunch of different mechanics, they know how they all work individually. And that's kind of the process that we use of slowly ramping up the difficulty, first with a single mechanic, then combining them. And then that's kind of how we take the individual smaller design elements and combine them together and turn them into the whole game. And now I think Dave is going to come back and talk some more about physics. DAVE KIRCHER: And after I cover these last four bits of physics, we're going to open up for questions. I know we have a whole miscellaneous section that we've outlined here, but that's more just buffer material. So I'm hoping you're going to put your spatial thinking caps back on. So how we handle portal transitions is there's two distinct methods. One is that we've got volumes here, which we call touch volumes or trigger volumes. And those are centered around the portal. So I've got my blue portal here and that was green volumes here. And you'll notice it's entirely in front of the portal-- that's important. And then we've got this yellow volume here. So the yellow volume is-- it's whole job is to tell us which objects in the world are just kind of close to a portal, and I'll come back to why that's important to the minute. But it separates us from having to think about objects that are way out in the world all over in the white space around here. We don't have to think about them. And we also know they're not objects behind the portal because we're only interested in stuff that happens in front of the portal. And this green volume here is where most of the magic happens. This volume says the objects in it are so close to a portal we need to think very hard about what they can do and what they can't do. We're going to let those objects start passing through the portal. And so we keep these objects in two separate lists. Objects that are in this green volume no longer intersect with any objects out in the white space out here. They don't have to think about them. They're kept in a completely separate list and they don't collide with them at all. They also don't collide with world geometry. I'll get to that in a bit. And then objects in this yellow volume are the only ones that the objects in the green volume have to worry about. So these are objects that are just kind of close to a portal. And so another important interaction with portals is ray casting. So we're only interested in rays that pass through the portal quad. So if a ray happens to just pass the portal plane, but not intersect the quad, we don't do anything with it. It's not special. We just treat it like any other ray in the world and let it do its merry thing. But we got this magenta guy. It intersects with the portal. So now we have to recast a new ray out the other orange portal which essentially gives us two ray segments. And if you think about that, if you were to write any piece of code that just did the ray casting and hand back two ray segments when somebody was expecting one, you're probably going to get weird results. So this means, the fact that this is happening, means that we have to go through every single system in the game that possibly casts a ray through a portal and fix every single one to understand. But if we give you back multiple segments, different things happen. Instead of assuming that this starting point goes directly to this end point, which doesn't even go in the direction it wanted to in the first place. And so at its core, remember how I told you every object had an origin, a single point that defines where it is in space. We use the ray casting to determine if an object that's in this green volume and just kind of moving around. We use a recast from one point where it was one frame to one point where it was another frame to see if it either passed through a portal or outside the portal because if it went over this way, we do nothing at all. If we went this way, we need to teleport it. So that's the basics of our handling. So how do we let objects pass through walls? This is one of the things I spent a whole lot of time on because we wanted our portal transitions to be very seamless. Remember in one of my first slides I showed you. It should be like a door. People expect to walk halfway through the door and just stand there. And how we do this is-- I'm going to talk about it a bit first. Whenever you place a portal, we take a snapshot of all the world geometry around you and create a very small representation of that and carve a hole in it. And we don't do this for the entire world because that takes way too long. And by way too long, I mean a quarter of a second. And in game terms, that's just way too long. I don't know if it was a quarter of a second. I remember originally that we had a problem where I think carving the mini-version took a quarter of a second, so it probably took several seconds. So I'm going to show you a scenario here where I've got a portal and it's going into-- it's going along this corridor gateway, gangplank thing. And it's going to go into this little classroom area. And as I go back around the wall, I'm going to show you a debug mesh of our collision representation. So in this debug representation, we've got these green lines. These green lines and then also these cyan lines-- or I'm probably mispronouncing that. I call them bluish, but my colleague has told me I need to call him cyan. [CHUCKLING] So I'm going to call them bluish now. So these green lines and the blue lines are in local space. So they're with the blue portal that we placed locally. And I know it's super hard to see, but there are a bunch of red lines over here and some magenta ones. Those are from the other portal that's in the classroom that are flipped and glued to the back of our local portal. So it's all in this local space and around this blue portal. We put some new stuff behind it and some new stuff in front of it. And so you may be asking yourself what the colors actually mean? Green here is representing a brush geometry, which most level editors, you can create walls and various shapes directly in the level editor. And at least in our terminology, we refer to these as brushes. So they're usually very simple convex shapes and super easy to deal with. And this bluish geometry is from what's known as a static prop, which is a model that somebody modeled in a model editor. So it's going to be arbitrarily complex, but it has to be made up of convex shapes. But we take a small snapshot of that and then carve it up. Sorry, I forgot to mention. So we call it a static prop because we are guaranteed it does not move. And that's very important because it's really easy to simulate things that don't move. They don't move. And the same is true of the red and magenta here. The red is the brush geometry on the paired portal side and the magenta is static props on the other side, which is mainly the desks. And as I'm looking through here. You can see just a small snapshot, and then you can see this magenta outline here of the desk mesh on the other side. It's important to know that that's not me looking at the mesh through the portal. That's the local space version and it just happens to line up the desk because we have to make sure everything lines up. Otherwise your physical interactions will seem weird if something is halfway in a portal and it's kind of not colliding with something or it's colliding with it wrong. As I walk through, you'll notice all the colors change because we switched spaces when I walk through in a second. So now all the colors are local space for this side. So, yeah, that is how we carve a hole. It's a very, very small area of the level that we carve a hole in. And so we're getting back to the volumes I showed you two slides ago. If we carve a small representation of the world, we have to know when the player is colliding with that versus the regular world. Because if they're colliding with the regular world, they're going to collide with the wall that's behind the portal and they're not going to go through it. So we have to use exclusively that carved version when they're close to a portal. And we do that-- we're using the same volumes I was talking about earlier. This is a 3D representation of them. And you'll notice that they have space-- a large amount of space above and below the portal. That's important because it's a 3D space instead of a 2D space. So as I enter the yellow space, I still collide with the world. I still collide with all the desks and things. Because I'm still-- while I'm exclusively in the yellow volume, I'm still colliding with the world. I'm going to show you. It's a bad example, but it's the video I've got. I'm going to hit this chair behind this desk because it's still in the real world. And then as I transition into the green volume, I am exclusively colliding with our carved version of it. Which-- that was a bad frame to cut. If I happen to look back in the portal-- which side is scrubbing? OK. Sorry. So if you happen to look inside the portal, you might be able to see it. There is-- I know it's super hard to see, I'm sorry. But we did carve a hole. There's no there's no geometry right here to stop us going in. And since we're exclusively using this new mesh, we're allowed to just go through that space. OK, so more importantly than static geometry, which doesn't move and is super easy to physically simulate, we have dynamic props and things that move. Specifically in this case, boxes. So the way we model this is very similar to how we did with geometry. We're going to be duplicating everything and I'm going to show you by walking in a portal. So this blue box that just appeared is my player. My player of physics object that's replicated from this orange portal to the backside of the blue portal. And this is using a system known as a physics shadow. At least that's what our system is. I'm not really a physicist. That's just what we call our representation of it. So I mean, I haven't dealt with many physics systems when I talk about that. So what a physics shadow does that's different than our rendering geometry is we're not allowed to actually teleport it from one frame to the next because if you teleport a physics object, then all sorts of interactions that intersect, they have no previous basis to go from. Of like how to solve that. They can't rewind time because they've suddenly teleported into an interpenetrating space. So all of our physics objects-- we give them a target of where they need to go. Sorry not all of our physics options are shadows. So just like the player volume and just the examples I'm about to give you. We told them where we want them to go and they try their best to apply forces and rotations to go there, but if it doesn't work, we're kind of SOL and they do their best. So I'm replicating that for the player over there. And we're also going to replicate it for the cubes in a second once I get around to placing them. And so it's important to note that we're not really solving the discontinuity in space because that would be way too hard, at least for a person of my skill level. What we're doing is we're saying each side has-- this cube over here is the master of it's physics and this cube over here is the master of its own physics. And this cube over here is just trying to replicate whatever this guy is doing. So they don't quite line up, but they work well enough. And in game development, good enough usually goes a long way. So as I'm using it, you might notice they don't quite work super well, but you can see that I've got this representation over here. I'm pushing it in my virtual version and it's all lining up kind of. And, yeah, that's how we do it in Portal. So I'm going to go ahead and tell you that I'm really glad that we didn't have levels with more than two cubes because if you try to do this with a train of cubes-- three or four-- it breaks down horribly. And this last little bit is me just showing you that we're not intersecting with anything in the back of it because we're not inside the green volume or the yellow volume because we're behind the portal. It's really important to manage your lists of what can interact with what when we're faking holes in space and overlapping space. I spent a whole lot of time on this. And I think that is the end of our physics material. So we had some more miscellaneous filler material, but it looks like we've ran over a little bit of our initial time. So we're going to open up to Q&A now. We might get to our miscellaneous material later. But, yeah, if anybody has got questions, now would be a good time. AUDIENCE: Could you talk a little bit about how lights interact with portals, or just lighting on objects and, like, will you get shadows from the portal? DAVE KIRCHER: So originally, I had a slide on that. TEJEEV KOHLI: The question was about lights. DAVE KIRCHER: Oh, sorry. Yes, sorry. The question was how lights interact with portals and shadows and things. So I'm going to preface with saying that most of this stuff I did a decade ago. So if I say something that's not true, I'm not trying to lie. I just don't remember it. So basically there was a time during Portal 1 where we tried very hard to make light work through portals and we kind of settled on a cheap solution. Where we would define a point barely in front of one portal, see what lights were projecting what amount of color on that, and just kind of make it a massive sphere on the other side that would kind of do that. So the downside was is that you only noticed it in cases that were very high contrast, which is also the case in where it was the most broken. So we just don't do it. TEJEEV KOHLI: On Portal 2, we tried for a while to have the portals themselves project light on things and that was also kind of broken for a while. And then we just took it out. DAVE KIRCHER: Yes, so we just punted on that one. Too hard. TEJEEV KOHLI: Any other questions? Yeah, sure. AUDIENCE: What were the performance implications of having to draw on that stencil buffer multiple times? DAVE KIRCHER: So the question was what were the performance implications of having to draw multiple scenes with the stencil buffer. So it's very analogous having to just draw a more complex scene. You're just drawing more quads and things. On one of the slides in our miscellaneous section-- you know what? Why don't I just go ahead and jump to it? So it's very important. So when we're rendering things in a 3D space, we have what's known as a frustum. It's kind of a pyramid, which comes out from your camera. And you can use it as a very quick test to see if you should even bother rendering something at all. So I've got-- I'm going to use my side-- my sides. The sides are defined by the screen itself. So the screen that you're drawing has a top, has a bottom, so those project into space. So we take our one side we can say, OK, if an object is completely on the other side of this plane, we don't even need to bother trying to draw it. We can just skip it. And so one of the optimizations we have in Portal is that every time you look through a portal, we can find the frustum to a smaller space. I took the easy route in that I kept it as an object that still had four distinct sides. So sometimes it's a little bit broken. But in this case, you can see-- in this case, you can see I'm looking through a blue portal at this little button here. And I've got this-- it's probably impossible to see, but I've got this mesh coming out. This is the updated frustum of everything we try to draw. So you can see it mostly just encapsulates a little bit of level and the button itself, and that helps us not even attempt to draw the complete scene over and over again. But I don't think I ever did a performance analysis, so I can't give you concrete numbers. But it was better than trying to draw the entire scene over and over again. Because since we still had the depth buffer on our side, we had already drawn most of the screen. And then we also had the stencil buffer telling us not to even attempt to draw most of the pixels. It was not nearly as bad as trying to render the entire scene. But we did find that for the graphics cards of the day, which not even all of them supported stencil buffers. Some people that played Portal 1, they got textures. We found it was best to just limit to two recursions because we could do our depth, or we could do our recursion fake and it worked pretty well. And I don't think it was terribly expensive even for the cards of the day. TEJEEV KOHLI: I know there were cases during Portal 2 when we were trying to make it work on consoles, there was a lot of proof tests. There were four cases, especially in co-op, when you're playing in split-screen with four portals on screen at the same time all looking at each other. It's like 16 views being rendered of the entire world at the same time. And there were these like weird edge cases where like, if you do that, you get two frames per second. Just don't do that. [LAUGHING] There was a few things in levels that had changed where-- like the corner case was the worst. Where if you have a wall like that and you can put a portal right next to each other on both sides of the corner. So we had a couple of cases where we had to actually change the levels to not have those cases. So you can't play-- so we just moved the corners apart like 16 units or whatever. So you can't always see both portals through both the views. So there was stuff like that we had to work through especially for consoles back in the day. Like we were working on PS3 360s. I'm sure now it's better, but it's been a long time since we've done that. DAVE KIRCHER: If I remember correctly, using stenciling was strictly less expensive than using textures, because you're still going to draw the same amount of geometry, but you have no texture cost whatsoever. Hopefully that answers most of that. AUDIENCE: How did you cover all of your bases for each level, so that a player could never get stuck? In the sense that if you fell off a cliff or maybe accidentally erased a portal, you could always find a way to go back or to keep progressing forward? TEJEEV KOHLI: The question was about how we covered our bases to make sure the players can't get stuck in levels if they do something bad. Mostly through play testing and then later on through bug testing. It's a lot of just trying to make sure that you can see parts of the level from different parts. Towards the later process of when we're getting closer to shipping, we do something called the greasy pig pass for the levels. Where we make sure the players can't literally get stuck on walls and stuff as they're walking through them. So we have a bunch of invisible geometry there that'll make smooth the collisions along stairs and along-- because especially in Portal 2, there's a bunch of these broken pieces and a bunch of foliage and broken parts of the levels that are tilted at weird angles and stuff. And it's like for the most part, we left them as is. But a lot of cases we had to go in and put invisible stuff everywhere to make sure that the wall might look like it's broken up into like 15 different pieces, but the player's just colliding with a flat plane. It's to make sure that those things don't happen where the players don't get stuck in spots. And there's also a bunch of level design work that goes around and making sure-- because we have to take care of the opposite as well, right? We have to take care of, well, we've got to make sure the player can see the exit portal from the start of the level so they can't just portal and portal and get to the end. And so doing that process helps with what you are asking as well. Because if you can make sure that the exploits aren't there, you're also getting rid of cases where the player can get themselves in a bad spot. And so it kind of works itself out through the course of development. You don't go in starting to make a puzzle or making a level with that in mind a whole lot. But as you start refining it, things get tweaked and things get tuned. Some things you might be have to tweak for like port reasons. Like this doesn't work on PS3. So you got to go, OK, I got to fix this and tweak the puzzle a little bit. But then once you tweak the puzzle, now you've got to do the whole testing all over again. Because all right, I can't just put a portal place on there because now you can solve the puzzle without doing any of it. So there's a bunch of work that has to go on from that sense. DAVE KIRCHER: And it's important to note that as we get closer to shipping a product, more and more of our dev team switches to play testing. And we have some very smart and mischievous people that that specific question of how do you make sure you don't get stuck is on the checklist. It was on my checklist at least of, like, I am going to make sure I can't get stuck. I'm going to sit in this level for about half an hour and think long and hard about how to get myself stuck. And if I can't do it, then pass. [CHUCKLES] AUDIENCE: Was there anything that you would have liked to have pursued, but didn't, due to either time constraints on shipping or the limitations of graphics cards of the day that you thought about, but for whatever reason, couldn't do? DAVE KIRCHER: The question was was there anything that we didn't pursue for various reasons before shipping? And I can't think of anything. I think I was pretty happy with what we produced. Most of the things I focused on were bugs that we shipped because once again, getting back into shipping mode, as you get closer to shipping something, you want to touch the code less and less and less. Even if you know that the fix is going to work 100%, it will definitely work, it might break something new. So I certainly have a small list of things that I wished I had fixed, but nothing that I wish I-- AUDIENCE: Basically, like, features like the sticky paint, for example. DAVE KIRCHER: Yeah, yeah. Yeah, I can't think of any features that-- TEJEEV KOHLI: There's stuff that we worked on that obviously didn't ed up shipping. Some of them we touched on over here. I don't know if sticky paint was something that we should have worked more on, though, because I feel like we spent a lot of time trying to get it to work. And the reasons for cutting it then are still valid now. So I'm saying if we were to go back, I don't think we would try to solve that problem. We'd probably come up with new problems to try to solve. We did have-- like another thing we tried was I think we tried it after the game shipped for like a DLC expansion was reflection paint. So it was paint that would reflect the different elements of the games like reflect lasers or reflect light bridges. And we didn't get too far with it. Again, it leads to a bunch of weird levels because you have to have all levels have angles. Because if you think about Portal, most of the levels are like 90 degree walls and stuff. And 90 degree reflections don't go anywhere. So we had to have-- make this super contrived looking levels with these weird 45 degree angles everywhere and they can reflect things. And then all the problems like, well, how often-- how many bounces do we allow and things. And also stuff just looked weird, like tractor beams reflecting off of walls just looked weird. There's probably other ideas that I can't remember right now, but there are-- a lot of them get cut short pretty quick because the flaws are really apparent pretty quickly. You might sit down and think, oh, this is a great idea. I'm going to go out and work on it. And then as you start working through it and testing it out with others, you start seeing all the problems. And those problems get apparent pretty quickly. And at that point, you make the call. Just be like, this is not worth pursuing anymore. We had some more game modes we were trying to work on. I think we had a competitive mode for a little bit we worked on. DAVE KIRCHER: We actually have a slide about that for a little bit. It didn't get fleshed out. But after Portal shipped, we immediately said to ourself what does multiplayer look like? And so the first thing we tried was deathmatch. Turns out that's a horrible idea. Everybody wants to just put portals under other people's feet. So you spend most of your time just completely disoriented or confused. And then I think we made a collect the coins kind of like, oh, do flings and things. But once again, everybody wanted to put their portals under other people's feet. So now we have co-op. TEJEEV KOHLI: The co-op was very successful, I think. And there's a bunch of other challenges that come with co-op that we had to work through. I think, yeah, we tried some more different competitive modes. We tried a time trial kind of mode, but they're doing it together. But that's effectively just playing two single player games at the same time. So there's not much interaction. Any time you let players interact in a competitive way in Portal, they just want to put portals on their feet. That's really all they want to do. It's fun for a bit, but not as the receiving end, right? It's not fun-- or they just want to keep bumping each other's portals. Like when they want to put their portal at exactly where the other guy's portal is. Like they walk in and they go in there instead of where they were supposed to go. It's fun for a bit. I'm not saying there's no merit there. DAVE KIRCHER: By "a bit," I think he means about five minutes. TEJEEV KOHLI: Yeah, by "a bit," that's the thing you look at, you're like, ah, that's funny. But then you realize there's no real-- at least in the mechanics we tried, there wasn't much depth to it. It's not something you could flesh out for a game mode. It's more of something you could do as a level-- as a gimmick once. But then there's not much reason to do that. The cost of doing that is really high, so you have to figure out do you want to spend a bunch of dev effort in making this gimmick that's going to get really old and lots of people are going to get annoyed or frustrated? So you just don't do that. In the back there. AUDIENCE: You mentioned that you could cache some stuff-- things in the pipeline for some of the lighting plots-- earlier. I'm wondering if there were any other kind of hardware hacks that you do in order to keep the targets that you want for the portal behavior? DAVE KIRCHER: So the question references how there were some pipeline restraints on the pixel queries. And if there were any hacks that we had to do to meet performance, I believe yes. TEJEEV KOHLI: And any other stuff we did. DAVE KIRCHER: Once again, I'm going to have to say that I did most of this stuff 10 years ago. I can't think of anything off the top of my head. There wasn't a whole lot. TEJEEV KOHLI: We did stuff with the paint. I don't know if we did a bunch of hacks, but one of the big hacks on the paint that we did was the paint that you're seeing is not the paint that's doing the painting. So I mean that's, like, nobody can tell. That's pretty good. But especially on multiplayer, the paint that the client is seeing is not the paint that the server is seeing. Because we couldn't transmit all that data, so they're both generating their own data. But then the server is the only one doing the actual painting, so all the blobs that the client is hitting in the world do nothing and the server blobs do the painting and then tell the client paint over there, paint over there. So that's the kind of thing-- because the network bandwidth is pretty limited and there's a lot of paint flying through the world. So we couldn't just transmit all the paint all the time, so they all generate their own paint. Blobs that are through the world, and then the painting itself happened on the server and then that gets transmitted. But the paint flying through the air is different on everyone, but it's random enough that you can't really tell. AUDIENCE: Is Half-Life 3 going to have portals? TEJEEV KOHLI: I don't know. DAVE KIRCHER: No comment. [LAUGHTER] Probably not. In all seriousness, after the initial Portal came out, one of the other experiments was not only what does multiplayer look like, but how fun is this in a Half-Life environment? And it turns out that the way that Half-Life is made, there are a whole lot of slightly scripted sequences to make things work. And so the way those levels are designed are fundamentally different than Portal levels and they basically just break down. So if there were portals in Half-Life, then Half-Life would seem a lot more like Portal. TEJEEV KOHLI: If you think about a Portal level, it's pretty constrained. The sight lines are pretty constrained. The level takes place in a box. You can't see really far. There's a lot of kinks in the walls so you can't see all the way to the end. Half-Life levels aren't designed like that at all. So you would just go in a level and make portals all the way to the exit and then skip all the game play. I mean there are probably mods that allow you to do that, but I think the games themselves and the mechanics are fundamentally different enough that I don't think they interact really well. Unless both of them change or one of them changes a lot so it's no longer the game you wanted. I think you were up first. Yeah. AUDIENCE: You mentioned that you had done, like, a student game project before you got hired by Valve? What was the story there? TEJEEV KOHLI: So the question was asking about our student game projects. So Dave worked-- we both went to a school in Redmond called DigiPen. Dave went there before I did. DAVE KIRCHER: I graduated in 2005. I worked on a game called Narbacular Drop. Which if you Google for it, it will be the only result because the name was chosen so that would be the only result on Google. If you could spell it, good luck. And so that was our senior project at DigiPen-- my team at the time. And so we ended up through a very convoluted long story showing that at Valve, and they hired us on the spot to basically recreate those mechanics for them. And that was actually-- there wasn't a whole lot of confidence at the time that would actually ship, but it became Portal. So it seemed like a good thing. TEJEEV KOHLI: Yeah, and I was part of a team that made "Tag-- The Power of Paint," the video I showed with a paint gun, and that was our team's junior project at DigiPen. And same thing, Valve saw it a couple of times and hired the entire team to come work on that mechanic at Valve. And then once we got there, it became obvious to try to integrate it into Portal 2 and that's how we start working on Portal 2 and that's how the Portal 2 gels came about. AUDIENCE: The paints and gels which were introduced as a mechanic in Portal 2 ended up being part of the story as well. Can you talk about how some mechanics end up affecting the story and how story elements end up affecting the mechanics? TEJEEV KOHLI: The question was about how the story and the game mechanics interact and how one affects the other. So the way at least in Portal 2, and I think Portal 1 was very similar. The way it kind of works with Valve is we don't really have an overarching design for a design doc for the game before we start. It's a lot of smaller things that we try to combine using similar techniques like what we discussed today. And the story kind of builds us out of using the same techniques. Because the way we kind of vet out most of our design decisions is by play testing. And the story follows a very similar plot but you don't really want one-- either one to override the other. Because if you see the game, like if I make a bunch-- if we have a team that made a bunch of puzzles for the game that haven't been very play tested. And then the writer comes in and does a bunch of writing for it and then you realize three weeks later that half these levels aren't shipping anymore because they didn't test well, then you made a bunch of dependencies that didn't really work. Portal was lucky in that the puzzles themselves are compartmentalized as you enter the elevator. Or you exit the elevator, you do a puzzle, and enter the elevators. So they're all pretty compartmentalized. And a lot of the writing that was done for it was essentially just jokes. So a lot of those jokes do fit in to most of the puzzles. So the puzzle can change and the joke can just be inserted into it. But for the overarching story of the game, I think that required a lot more collaboration. So the writers were on-site. They were Valve employees and they were sitting in the same room as us watching us play test, bouncing back and forth ideas. And we used-- we had GLaDOS for most of the game. And the voice artist was local, so we had her come in many times and record a bunch of lines. We also used some like fake online robot voice for a while, but those are hard to judge because the play testers almost never laugh at those jokes. Because the robot always doesn't really know how to speak them. But it sounds like a robot so it's not it's better than nothing. It's better than just putting text on the screen, which we also did for a while. So with the writing, there's two things that you're trying to test, right? You're trying to test out the individual's jokes, and a lot of them can be transported to any level. So they're not super dependent on the levels. But then once the story starts coming together and starts taking shape, at that point you're making changes to the levels to accommodate the story. And from that point on, you have to have a pretty good amount of confidence that these particular levels are going to ship in the game. And so that that starts happening I think fairly late into our dev cycle at least. There's always an overarching goal. There's always a goal of you're trying to capture Wheatley or you're trying to go kill GLaDOS, but the exact mechanics of how that happens doesn't come together until fairly late. Because you don't want to spend a bunch of time integrating your story and your levels without having a bunch of confidence that these levels are actually good enough to ship. Which we do have for a bunch of the game, but as new levels and new mechanics are being introduced, it all kind of goes haywire. So it's just mostly a pretty strong collaborative process between the writers and the designers and it all goes back to the play testing. AUDIENCE: Can you talk a little bit about how the sound interacts with portals, like in 3-D positioning of the audio sources? DAVE KIRCHER: So the question was how sound interacts with Portal. And my memory's a little fuzzy. I'm pretty sure we tried to replicate a little bit using just a simple-- basically the exact same solution as with our lighting. Where it's like we have a sample point in front of a portal and we have an emitter on the other side. I can't remember if we shipped that way. TEJEEV KOHLI: I think we did. DAVE KIRCHER: Yeah. TEJEEV KOHLI: I think there's a microphone or in-game microphone and an in-game speaker on the portals on both sides. So if you're on this side of the portal, you'll hear what's happening on the other side. Pretty sure that's how we shipped. DAVE KIRCHER: Yeah, but I don't think we made any special concessions to make it seem like it was going through a tunnel or anything like that. We just wanted to make sure you could hear what was going on. TEJEEV KOHLI: Not through the portals specifically. I know there was a bunch of stuff we did for the tractor beam. Like when you head to the tractor beam, it kind of fuzzles everything else around you and muddles the sound a little bit. But going through the portals themselves, I don't think there's anything specific we did there. At least not that I can-- it's been a long time. DAVE KIRCHER: It's been a long time. AUDIENCE: What were examples of puzzle games that inspired you when you making your games? TEJEEV KOHLI: Uh, Portal. [LAUGHING] The question was, what puzzle games inspired us when we were making our game? DAVE KIRCHER: I can't think of a strong inspiration. I'm mostly a code guy, so I didn't do a whole lot of the actual puzzle design. But when I'm thinking back, we didn't have a whole lot of sources to draw on because it was a fairly new concept in general. I can't think of any sources I drew on. I mean-- TEJEEV KOHLI: I wasn't kidding when I said Portal. When we were making Tag, I think Portal had come out a year or two earlier before that and was really good and a big success. And we were trying to learn from how they were teaching the players different things. And that's one of the biggest things we took away in our student game was how do you teach players different mechanics? And I think Portal did a really good job of that. By teaching by doing instead of by showing. So like the players doing all the stuff and then figuring it out instead of someone showing a video or just telling the player, hey, here's what do you do next, and then go and doing that. So we tried to take that at heart, and as we were doing in our game introducing new paints and new mechanics, doing it the same way where we introduce them in a way that the usage is obvious enough that the player will try it out. And when they try it out and it works, they feel really good about it. Because they feel like they figured it out instead of us doing all the work and showing them what to do. So a lot of that kind of was a specific thing that we took from Portal and trying to do it in our game. AUDIENCE: How many people did it take to create these two games, Portal and Portal 2, across the different functional units-- development, writers, and the rest? TEJEEV KOHLI: So the question was about how many people it took to make Portal and Portal 2. Portal 1 was a pretty small team for the most part. DAVE KIRCHER: So Portal 2 started as the seven people that worked on-- TEJEEV KOHLI: Portal 1. DAVE KIRCHER: Yeah. Sorry, Portal 1 started with the seven people that worked on Narbacular Drop directly transplanted. And then we started working fairly early with two writers. And we were leveraging other people at Valve to answer questions and help us hit the ground running as far as how to use the engine. But it was mostly just those nine people working day to day. And then Portal 2 ballooned quite a bit. TEJEEV KOHLI: Portal 2 was a much bigger team. By the time I joined Valve in 2009, I think there was already a pretty big Portal 2 team. They already had a field the mechanics figured out. The game was pretty different from what you see now, but at that point it was already maybe 10, 12 people. And then like it slowly increased. Like we were four or five that got hired for our paint game. So we joined that team. And then I think by the end of it, there were probably close to 40, 50 people working on it. That was towards the very end because we had to ship on two consoles and PC and we had a whole co-op mechanic. And there was a whole co-op campaign be worked on separately as well as a single player one. So it was a pretty big team by the end of it. Much bigger than Portal 1. And the game itself I think is much bigger than Portal 1 as well. I think the single player campaign itself is probably more than twice as long. And the campaign-- the co-op one is probably also that big. DAVE KIRCHER: I remember in Portal 1 we would have to do frequent integration testing and I think I got my play time on Portal 1 down to like 45 minutes and Portal 2 is several hours. TEJEEV KOHLI: Yeah. So it's a much bigger game, so it took a lot more people. AUDIENCE: How does the game engine that you used compare to Unity? Is it more straight-up C programming from scratch, or is it a lot of the drag-and-drop stuff you see? TEJEEV KOHLI: So the question is how did our game engine compare to something like Unity. For both Portal and Portal 2, we used Source, which is our in-house game engine. And it's very different from how Unity works. So the way Unity works is mostly like a really big editor. Like what you're seeing in the editor is the game essentially. Like all the entities and stuff are loaded. Obviously more stuff gets loaded at one time. But what you're seeing is what you're getting. Whereas the way Source works is it's got a bunch of these discrete tools that make stuff. So there's a level editor, which is where you make your level. And then you import that into the game and you run the game separately. And what you're seeing in a level editor is not what you see in the game because a lot of the entities and stuff don't translate to the editor. A lot of the lighting and stuff has to be pre-baked. Unity has some pre-baked lighting as well. But in the way it worked in Source-- Source I think is a combination of a bunch of discrete tools for each different aspect of the game. So I get a separate particles editor, separate model editor, separate editor for VO and the face poser, and the separate level editor. And then there's a game engine that takes the compiled versions of all-- compiled outputs of all those things and then puts them in the game engine and combines them together. And then all the code is pretty much exclusively C++. I don't think there's really anything else. There might be a couple a handful of things that are not, but all the tools are C++. All the game engine all the runtime code is all C++. Source 2 is a little bit different, but still going forward on that front, I'm not trying to do what Unity's doing. Because Unity is more of your running scripts-- C# scripts-- and then you're just compiling them while the editor's going and the rapid iteration and stuff. Source doesn't really have that same model of working. But the advantage is that we control all of it and then the ceiling for what we can produce is theoretically quite a bit higher. So there's tradeoffs to it. And also we make all our tools and all our engine stuff in-house and we're the primary customer for our games. So we're not trying to do what you Unity is doing and trying to service to anyone out there who wants to make anything. And Unity has thousands of people working on their engine and we have quite a few orders of magnitude less. But I think we are aware of all the tradeoffs we're making. We're not trying not to do what they're doing. We're just seeing-- and we're learning from them, too, and Source 2 has taken a few cues from stuff like Utility and stuff like Unreal. Trying to be more user friendly even to our own customers, internal employees. But it's not like-- the way of working is very different between Source and Unity. I think we're good. All right, well, thanks again for having us. [APPLAUSE] COLTON OGDEN: Thank you all so much for coming. So there's some extra pizza outside, but that was Portal Problems. So thank you very much.