This is what happens when you try to be an "Absolute right" or "This is all sound and sane advice" guide to something. While the advice they give is "useful" they are blind to the half the audience that notices when it is good. To an entire set of opinions... They are blind to the situations where the advice... ruins games.

@@Buglin_Burger7878 at the start, he said they're "most noticeable" when they fail, which is vastly more correct.

@@Buglin_Burger7878 do you even know what you are talking about lol

You aren't the usual gamer though, you obviously have an interest in game design since you're watching an hour long GDC presentation on cameras. Of course you're going to appreciate the subtle details of a game since you have an eye for it. I am the same way but most people are not this way.

@@getgle Depends on the game, not the gamer. Most games have cameras because they are required to show the player the world, and that's all there is to it. They just need the camera to work and not be intrusive. Other games use the camera as a part of the experience. Things like the dolly zoom in Max Payne, or the Drunk Cam in GTA. I don't care who you are - if you play those games, you will notice those things, because that's the point.

imbw267 ur doing Lord‘s work

You're a hero, my friend

not all hero wear capes.... some of them have i set as avatar

Thanks man

Accidentally disliked this, sorry! Fixed it right away.

I'm curious, as a student of psychology why do you think you are watching this?

@@ironbard4901 Because, as it turns out, I'm also a big (big) sucker for videogames and I love to learn everything about them.

Jack of all trades, master of none, often times better than a master of one. The wider your knowledge base, the more you can leverage. 20 min to absorb what took someone years of study and effort to learn? Worth it

@@enzocap43 maybe this is a subconscious thing, but a camera's design has a lot to do with how a player perceives a game, giving it a psychological spin, too

Game design is largely psychological so it's not a far leap.

Developers developers developers developers...

@@AnubitekOfficial He needs a good pop filter. :/

Dude it blows my mind

Through the roof? Like a badly designed camera?

Love it.

Really surprised to read this. For me, I have quite opposite, I want to look directly at the surface I'm running, because it is not smooth in general, so I hate when the camera behaves 'or look you need to see what's forward on you'. That was particulary annoying in Cyberpunk when I want to camera look upside down to the ground when driving. But, after all we speaking about same thing - 'don't touch my camera!'

I was hoping someone would mention this. It gives me a headache when the game keeps slapping me in the face for daring to try and have control over where I'm looking. Why on earth can the player not be trusted look where he wants while moving?

Its especially annoying when you’re trying to take a pretty picture, and you’re fighting with the camera to get the desired angle

Should of followed rule 35

genshin impact also does this, not only for rotation but also pitch. one of the worst game cameras I've experienced. at least you can turn this off for pitch. another problem is also the inconsistency, because it's different depending on the movement type

Discipline!

I agree. I'm here because in my prototype you have full control of the camera, however, it's a 3rd person real time strategy game and I feel like messing with the camera while I'm trying to command units is annoying and taking away from the experience. It was originally going to be a side scroller (think beat 'em up style with horizontal and vertical movement) with a fixed camera but I wanted exploration in the game so I decided to make it full 3D.

I was looking at the example with BG&E and thinking "oh my, how much better felt that than any camera trying to do things I never asked it to do". It sounds like a nice idea to predict where the player would want the camera to be, but the reverse side of this idea is that it forces the player to constantly predict what the camera is predicting about him. And it bothers me as a player much, MUCH more than some jerkiness that I generate by myself. It is like with driving a car and being a passenger - this kind jerks look bad from aside, but when its only you who controls them, your mind and perception are ready to them and you easily ignore it. Much easier task for the brain than to predict camera predictions.

if you need to take control away from the player in terms of camera..you are failing as a designer. great Designer naturally used the world it self to draw the player eyes.

@@TheMrTape brah, was this towards me or what? cause wtf did i say to get attack lol

@@BrotherO4 Most likely because you are gatekeeping. "If you don't do x then you are not y" en.wikipedia.org/wiki/Gatekeeping_(communication)

"wallhack view" and hiding objects that break los are indeed options too.

You see this a lot in "2.5D" games and I think it works well; however I'd prefer making the object semi-transparent instead of the character 'shining through' - gives a better visual representation of where the character is on the floor behind the object.

@@JapyDooge a lot of ARPG do that, dithering/making stuff in front of the character transparent.

It depends on what sort of visual feel you want to give your game. It's still pretty important.

Depends on how important it is to see other things in the environment your character is interacting with, including navigating around.

