50 Game Camera Mistakes

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments

I refer to this talk to explain to people who don't play games what making one entails, and also when I'm trying to convey that it's an art form

Here's some guy who made a very artistic game called journey. Ever seen an artsy game? Well, there you go. (Usually they haven’t)

And here you can watch him talk for an hour just about the camera. This man spent days just thinking about his camera. You don't even notice it when you play.

πŸ‘οΈŽ︎ 65 πŸ‘€οΈŽ︎ u/PM_ME_WITTY_USERNAME πŸ“…οΈŽ︎ Oct 08 2021 πŸ—«︎ replies

This is probably one of my favorite game dev videos. It's specific, practical, and makes you re-think the way your game is designed. It also made me notice how many 3D games (like Lego Star Wars, Crash, etc) get away with mostly fixed perspective cameras, which probably saves 101 headaches and makes it easier to design levels.

πŸ‘οΈŽ︎ 8 πŸ‘€οΈŽ︎ u/DeanoAndJimbo πŸ“…οΈŽ︎ Oct 09 2021 πŸ—«︎ replies

Camera's can very easily coax you as the developer into playing with it too much, because they give immediate and simple feedback that makes the project we've been working on for years suddenly feel fresh and interesting.

You have to resist the urge to make dramatic and powerful changes to your game through the camera because you're burning out, the player wont notice these changes or even find them jarring.

πŸ‘οΈŽ︎ 3 πŸ‘€οΈŽ︎ u/IllTemperedTuna πŸ“…οΈŽ︎ Oct 09 2021 πŸ—«︎ replies

Can someone with experience with 3D explain number 3 a bit for me? I don't know what a camera uses quaternions would look like.

