Tuesday, November 8, 2011

Video Game Camera Movement Design Theory

This post is more like a note to myself then anything else, but I thought someone might get some benifit out of the information here.  If nothing else, it will get you thinking on your own games you play about how the camera interacts with the world, and appreciative of those games where someone really sat down and thought about it.

I programmed an orbiting camera today.  I also got it to raytrace when something is in the way to move closer to the player, which in everyday terms is a fancy way of saying "If something is in the way, the camera will move to look behind that something."  Right now it moves behind everything(collectables, any polygon really).

This creates a problem.  The camera goes insane if the player hides behind something too close to them, such as running around a corner, with very little space between them and the wall, without moving the camera.

Hmm...various games have various solutions to this, all of which are pretty complicated to do.  A few examples of fixes used in games I've played, and quick opinions:


-Automatically rotating the camera to look around the corner for the player as they walk that way. But that removes the control of the camera from the player and is not practical in say, a 4 way tunnel intersection(which way do you rotate without knowing where the player is going?  What if there is something interesting directly in the middle too?).

-Forcing the camera along set paths through the level.  Yes, it works, but every game that has done this has really lost the "freedom" of exploring the world.  I say "freedom", because you're never truly free to explore things in video games since everything is a set, like the Truman Show.  But it's important the player feels in control of the game, and forced camera angles are a great way of saying "Well, we want to be in charge of everything you ever look at."  Which while this fact is mostly true for a lot of game types, it's not something you want to be shoving in the players face.

-Just ignoring the problem entirely and letting the camera do whatever the heck it wants.  The problem is that if you don't do this collision check, suddenly the player can look outside the level walls into the "void", which ruins the otherwise very good illusion of the world they are in.  Also, having the camera not react at all to the world forms a subtle, but very real disconnect, reminding the player they are in a "stage" made of polygons, not a real world.  It's just like how in modern games with rain, the game designers will put extra effort into making the rain "stick" to the camera screen.  The player knows they are looking at a tv/computer screen and a "camera" into the game world, so it actually helps to immerse the player if the camera reacts like a true camera would.

Perhaps the best solution, used by Mario games, Zelda, and many other classics:  Allow level elements to be set as "allow the player to walk behind them", and then additionally, only bring the camera closer if the camera is escaping the outside hull of the level.  

This also comes with another simple, but very tricky to program part.  What I've seen some games do is push the camera around it's own "orbit" till it is able to see the player again. In other words, the camera is free to spin wherever along it's orbit, but if it tries to escape the level area, it is forced to rotate to a position where it cannot see outside the level anymore. This results in walking around the corner forcing the camera to "orbit" into a better position.  Last, the camera is programmed to be unable to move through certain major level elements, like a balcony on the side of the level.

The benefit of this solution is that the camera has a physical "body" that can't go through things, won't look outside the level(preserving the illusions of a real world), and still is helpful and controllable by the player.  The only places it won't listen to the player moving it are places where in real life you couldn't move it either(into walls, into the ground of a cave, through a barrier fence that isn't open yet in the level.)

If I can figure it out, I'll probably go with this last solution.  If I can't, then I'm just going to go with the "allow the free roaming camera regardless of situation".  As much as I don't like breaking the immersion of the game, I don't want to be spending years coding a camera when the rest of the game needs to be coded as well.

Gawain, signing off for now!