On console it's more or less only for optimisation. The lower the FoV the less stuff that needs to be rendered. As far as distance to the screen goes, there's a golden rule that is assumed. The distance from 2 opposite corners of the screen is the distance you should sit at for the optimal viewing experience. So if your screen is 24" then you should sit at around 24" away from your screen. If people choose to sit closer or further away, that's their own decision. But as a general rule of thumb, screen size = viewing distance.

+Theo Laanstra That could be part of the problem : Designers, by their nature, want to Design a "Solution" - it's their process...When, like you say, the player would (most likely, most of the time) be best served with "Options" - to customise/tailor their *own* experience.

@@zetetick395 Hahahaha! That's hilarious. Now let's talk about how people *actually* work. People will play your game, get sick, then quit and get their refund without ever taking a look at the options. Even if you have some glaring popup which points out the options, they will either: #1. Forget, #2. Mash "A" past it without reading it, #3. Hop onto your Twitter and call you a lazy fucking asshole for making them "design your game for you". THAT is why we want a solution.

@@21coute Yeah, I plan for my game to hopefully reduce this issue by having a "First time boot up routine", where it puts the camera in these different scenarios known to potentially cause Simulation Sickness, and give you the option to turn the effect off, down, or up It'd be skippable, and the settings could be changed manually at any time. It's not perfect, but I feel it's as close as you can get to solving that issue

Kinda annoying he has to point to Journey so much when speaking on how to do it right...

Yup. Vocalized pauses are so easy to get rid of once someone points them out. Beforehand, you don't even notice you're doing it! I pretty much never say "um" anymore, but I do still have a "like" problem!

I wish I didn't read this comment. I might not have noticed it so much.

You mean like when you're like, "she was like"?

imo "like" is a lot more annoying to hear than "um"

I now hate you, I didn't notice at all until I read the comment but now, its excruciating! It's like after every uuurm..three uuurm words. uuurm! -_- :P

Never touch a player's camera angle means you can't show stuff like an object collapsing for example, lets say you walk into a room and the point of interest that is about to collapse does everything right to draw attention to it... this means a savvy player explores the room and looks away from it for secrets and rewards. They look back in the center of the room after a noise... and don't notice the object collapsed. You'd grab and turn someone's head to show them the tsunami is coming.

You're first suggestion is a major reason for my hatred of the Tomb Raider reboot. I hate trying to look at something only for the camera to be pulled away from me. Never bothered me on a controller (on my PS2), but on KB+M? It's rage inducing.

@@Buglin_Burger7878 I think it was addressed towards times, when player does not need to see something important but camera keeps rotating towards movement direction or something

@@prycenewberg3976 A hypothetical force feedback mouse might improve this. If you’re using a stick and something tugs on your camera a little, you can easily balance that tug. If you’re using a mouse instead, it feels as if your view is slipping. If you try to counter it, you quickly run out of space and have to pick it up. That’s the worst. If your mouse had force feedback and the camera acted through that instead, the link between mouse and camera movement would be preserved. You’d feel it and you could hold it in place if you wanted. That’s assuming I can’t just sort myself out without such frills.

@@Buglin_Burger7878 Hell no. If your player's attention is diverted away from your big blockbuster moment, your level design is wrong, NOT your camera. I cannot overstate how much I hate games that take control of my camera to show me something "cool".

5 years later, hello from the future lol, yes absolutely agree. Lately I've been revisiting games from my childhood, one being 3D platformer Croc on PS1, and 99% of the issues with that game are directly camera related, as is the same for heaps of other early 3d games, namely platformers.

I know. It's part of the controls and moving the player with the camera is as important as moving the playing in general. I love it in Rayman 3 as you know how and when it will turn and move when you walk in a specific direction

That's a preference, these aren't catch all. In general I think these are good. They're not the best option for everyone, but it prevents bad camera and that's the point of this presentation.

@@fishbonesinc Religion which tells stories about being kind to others and sends you to hell if you're cruel to others... has holy crusades, hate to non-believers, murder. History has shown this countless times. Believing it prevents bad when it has good intentions just creates infinitely more bad and blindness.

@@Buglin_Burger7878 bro you good?

@@Buglin_Burger7878 What the fuck made you say this?

Morten Brodersen journey may have been a very simple game, but it's camera work was complex and excellent.

No actually, it's a terrible video. He's just describing ways to work around bad rendering. In truth, the camera is not physical, and is free to move through and see through objects. I admit that making the renderer work this way is not easy, but this is the *right* way to handle a camera This talk is merely the *cheap* way to do it. Edit: #15 and on return to reasonableness, but not because any of those things are *mistakes* per se, but because his solutions are cinematic and beautiful. I'm guessing he wanted his camera to be cinematic, and that's a wonderful choise. But few games make that choice.