πŸ‘οΈŽ︎ 1 πŸ‘€οΈŽ︎ u/gojirra πŸ“…οΈŽ︎ Oct 09 2021 πŸ—«︎ replies
Captions
all right hello I'm a very happy to say that people are still filling in and there are so many people here who care about video game cameras because I haven't really found a community of game developers who specialize in game cameras it's true that there's at least one book on the subject real-time cameras by Mark hey Hutchinson but I feel like there's still a lot of room to delve deeper into this discipline I want to see more role models talking about how they solve problems with their camera designs but I actually I guess it kind of makes a little bit of sense that there's not a whole lot of attention being paid to cameras because the whole point of cameras is to focus attention on something other than themselves cameras are most noticeable when they fail as players we only talk about cameras in order to complain when they're distracting so I decided that in order to really talk about camera design I have to embrace failure so this talk is about all the things that go wrong when you're developing a game with a third-person camera design I'm John esky I'm a field engineer at backend company I was sort of a thrown into this camera design thing boxing and actually I just hired as a general designer but I became really passionate about improving the the camera in the game is my first time developing a game with a dynamic camera and I discovered it it's a massive challenge and I now know that this is probably the hardest style of camera to design for a video game we can certainly learn a lot from cinematography but game cameras I think have a lot of their own special rules there are they're pretty hard to begin with for any kind of game like it in movies camera operators can deliberately plan out your shot in detail but as game designers we don't have that luxury everything in the game including the camera has to react to what the player is doing and it has to adapt to the situation and in order for the the game camera to adapt to the situation we have to formalize the the rules of a good camera design and teach it to the computer software that so they can do that I'll be already half and I call this discipline gamut ography not the first person to use this word but I think it's a good one there's basically three gamut ography styles in video games the the one on the left is a fixed fixed angle third-person see these little diagrams are representing an avatar standing in the middle of a square room with a camera pointed at them and I want to let the left is fixed angle third-person meaning the camera never rotates the the one in the middle is dynamic angle third-person and the one on the right is first-person and there's a lot of differences between these but the main difference I think that kind of everything else revolves around is the distance between the camera and the avatar on the Left you've got you have a camera that's basically infinitely far away or at least far enough away that you pretty much have to tear down everything between the avatar and the cameras in order to be able to see through all that and see the avatar you're basically tearing down the fourth wall this is common in basically all two-dimensional games do this as well as honestly many three-dimensional games as an overhead perspective however basically the same effect like league of legends just tears down the upper fourth wall first-person games on the other hand just have a distance of zero the camera is literally inside the skull of the avatar this means you never have to worry about losing track of where the avatar is because you are the avatar and since there's no danger of losing sight of the avatar we can leave in the fourth wall that we've removed for the the first camera style and leaving in all of the parts of the environment allows the camera to spin around without losing sight or without like seeing a gaping hole where the camera used to be the middle one dynamic angle third person games are on this weird sliding scale between close and far camera distances with kind of all the downsides of both for journey we did want a game where players could look in any direction and explore on their own so we couldn't use the the fixed angle third-person but we also wanted the player to have a clear view of the avatars body so we couldn't use first-person and we needed something in between and that means we need a camera that physically fits inside the world alongside the avatar and that means we have to worry about all of these collision detection problems and keep this in general keeping the space between the camera and the avatar empty so that you can always see what you're doing and these can design constraints leave us with a whole lot of problems in fact there's definitely at least 50 problems which I have taken the liberty of enumerated for your convenience I encountered most of these problems working on journey and usually I got it wrong the first time it's only through iteration that these problems get fixed but ah many mistakes remain in shipped products often and some of these can even still happen in journey as the sign-out actually started with a list of a hundred problems and had to narrow them down to fit into the space with this talk so I'm gonna have to talk a little bit quickly so let's get started started number one using a damp yes okay good yes they both animate a good using a dynamic camera when another pouch would work dynamic third-person camera as are as I said are the hardest kind of accounting to design and really there's no shame in taking the easy way out if it lets you focus on other parts of the game to make them better dynamic cameras don't automatically make games better in fact they frequently make them worse for example the the early 3d Mario and Zelda games all had dynamic camera angles but the more recent ones like Super Mario 3d World and Legend of Zelda link between worlds these have reverted to fixed camera angles and these are highly respected sequels so yeah pay attention to the for example the background on the image on the left and how it swings around as the camera turns while the right video has a stable background because the camera angle is fixed so for student projects game jams and other games developed under tight constraints I highly recommend picking an easier camera style such as first-person or fixed angle next problem is designing levels and camera behaviors that don't match a level design and camera design are closely related disciplines and they need to cooperate to help players navigate if you know the camera angle ahead of time you can design the entire level around map and if you don't if you have a dynamic camera angle then you have to make sure that the levels gracefully flow from one point to the next with the camera easily showing you where you need to go meanwhile the the camera itself has to be good at navigating the kinds of environments that are in your game I like this video because I find it telling that the author chose to include the original side-scrolling game in the top left corner of the screen yeah you can see it so that the player can actually tell what's going on I think that's a clue that this is not a good camera for this game using global coordinates or quaternions to persist camera state obviously this is sort of a programmer oriented issue afraid so I want to get this one out of the way early but it is also sort of a design issue it's it's easy to assume that a third-person camera for games should behave like like maybe a human holding a camera who can pivot around in place but in in third person games like this the the focus of the tension is really the avatar not the camera if it's not a first person game so whenever the camera rotates it should always be pivoting around the avatar like like a moon orbiting around and that means you should be is not important to store the global XYZ coordinates of the camera because you can always just derive those as an offset from the avatar finding where it is on the the orbit and the other issue is the quaternion thing quaternions are often considered the correct way to represent orientations of things by programmers and they're very useful but that's not how players think players think in terms of Euler angles that means pitch and yaw they rotate sideways and they look up and down that's that's how players want to control with for example an analog stick or whatever it is they're using to control control the camera so use use the Euler angles to to represent the orientation of your camera or at least at some point in the code and can convert to Courtney's later and as for the position instead of storing global XYZ coordinates store like distance from the avatar and maybe like a vertical or lateral offset and if you want to frame the avatar somewhere other than the center of the screen using a camera distance that's likely to break line of sight this means well the the line of sight but this this like imaginary line between the camera and the avatar is very crucial kind the entire camera code is basically designed around keeping this line of sight clear not not all the camera code but quite a lot of it and here's an example of an important game Papo yo-yo but it this game nevertheless fails to preserve line of sight for example this pipe on the left yeah and if if the camera was closer to the Avatar by default it would be a lot harder for this sort of problem to occur to do allowing obstacles to break line of sight from the side this is the most common way that obstacles will break line of sight and the the simplest way to fix the problem is to just detect by casting away from the avatars of the camera detect when the avatar has been included and just push the camera immediately closer to the to the avatar but that bet is a cut that is a camera cut and if all you're doing is changing the position of the camera that violates the 30-degree rule in cinema the 30-degree rule means all camera cuts should change the angle by at least 30 degrees and failing to do that creates a jarring sense of motion so it's much more pleasant when an obstacle is threatening to break line of sight to preemptively turn out of the way so for example in this case the camera swings to the right to avoid the obstacle on the left and you can detect these obstacles early with Ray casts that I call whiskers you can see the the green arrows on the diagram and if any of those whiskers detect an obstacle you can use that to preemptively swing away and if necessary you can reuse results from previous frames to reduce processor load if that's a problem however we have our first conflict pushing away from an obstacle like that while the player is trying to swing towards it so in journey and in many games like this the the player has a control stick or something to control the camera and it is important to to always honor the players intent so if the player wants to turn the camera one way the camera must turn that direction otherwise the player will be very frustrated which means in we come across these situations where the the camera wants to swing away from the obstacle but the player is swinging it towards the obstacle and in that case the only solution as far as I know is to pull the camera closer but as long as we know ahead of time that the obstacle is on the side that we're trying to avoid and the player is swinging towards it we can gradually interpolate the camera closer towards the avatar so that by the time the obstacles in the way we're already squeezing by it by getting closer letting the player push the camera inside an obstacle we still want to prevent breaking line of sight of course so as I said move the camera closer to avoid the obstacle and we may need to use some actual sphere collision detection I'll get into that a little bit later to avoid to make sure that the camera doesn't accidentally find ourselves inside the obstacle that you're pushing the camera towards letting independent forces compete to push the camera the as we've seen we need to deal with this special case where obstacle avoidance says to do one thing and chemically rolls say to do another thing but this is hardly the only special case we have to deal with the camera has to satisfy many constraints at a time and if constraints are allowed to compete with each other by applying forces in opposite directions they'll often cancel without satisfying either constraint but we can we can organize the constraints a little bit better because we know that there are seven axes or degrees of freedom that matter to the camera there's a pitch and roll and the horizontal vertical and like forward backward offsets and field of view those are the seven degrees of freedom and we can organize all the constraints according to which degree of freedom they matter to this is a separation of concerns basically it which is a programming principle and for the the problem that I described earlier with a swinging put toward and away from the obstacle those are both apply to the yaw axis so you can get all the forces that apply the y-axis and prioritize them and in this case we know that the player control it has the priority number nine is keeping narrow columns from braking line of sight it is important as I've said to avoid braking line of sight however there are cases where here you can see that this this column breaks line of sight with the the avatar on the right and it would be more trouble than it's worth for the camera to try to avoid letting that happen it actually looks pretty graceful in this case to just swing around the obstacle or on the outside and you can accomplish this or that journey we accomplish this by tagging obstacles based on whether or not they're allowed to break line of sight and this one this particular obstacle is very narrow the the player should be able to track the avatar with their eyes even though the avatars temporarily eclipsed ten is letting the camera intersect narrow columns so I just explained that it's okay to let this narrow column break line of sight however that's not okay to let the obstacle actually collide into the camera self that would be confusing to the player so this is where a more ordinary collision detection algorithms like a sphere collision check is helpful you can check if the the camera itself is touching the column and if so just push it out until it's not touching anymore interpreting a hill as a wall to be avoided journey is full of sand dunes with the smooth slopes and like any other obstacle it is important to keep line of sight from colliding with the sand dunes however we don't necessarily want to swing sideways away from the hills it actually makes much more sense to rise the camera above the hill so in the case of journey actually just skip a collision detection with whiskers and sand dunes but you can also try checking the the surface normal of the the slope to see if it's the kind of obstacle that you should be swinging away from or rising above swinging sideways when a clue is come from behind so far all of the obstacle avoidance has been these the the sideways whisker swinging around but line of sight can be broken from many directions there's the sides and then there's also behind for example if the the avatar if the players making the avatar run towards the camera and the camera is backing up it can be backed up into a corner and if the camera finds itself backed into a corner then swinging either direction won't actually get it out it won't help at all so in this case you should use a ray cast like immediately behind the camera to Detective its being back into a corner so just pull closer without swinging sideways 13 is letting the cameras near clipping plane intersect the avatar this is a technical problem that prints all virtual cameras have what's called a near clipping plane and anything closer to that gets cut off and leaves a big gaping hole in the object so we want to make sure that this almost never happens or never happens preferably so there needs to be enough space between the avatar and any adjacent walls for the camera to fit it's near clipping plane through the space and what we can do that is by making sure that the the avatars collision radius is wider than the actual avatar so that they'll never actually like press up right up against the wall so you can just like still fit the camera between the model and the wall 14 is using the same camera distance for all angles in particular I'm talking about up and down tilting if you're if you're looking up that means the camera has to swing downwards to keep the avatar in view while you're looking at the sky but if your camera or swinging downwards it's going to crash into the ground unless you make it closer so some games will make the camera crashing to the ground and then pull closer but I prefer to have a smooth curve that kind of knows in advance what the shape of the floor is and it can kind of glide into the position at the the avatars feet for a worm's-eye view it's also good to extend this curve the other direction so when you're looking downwards and you swing the camera up this looking downwards means the horizon is the long no longer in the view and if you can just see this little patch of ground around the avatar and it can feel a little bit claustrophobic so I recommend pulling the camera out a little bit when you're looking downwards so you can have a little bit more to see around the avatar so you don't feel it closed in 15 using the same field of view for worm's-eye and standard angles the the sky is really really big it's nice to be able to take in more of the sky at once and in reality as humans we use our peripheral vision to to see the most or all of the sky we can see almost 180 degrees is to our sides so in order to create the same feeling when the game is looking at the sky it should expand its field of view as its transitioning to a bird's-eye view you can kind of see being at the sides of the canyon filling in the sides of the the beetle up here and that that just makes you feel more like you are the character looking the way the character would look let's see 16 is shifting pitch distance and feel the view independently so as I explained as the camera is pitching up and down the the distance needs to change and the field that they also needs to change but if these if these degrees of freedom are not completely linked together then you can create this weird effect where like as you look up or down the the field of view will change and that will affect the size of everything on the screen because field of view is zoom but then the distance will also change it will change in the opposite direction so you might end up with the Avatar appearing to expand in and shrink or shrink and then expand so it's best to make sure that the the the distance and the field of view are both like derived from the pitch so that they transition together like gears however you do end up with situations where other other factors want to affect the distance the field of view so in that case you can kind of have like a base distance of field of view there drive from pitch and then other modifiers can like be multipliers or offsets to be the base field of view 17 not cutting when the avatar passes through opaque areas this is the case where the line of sight is being threatened from the front which is actually super rare because the avatar itself has collision and will prevent obstacles from hitting the front of the line of sight but there are cases for exam the sand fallen journey where an opaque surface it can still be passed through and in that case the only thing you can really do to bring back line of sight is to cut 18 is letting cuts remap directional controls up on the on the analog stick ring means go forward but but but forward is determined by whatever direction the camera is looking in and when the camera suddenly rotates to a different direction forward changes and then up on the control stick changes and players they physically can't teleport their thumb when the camera cuts they need a moment to adapt to the new direction so this is a good opportunity for either like a cutscene or some kind of transition effect or or just put the player in a situation where they're not in danger of being attacked or anything like that when when the cut happens because players do need a moment to adapt I'll totally alternatively you could also try to interpolate the forward direction during the cut I don't know how well that works but some people do it I've seen it happen 19 is breaking the players sense of direction remapping controls is a temporary problem because the Fed can quickly adapt to whatever the forward direction is on the camera but cuts that change the camera angle also create a longer-term loss of the players sense of direction I think players use primarily two different techniques for navigating dead reckoning which is keeping track of all the changes in your position in orientation so like if I rotate my body 180 degrees I know that North was is now south or but a camera cut sorry the the second technique is recognizing landmarks so Dedrick can in recognizing landmarks and camera cuts they they make dead reckoning impossible you can't tell all the time when a camera cuts how much it has been rotated so I don't know how much to rotate your mental model of the map so this is a crucial moment to make sure that the the camera is showing the player easy either recognizable landmarks or something to help them understand where they are when the camera is cutting so that they they don't lose their sense of direction too badly 20 is violating the 180 degree rule this is a commonly known rule in cinematography 180 degree rule means don't cut the camera such that two subjects like characters talking to each other swap sides that means like don't rotate the camera behind them that kind of thing but fortunately we don't actually have to worry about that 180 degree rule very often in games because as I've explained cuts are dangerous and we should avoid using them whenever possible however there are situations where 180 Google does apply especially during cutscenes so like at the end of the cut scene you should be showing me the player what they they need to be seeing to be able to navigate yeah 21 is focusing only on the avatar so far I've only been talking about the avatar but yeah the player also needs to see other stuff in the environment in order to navigate for example the player needs to be able to see the terrain immediately around the the avatars feet to see within out they're going to bump into a wall or where they're going to fall off a cliff and they also need to track a keep track of things that are far away like the mountain on the horizon and journey or the partner they're traveling with so number 22 is relying on players to be controlling the camera at all times for from any players controlling an avatar and the camera at the same time is a lot like patting your head and rubbing your belly you can see a this is Beyond Good and Evil and this player is probably pretty good at this game but they still end up like jerking the camera around because this game doesn't have any automatic guidance for the camera so I recommend whenever possible the camera should be doing its best to look where the player wants to see in advance so that the player doesn't have to be controlling it 23 is leaving the camera yah alone while the player is running and the simplest way to help the players see where they're going is to show them where they're already going just take the direction that the players running in and map that to the the the yaw of the camera so kind of like drift behind me the avatar as they're running however even this rule has a little bit of nuance for example if the player is running right into a wall it doesn't do them any good to like show them a direct view of the wall because there's nothing beyond it so use use the players velocity to figure out where they're going rather than the direction of pressing on the analog stick because they may be pressing in like or we even worse they may be running into an invisible wall and you don't want to taunt the player by showing them beyond invisible you all you want to swing the camera around the other direction to show them where they should be going 24 is making it hard to judge distances I love this game a lot but this is a situation where the challenge is created entirely by the camera kind of refusing to align with the direction you're going in the problem is that the screen is 2-dimensional and even if you've got some kind of three-dimensional screen depth perception is pretty weak players are much better at judging distances that align with the plane of the screen and there's that so for example if you have a top view you're good at judging all horizontal motion where's if you have a side view you're good at judging vertical motion and also horizontal motion on one axis and in this case for this catwalk the most important thing for the players to know how far they are from either side of the catwalk with that which means that the cameras really should be like pointing right down the catwalk so you can see so you can like align that axis with the side way sideways access of the screen excuse me and 25 is looking straight ahead as the Avatar approaches a cliff when when player when people walk towards a ledge they will look down to see what's below and the counter should be the same thing you can cast more Ray's kind of kind of a downwards ray in front of the avatar to see if there's any drop in front of the avatar and if you detect a drop the camera can rotate its pitch to swing into a bird's eye view and an additional benefit of this in addition to just showing you what's down there the camera is ready to get out of the way if the player falls off the cliff otherwise if the player if the camera is level when you fall off a cliff and the avatar Falls then the camera wants to fall with it and will crash into the clip itself but if it's looking from a bird's eye view can just like slip over the edge 26 is keeping the camera level when the avatar is running up or down a slope the same kind of technique of for Clips applies the slopes detect like what the the height of the ground is in front of you and if it's above or below you can look up and down however some people might try to just use like the shape of the Train directly under the players feet but if it's bumpy terrain that might give you noisy information so you should be really doing some kind of rate cast ahead with the player to figure out the like the average slope of the terrain 27 is misusing rule of thirds rule of thirds is another well-known rule of from cinematography and basically says that pictures are more attractive when the subjects are off-center usually facing inwards this is a simple way to improve the perceived quality of your camera design but the the wrong way to implement it is to to rotate the camera in place like if you if you're trying to implement rule of thirds by holding a physical camera in your hands you'll probably just rotate your hands a little bit and you're pivoting in place but again a game camera should never pivot in place it should be rotating around the avatar when it's doing the rotations so instead in order to create an off-center avatar you can just slide the camera sideways the there's a problem here however which is that players use the center of the screen to aim their analog stick if you have the player on the off-center while they're running they'll get confused about what direction they're running in so in journey we only use will of thirds when the player is standing still when they have to be running or when the players analog stick we make the avatar drifts back to the center and I'm trying to clip some shadow of the classes here because it's actually an interesting counter example in this game I think it's okay that the horse is off-center as you're riding it because in this game you're not using the analog stick to to aim actually you're pressing like the gas pedal to go forwards and then you just use the analog stick to press left and right to steer so in this case the I think it's okay that the player doesn't need to associate up on the analog stick with the center of the screen because you don't use the analog stick to go forward 28 is using the same logic for ground and air motion I've mostly been talking about ground motions so far but depending on the kind of game you have there may be different kinds of locomotion in the game and journey you have running and flying shadowed for the classes has as we said the the horse and these different transportation modes take different paths and trajectories through space and the player needs to be able to make different kinds of judgments and in the case of flying in journey what goes up always must come down and it's important to always show the player where they're going to land so especially when you're running out of juice in Journey have like a special amount of or limited amount of flying juice it's like at the very beginning you might be flying upwards and the camera will look up to show you where you're going but as you're running out of juice it's important to tilt the camera downwards so that you're prepared to land at any time to see where you're going to land 29 is relying entirely on procedural camera behaviors pretty much all the camera behaviors I've described so far are just automatic things that it does to respond to the environment and to the player but raycasting is is only going to tell you the shape of the train it doesn't tell you what's important we as game designers need to decide this this this other character in the game is important or this this mountain is important and the player needs to see these things so in in our in our maps or levels we we add scripted hints to tell the camera in this context sensitive sensitive situation the camera should be pointing at this particular target I think camera hints become even more important in small closed environments because dynamic cameras are pretty good at open environments within weather there's not very many circles but in small closed environments there's a lot of stuff for the camera to watch out for and the more we can help it out the better and here I have an example from journey of a large tower it's a very it's mostly complex re convex shape which means there's like a pretty well-defined center of the tower and as long as the camera is on the other side of the avatar from the center of the tower then you can have a pretty clear view of what's going on here so this is a scripted hint in the game that's that's not a general-purpose behavior 30 is letting players make themselves lost and confused players do love to explore and we want to enable them to do so but we also want to make sure they don't get too lost and the simplest solution employed by many games is to put an error arrow or radar on the screen I feel that these are a bit heavy-handed we did not use them in journey I prefer relying on subtle camera tricks to suggest the direction to to go for example as I as I said when you're running up against a the boundary of the world and journey the camera will spin around to show the opposite direction to point you back towards the center or where you're supposed to go another thing you might try doing is detecting whether or not the player has backtracked a significant distance and if they have then spin the camera around to point them forwards again 31 is rotating to look at nearby targets when you have a scripted hint that's telling the counter to look at for example another character or avatar we're standing right next to you maybe your first approach would be to make a camera rotate to point at it but if you keep doing that on the left you see Batman Arkham Asylum and the camera just keeps spinning around because these these two things they're in close proximity to keep can basically dancing around each other and it's hard to keep up with that kind of rotation um but fortunately there's an alternative approach here which is to just pull the camera either to the side or back to include more more in its view in this journey for example what happens is the camera pulls out right about now to show both avatars without doing any rotation and that that just is less disorienting and more graceful 32 is translating to look at distant targets this is the opposite situation if you have a nearby thing I should slide the camera sideways or backwards to include it but if you have a distant thing like something on the horizon of the screen or like the Sun for example no amount of sliding the camera around would change the position of the Sun on the screen so the correct width thing to do in that case is to rotate 33 is letting the avatars own body occlude targets ahead if you're rotating the camera to point at something and the avatars in the center of the screen there's a danger the avatar itself will actually eclipse what you're looking at you can point either to the side or you can this would be a good opportunity for rule of thirds to slide to the science of the avatars on the side of the screen but any case you should just be be aware of this situation often the the easiest thing to do is to just make sure that the camera is tilted down slightly so you can see over the top of the app Tarzan 34 is giving the player control over the camera and then taking it away it's very frustrating to give players control only to take a big way again later so when you're making these scripted camera hints you should be aware of that or at least enable the player to override the hints whenever possible and if if you have to make a hint that will override player control make sure it's in a situation where the camera is already looking at everything that the player needs to see so that they won't feel the need to control it 35 is immediately applying a hint to a scripted hint to control the camera after the player has finished turning the camera to look at something if the player is deliberately controlling the camera they probably want to be looking wherever they pointed the camera and if you have a like a scripted hint that's always on and always trying to push the cam in a certain direction as soon as you stop overriding it it'll start it'll kick in and again and turn the camera so the there should be like a little delay after controlling the camera where the camera will continue to look where the players wanted wants it to be pointed and either after delay or after maybe the player started moving again then you can let the the can't kick in again 36 is not letting experts explore even if the the player is technically still in control of the camera and constantly controlling it it can be frustrating when overbearing hints are constantly trying to get them to go in a different direction especially when experts are replaying in game they're likely to want to go to new places so after the hints have helped the players establish their goals the hint can be disengaged to allow the player to vote to find their own drag their own way to get there 37 is not providing inverted controls this is a big problem I think pretty much everyone in the game industry kind of knows about this problem especially first-person shooter developers but a significant fraction of the game playing population wants up to be down and the other half or large fraction wants down to be down and up to be up and they probably will either refuse to play your game or just complain a whole lot about the game if they can't set the the controls to be the way they want so make sure you have an option somewhere in the game to invert the axes this is actually the only option we have in journey four controls 38 is responding to accidental controller input in journey we made the decision to support two different inputs for controlling the camera there's the the analog stick and there's also the actual like a gyroscope or orientation of the the ps2 controller and this is partly left over from flour where you control the game with the tilting the controller honestly I think it makes it made a lot more sense in flour because it's the only thing you do in the game where's in journey it's more of a a a pattern your head and rub your belly type of a problem and we end up in journey with people often a tilting the controller accidentally and accidentally making the camera swing around there are reasons why we we supported the the tilt I think it is an intuitive control for especially new players but I I think at the very least we probably should have had an option to disable it 39 is using linear sensitivity especially on the analog stick analog sticks don't have much range often it doesn't matter much honestly because players have a tendency to push the stick all of the way you kind of saw this from the Beyond Good and Evil clip where the player kept twitching the camera but I think it would have been nicer to provide sort of an intermediate or a very slow way a way to control the camera very slowly for fine-tuning the camera direction you can do that by stretching the the input axis from the the analog stick into a sort of NS S curve that reduces the the neutral positions for T is letting the camera pivot drift too far so this means well in order to smooth out motion for example if you have an avatar there's jerkily dashing back and forth it's nice to smooth it out by letting the the avatar drift from the center of the screen but if you do that too much if you let the camera be too lazy then the avatar might actually run outside the screen and that's a problem so if you're using an elastic band type thing to make the camera attracted to the avatar make sure it has a limit to to how far the avatar can get from the center of the screen and you might actually want the camera to look ahead of the avatar for example in your shoes island if if the player is running in a certain direction up a little while the camera will adjust by looking ahead of the ocean however problem 41 using a small field of view another when the camera zooms in on a tiny little thing then tiny little motions become large motions and zooming in exaggerate the speed of everything and zooming out makes everything appear to move much slower and here's a game that is a I think nostalgic for a lot of people I enjoyed the game quite a lot but when I tried this is an example of a game where when I try to show it to some of my friends they are not able to play the game because the camera just moves too rapidly this is this is something I care about a lot this is called simulation sickness it's when people play games and just from playing the game and watching the screen they feel sick and I wish that Yoshi's Island for example or many other games would would zoom out a bit more so you have a bit more space to look around and the camera won't have to to move as quickly to keep up with the action on the screen and on the subject of zooming out this is also applicable to first-person shooter games I don't have a clip but you could easily put a first person shooter clip on the screen this first button shooters are actually probably the most common trigger for simulation sickness and the way that people usually recommend that players deal with it is by going into the configuration for the game they're playing and expanding the default field of view and as I explained this has the effect of making everything appear to move slower and I think this is a good way to deal with a situation if you're making a first-person shooter especially for console where you don't always have as much configuration options include a way to expand the field of view or just have expanded by default so that you don't exclude players who would otherwise be made sick by your game 42 is rapidly shifting field of view this is actually increasing the problem in first-person shooters when when aiming with a sniper rifle or other type of weapon with a scope the camera often zooms in rapidly and also racing games do this when you're boosting the camera will zoom out to make it feel like you're going faster and these kinds of things are also triggers for simulation sickness so be aware 43 is shaking the camera screen shake is an effect that is commonly used and all excuse me all kinds of video games it's popular because it emphasizes impacts it happens in the game game world and in alongside vibration this is used to make the game feel more real some people say the screen shake is the easiest way to make a game feel more polished so it's clearly a very useful tool for game developers but I want you to be aware that not all players experience shaking in the same way the right amount of shake for you might be too much shake for someone else so again I urge you to have accessibility settings for are tuning down effects like screen shake I have a clip from tower fall here and I'm told the tower fall actually does include a setting to turn off the camera effects so I'm cluding it here as a good example 44 bouncing the camera with the avatars walk cycle this is another common one especially in over the head games or over the shoulder games this again is to make the camera feel more real but feeling real - you might not feel real - someone else might feel nauseous to someone else nauseating rather the the goal is to sit the same as a screen check again to make it feel more real and the effect is similar camera bobbing is just a longer slower shake and equally likely to trigger simulation sickness so you should be able to disable that as well I have seen plenty of games with an option to disable this this is a common one do it please translating or sliding up and down or rotating up and down when the avatar is jumping a lot of games both third-person and side scrollers are have the camera kind of locked onto the avatar one mid-jump and that means like at the moment when they jump in when they land the camera has this abrupt start and stop and that can be triggering as well so this is another situation where we know what goes up must come down and we know that the camera the avatar is probably not in danger of going off the top of the screen so we can just let the the camera stay in place as long as they're just jumping up and down in place and often what happens like in mario games what happens is the camera waits until the player has landed on a higher surface before moving upwards in journey we sort of a a rubber band - just move without the the rapid vertical motions that happen on the screen 46 is rapidly transitioning to a new camera position this this happens often in games I think I think actually some game developers take the rule of not cutting a bit too far in games Zelda games are the 3d Zelda games are especially bad at this I think these camera train transitions might as well be camera cuts but because there's smooth transitions but they're really fast smooth transitions they create a sense of motion that won't be bare with a cut 47 is maintaining pitch speed until hitting the limit one of the downsides of using Euler angles is that there's gimbal lock and in other problems if you look straight up and down so you pretty much never want to have the allow the player to look straight up and down you have one have like some limit of how how high and down there can look but I've seen a lot of games will will make it so that if you're pressing like up on the the camera control stick it will rapidly move the camera upwards up until hitting the limit and they'll come to an abrupt stop and it's much better to to anticipate hitting the top-end - to slow down as you approach the limit 48 this is probably a controversial thing to put as a mistake but what I mean by this is a that as games get more and more lifelike and they're getting better and better at simulating motion they're also getting better and better at triggering simulation signals because simulation sickness is what happens when there's a mismatch between what you see the motion that you see in the motion that you feel and I know that the oculus rift developers are doing their best to improve it and I'm sure they are improving it but for the purposes of maximizing your audience and not excluding anybody I urge everyone to to not make games exclusively for the oculus rift make sure there's always some other way to play the game because some people I think will probably never be able to play an oculus rift or at least not in the next few years 49 testing with a narrow demographic children especially are eager to point out flaws and and other people who who don't have a personal relationship with you will be eager to criticize you but you you may need to pry a bit with testers because I know from experience that some people who have simulation sickness don't want to admit it it feels like a weakness and you want to make sure that they feel comfortable telling you when there's a problem with your game because I'm sure that none of you want your customers to feel sick and 50 writing and general constraint solver given the complexity of all of these constraints that I've been describing it's probably tempting to just come up with a function that like evaluates how effectively each of these constraints has been satisfied and to just try to optimize and pick the one angle that satisfies them all the best now and let the computer kind of figure that which one that is which angle that is but I believe this is actually almost never the right approach because when you let the computer do all the work it can be very difficult to predict what the results are going to be and if you can't predict it and you can't really design it you have to be able to iterate on the design with changes that affect affect the behavior in some unpredictable ways so I think it's important to deeply understand the relationship between the different camera constraints so that you're able to prioritize or otherwise figure out how to satisfy all the constraints or as best as possible see so the devil is in the details this solutions that work for journey might not work for you so this lift list can serve as criteria to help you evaluate how well your solutions work but it's not a replacement for doing your own research so many of you will have to do some of the same kind of research and development that we have to do on journey so good luck and first of all I think I have two minutes for questions one to two minutes for questions I anyone have any hi so you mentioned a few options that you think everybody should have you Bob field of view camera shake do you think it's worthwhile to combine all those into a single option for people where simulation sickness um that may be a good idea although I think there's there's some differences in how people experience simulation sicknesses so some things that are triggering to some person some people might not be tricking to someone else did you find that a lot of people with simulation sickness were very familiar with what precisely it was that caused their simulation sickness that is actually a good question that is not always the case but if these options can be surfaced you can let people know about them so that they'll know what to look for to figure it out okay thanks so I know a bunch of us are probably gonna go run and try to fix our third-person cameras and while you mentioned that like there's not a one-size-fits-all there's definitely also some principles it may be extrapolate yeah not to put you on the spot any chance you're going to like make a unity plugin or something that's like a starting point that already acknowledges some of the major stuff so we can start from there instead of like having to recreate some of these foundations I'm deeply concerning it it's a matter of having time thank you now I'm you good I think I'm a person so I'm modifying field of view in order to help with simulation sickness yeah however in competitive first person shooters field of view can also be important to the players ability to react to things on the edge of their vision so it's actually the balanced concern now if you have any thoughts or experience with how to strike a reasonable balance between those two constraints well I remember reading about in quake people a deliberately expanding field of view for an advantage so it sounds like expanded field of view is an advantage for everyone just do it alright you can contact me on Twitter and I can probably find my way over to the to the wrap up room somehow and thank you
Info
Channel: GDC
Views: 448,543
Rating: undefined out of 5
Keywords: gdc, talk, panel, game, games, gaming, development, hd, design
Id: C7307qRmlMI
Channel Id: undefined
Length: 60min 53sec (3653 seconds)
Published: Tue Nov 17 2015
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.