Placeholder Image

字幕列表 影片播放

  • [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.

[MUSIC PLAYING]

字幕與單字

單字即點即查 點擊單字可以查詢單字解釋

B1 中級

門戶問題--第11講--CS50的遊戲開發介紹 (Portal Problems - Lecture 11 - CS50's Introduction to Game Development)

  • 5 0
    林宜悉 發佈於 2021 年 01 月 14 日
影片單字