Have you actually tested doing a camera that way? Because personally I've played/playtested a couple things where the camera *can* go inside objects, and it just ends up feeling very weird to me that I'm looking from inside an object but not seeing it. So perhaps too many people share my reaction, and people who've actually tried it have noticed that (if it's the case)?

Jess Kay I've played a few games that way, it was quite nice. There was no dicomfort, since the camera always goes where you expect and shows what you need.

Fair enough, I'm not at all saying my reaction is universal, but it's definitely not something that feels comfortable to everyone. So in light of that I still don't think it's just a lazy decision.

+David Hoskins I'm envisioning this as I wonder what made them chose that approach over just cutting to an establishing shot from a third person view, too - choosing a neutral angle when you walk into the room, cut to and hold that for a beat, and going from there...

One of my favorite things about Half-Life is that at no point in the game your vision leaves Gordon Freeman's perspective, it's awesome.

There are two games called "Thief," one released in 1998 and one in 2014. Which one are you referring to?

The 2014 one, the camera is fucking awful. Why? Because they can, so they did...

Not sure why that'd make you sick...

sonic games made the mistake of existing

Worst mistake of Sonic games (or most of them) is giving incentives for you to go fast and once you go out of the screen punishing you by placing a robot/trap in your way. If that's to happen, why not hint the player before? Give the player a fair chance of dodging, counter this! It could even become part of the fun.

Have you even played the Mega Drive ones? Or even the DS ones. They're great!

bananaboy482 Like you.

Kennedy Richard Games They do the exact thing you describe.

(late answer :P) Sadly hard to fix for Minecraft as you can't just tag obstacles or something as it's a player-made world.

Well, it's not really a third person camera, just a first person camera with an offset. That being said, a decent third person camera would be nice.

Yea, it make me feel sick

Sure you don't mean #33?

@@Asdayasman Nope I meant #9. Although Minecraft might have changed in 4 years, LOL to make #33 even more relevant than it was. ^^; Back then it's #33-ish problems all were so extreme, jumping in and out of your head and all this other stuff that I couldn't even call it that one. XD

+Chris Koss What do you mean? How would more cameras solve any of the obstacle avoidance problems for the first camera? And which of those cameras would actually render to screen? It would always be only one of them anyway, so I don't see the point of having more cameras, when you can just use raycasting and spherecasting to detect obstacles and such.

Oh no practical use, I just think it would be cool to watch how a camera moves from another camera that is chasing it.

+Chris Koss Ooh okay, so more like a debugging tool then. Yeah that can be done. I've seen similar solutions before :)

+Rafał Dorsz yep! I think if you could get a chain of ~10 of them you'd see some really interesting emergent behavior as some movements could be amplified in fun, non intuitive ways as you go down the chain.

Could we call it a "camera snake"? Or a "camera caterpillar"? Or, since that's too long... a "camterapillar"?

all of the journey footage looked pretty incredible, a lot of the points were focused on not confusing the player & communicating boundaries or trajectories, very little was subjective (like rule of 3rds)

Well those 2 games you mentioned should be played on controller to be fair.

​@@RedNayl That is a common sentiment sure but only because of the terrible m&kb ports. Dark Souls 2 was the worst adding nearly a full second of input lag to attacks and blocks when done with a mouse.

@@RedNayl After Capcom patched the camera controls for the PC port of Monster Hunter World (removing the awkward acceleration and maximum camera speed), it became just as good as controller and arguably better for the ranged weapons that could be played like any other 3rd person shooter. I've played the game with both control schemes and I honestly prefer M&KB because (at least for the most part) they fixed the camera issues that would have necessitated me to play it with a controller in the first place.

he did talk about both points

like, in Sonic Unleashed for example, the FoV is actually increased to increase the sense of speed. in games where the FoV is reduced when going fast, it's likely so you can see more things ahead of you and react to things around you faster. like how in some 2D platformers the camera zooms out when going fast. however increased FoV does make greater sense of speed. at least I think

Yeah, a good rule of thumb is to maintain the direction of motion from before the cut until the player chooses a new direction for themselves. It takes the brain a moment to process the new environmental layout.

The main thing we don't care about at all in those games is 14:54. If the camera can rest out of bounds, let it and make it look good. That is what we have found to offer the best player experience (we also tried moving the camera closer and players hate it)

This is the approach I've seen, especially in 3D dynamic camera Mario titles. I think there's not a one-size-fits-all solution though because every game has different player navigation and tone needs

Yeah! Especially in games with a lot of enemies on screen.

+nossfu Agreed, especially on PC where the mouse can quickly and easily move the camera. I found the automatic camera in the Tomb Raider reboot to be a huge problem.

+nossfu He touches on that with #35. I agree entirely - any time a game takes obvious and/or immediate control over my camera, it's annoying at best, disorienting and nauseating at worst.

Just make it once and then you can reuse it and DON'T do a fucking AAA game camera. Old 3D platformers are the superior camera like Mario 64, Rayman 3, Sly Cooper and Spyro The Dragon. No fucking scripted cutscenes and locked angles for dramatic effect I want as much freedom as an FPS

@@magnusm4 yeah Sly and Spyro are great. But Shadow of the Colossus is my personal favourite in terms of camera work. Love how the camera changes slightly depending on gameplay context (on horse, sword fight, walking climbing)

The avatar that failed to jump on the pillar was the companion. If it was the player, a more serious issue would be the player leaving the screen. Even just a little (3 frames worth) of movement smoothing would help your eyes track objects on screen.

+Deathbrewer Listen man, you should stop your harsh criticism of older games and understand that they were struggling with the advent of 3D gaming. lol :)

yea dark sopuls best game ever

Only bad part about Dark Souls is when you are not locked on during a boss. Having to move the right stick takes away your thumb from the dodge button. Other than that, the controls are perfect imo

or use keyboard and mouse

+Velocity Eleven No, when you move up, the image goes up.

+akawhut But if the "image" goes up, and your view of the image stays the same, the effect on the screen is the "camera" moves down. You could argue the correlation either way - for example, sliding your finger down on a phone screen moves the "camera" upwards. This comes naturally to us because it's like sliding a piece of paper. I don't use inverted, but I'm pretty sure the primary intuition is that your controls on the camera are as if the analog stick is attached to the back of the player's head - move it up, tilt his head down and vice versa.

Or rather, it often isn't :(

Yeah or from SotC! Still working on recreating the system.

The purpose of cameras is to focus attention on something else. Cameras are most noticeable when they fail. Camera distances: 1) Fixed-angle third person (never rotates) (good for 2d games) 2) Dynamic third-person 3) First-person Mistakes: #1: Using a dynamic camera when another approach would work. (No shame in focusing on other features. Fixed-angle cameras are great. Best for gamejams, limited resourses). #2: Designing levels and camera behaviors don't match. (Cameras work with level design to aid navigation, reveal information that's relevant to player's decisions. Camera should be prepared to work with frequently encountered situations). #3: Using global coordinates or quaternions to persist the camera state. (Instead of storing the camera coords - save it's offset from the player's position and rotation angle if needed). #4: Using a default camera distance that's likely to break line-of-sight. (The smaller the danger zone, the easier it is to avoid. Line-of-sight must be small enough to fit through levels). #5: Allowing obstacles to break line-of-sight from the side.(Detect obstacles with raycasts. Reuse results ffrom previous frame to reduce load. Swing away from obstacles to avoid them). #6: Pushing away from an obstacle while the player is trying to swing towards it. (Never ignore player intent. When avoidance and intent in conflict, intent wins. We can get the camera closer to the player to squeeze it between the player and the obstacle). #7: Letting the player push the camera inside an obstacle.(This can only be achieved by shrinking line-of-sight. Camera sphere colliders can also help). #8: Letting independent forces compete to push the camera. (There are only 7 axes to adjust. Organize forces by degree-of-freedom, prioritizing forces for each axis). #9: Keeping narrow columns from breaking line-of-sight. (Obsessively preserving line-of-sight results in doing gymnastics to keep a twig from passing in front of the avatar. Tag obstacles that are allowed to break line-of-sight. Raycasts ignore the tagged obstacles). #10: Letting the camera intersect narrow columns. (Breaking line-of-sight may be okay. Smashing the camera isn't. Try simple sphere collision detection for the camera). #11: Interpreting a hill as a wall to be avoided. (Hills also count as false positives. Rise above hills instead of swinging away. Try checking the surface normal to determine if you should be swinging away from or rising above the obstacle). #12: Swinging sideways when occluders come from behind. (Avatar collision protects line-of-sight from the front. Raycasts protect from the side. But we need a new rule to catch obstacles from the back before the raycasts catch them. Resolve the occlusion by pulling camera forward). #13: Letting the camera's near-clipping-plane intersect the avatar. (In emergencies, the camera may need to squeeze between avatars and walls. Can't get closer than near-clipping-plane distance. Need a gap between avatar model and collision radius for guaranteed camera space. Alternatively, fade out the avatar). #14: Using the same camera distance for all angles. (Up and down in particular. Worm's eye view leaves very little camera space. Use a smooth curve to gracefully transition into a closeup. Bird's eye view reduces visibility, hiding horizon. Reduce claustrophobia by pulling back slightly). #15: Using the save field-of-view for worm's eye angles and standard angles. (The sky is really, really big. Humans take it all in with peripheral vision. Imitate peripheral vision by expanding field-of-view). #16: Shifting pitch, distance, and field-of-view independently. (It feels laggy when linked variables must play catch-up. Distance and field-of-view both affect avatar screen size. Moving them independently make avatar appear to change size. Moving them together can preserve size. Distance and field-of-view should be instantly derived from pitch, shifting together like gears. Additional rules can be applied as offsets to the derived base values). #17: Not cutting when the avatart passes through opaque areas. (Avatar collision USUALLY protects line-of-sight from the front. But opaque things aren't always solid. Only one option left: cut). #18: Letting cuts remap directional controls (Pressing the directional stick upward means forward. But the camera decides which direction is forward. Players adapt when forward rotates smoothly, but it's impossible to teleport your thumb when a camera cuts. Give the player a moment to get used to the new angle before requiring a new input). #19: Breaking the player's sense of direction. (Cuts are common in cinema, but players need to be able to navigate. Players navigate with a combination of landmarks and dead reckoning. Cuts break the latter. Cut sparingly. If the camera must cut, avoid changing the angle more than 90 degrees, and try to keep landmarks in view). #20: Violating the 180 degree rule. (Well-known in cinema, the 180 degree rule is less important to games because it only matters during cuts. But it applies to cutscenes! Align the game camera with the end of a cutscene and transition smoothly to the game camera to preserve sense of direction).

#21: Focusing only on the avatar. (The avatar is not an island! Player need to see where they're going, and it's the camera's job to show them). #22: Relying on players to control the camera all the time. (For many players, controlling an avatar and a camera at the same time is hard. There are many tricks to point the camera in the right direction automatically). #23: Leawing the camera yaw alone while the player is running. (Players usually want to look in the same direction that they're running in. The simplest way to guide players is to show them where they're going. The camera should drift behind moving players. It's good to use player's velocity for this). #24: Making it hard to judge distances. (The game may be 3D, but the screen is 2D. Depth perception is weak. Distances are easiest to judge when they allign with the plane of the screen. Side views are great for vertical navigation. Top views are good for horizontal navigation). #25: Looking straight ahead as the avatar approaches a cliff. (Use raycasts to determine the elevation ahead and detect drops. Tilt to an overhead view to show how far the avatar is from the edge, and how to allow the player to see below. Lifting the camera over the avatar keeps it from hitting the ground in case the avatar suddenly drops down). #26: Keeping the camera level when the avatar is running up or down a slope. (A straight-ahead view feels like an overhead view when climbing a slope. The slope immediately under avatar's feet may be bumpy. Use raycasts to determine average slope. It's easy for raycasts to mistake a short wall for an upward hill. Distinguish with surface normals). #27: Misusing the "Rule of thirds". (Framing thing off-center can be pleasant. But don't pivot in-place! Instead, slide sideways to frame the avatar. But the players use the center of the screen to aim the directional stick). #28: Using the same logic for ground and air motion. (Players need to make different judgements depending on their form of transport. The camera should adapt. When jumping or flying, players want to see where they'll land. Look downward. Short hops might not require any change. Moderate rule changes by the avatar's height above ground). #29: Relying entirely on procedural camera behaviours. (Raycasts can only convey boundaries. They don't indicate values. As designers we have a better idea of what's important. For special cases, use scripted "hints" to point yaw or pitch at a target). #30: Letting players make themselves lost and confused. (Detect whether a player has started backtracking a significant distance or veering away from targets. Gently rotate the camera to guide the player back. Explicitly telling the player where to go robs them of the sence of discovery). #31: Rotating to look at nearby targets. (Nearby targets change direction frequently. Trying to keep up results in flailing around. Move back or sideways to include targets in the view). #32: Translating to look at distant targets. (Distance targets will stay roughly the same direction from the avatar. The further away they are, the further the camera would have to move to account for them. The only way to look at the sun is to rotate the camera). #33: Letting the avatar's own body occlude targets ahead. (If the avatar and the target are both aligned with the horizontal center of the screen, they need to be vertically offset to be able to see both. A slight bird's eye view usually works fine. Alternatively, slide sideways for a horizontal offset). #34: Giving the player control over the camera and then taking it away. (Hints and rails can provide "default" camera angles, but let the player to override them. If you have to take away the player's control, make sure that the camera is already showing what the player needs to see). #35: Immediately applying a hint after the player finished turning the camera to look at something. (If the player intentionally turned to look at somrthing, they probably want to examine it before moving on. If there's nothing important, let the camera rest for a moment or until the avatar moves). #36: Not letting experts explore. (Curious and experienced players may want to break the rules and explore a bit more. Beginners need guidance, but letting experts control the camera lets them choose what matters to them. After the hint has helped the player achieve their goal - it can be disengaged). #37: Not providing inverted controls. (Many players are used to inverted camera controls on one or both axes, and it's hard for them to relearn. Not having the option simply limits your audience). #38: Responding to accidental controller input. (When using a gyroscope, to minimize accidental input, constantly recalibrate the neutral position to adapt to the player's posture). #39: Using linear sensitivity. (Analog sticks don't have much range. To provide more perceived range, use and "S" curve for the sensitivity. Intermediate positions should be significantly less sensitive than extreme positions, allowing players to make small adjustments). #40: Letting the camera pivot drift too far. (Jerky avatar motions can be smoothed out by letting the avatar drift slightly from the center of the screen. But it's easy to let a fast player escape the screen entirely. Limit how far the camera can drift). #41: Using a small field-of-view. (The more the camera is zoomed in, the faster everything appears to move. Camera zoom should be tuned to fit the environment size and avatar speed. First-person games often make players feel sick. Expanding the field-of-view reduces simulation sickness). #42: Rapidly shifting field-of-view. (Racing games often change FOV when boosting. First-person games change FOV when aiming. FOV shifts feel like forward-backward motion and can be a trigger for simulation sickness). #43: Shaking the camera. ("Screen shake" is often used to emphasize impacts. But it's pretty clearly a trigger for simulation sickness. Just provide a feature in the options meny to tone it down). #44: Bouncing the camera with the avatar's walk cicle. (The up-and-down motion can be nauseating, also needs a menu option). #45: Translating or rotating up and down when the avatar jumps. (The camera can ignore temporary vertical motion. If the player landed - the camera moves to the new vertical position). #46: Rapidly transitioning to a new camera position. (Yanking the camera isn't much better for sence of direction than a cut, and can still trigger simulation sickness. If it's a moment when control is taken away from the player, a cut would be perfect). #47: Maintaining the pitch speed until hitting the pitch limit. (Pitch has higher and lower bounds. Stopping abruptly at the limit triggers simulation sickness. Decelerate as the camera approaches the limit for a smooth stop (example is moving the camera up, pointing to the sky. when the camera gets closer to the end position - make it move slower.) ). #48: Developing for VR only. (Triggers simulation sickness very often. Don't make VR mandatory for your game). #49: Testing with a narrow demographic. (People who already play the type of game you're making won't help you grow your audience. Children and beginners will point out many design flaws. Ask testers if the game makes them sick). #50: Writing a general "constraint solver". (All of these mistakes are part of the iteration process. It's a lot easier to iterate on rules that interact in predictable ways. It's important to deeply understand the relationships between the constraints).

Thanks a ton, really appreciate it!

it wasn't a very good camera system tbh. I knew he was talking out his ass as soon as he said the point of a camera is to draw the player's attention attention to certain things above others

KingHalbatorix could you elaborate your point? I'm not sure if I disagree with him there.

KingHalbatorix This is different for different genres. But even in games where the camera is solely a tool there are a few moments, where the camera is needed to highlight things.

This can work for many games though, and it definitely worked in journey. Wanna experience a frustrating camera, go play sotc! :( lol

Yep. Imo fixed camera just aged badly, I understand why people who study game cameras will praise it, but honestly? If your game has anything that remotely envolves reflexes on the gameplay, you'll be much better having a dynamic camera. Also, the Link Between Worlds camera is fixed from an upwards angle (almost completely vertical) which is what helps the most for that 2D style of gameplay. That mario game camera is from an awkward diagonal angle which is nauseating for today's standarts.