Alt Review: GDC: Side Scrolling Cameras

[Alt Reviews is a review of some topic but with my own spin on it.  I.e. I learn from the topic, and mix my own experience and ideas into it.  I do this mentally on all learning content, but I'm sharing it for others benefit as well.]

At GDC 2016, Itay Keren gave a presentation called "Scroll Back: The Theory and Practice of Cameras in Side Scrollers."

Physics Base

2D camera movement is more important that typically realized.  For instance, in many games, a camera is simply affixed to a focal point and never moves off.  An upgrade, is adding minor physics to so that the movement is smoothed out with tethers and springs.  Another upgrade is leading the view, where if you are in a vehicle and picking up speed, the camera might move out to let you see farther ahead, while keeping the vehicle far behind.  Itay's presentation talks about the importance, value and methods of implementing deeper layers of leading and controlling the camera for players.

Itay starts out talking about how the eye works and how the brain recieves images.  First pointing out that the center of our vision and the edge of our vision have different response systems.  The center is very clear, focused, and lower speed.  While the outer/edges is faster, but less attuned to specifics.  It makes assumptions about what it sees.

He brings up 3 topics that are intertwined

• Attention - Make sure the camera shows all things that are important.
• Interaction - Make background movement tightly bound to controls. (Paralax BG's for instance)
• Comfort - Ease of contextualizing background changes.

Issue: How to eliminate unpredictable bumps?  Below is ordered from earlier/lighter methods to newer/more exact methods.  (Its not that one method is better than the other, but that each can have practical value depending on your game design.)

• None.  The camera is locked to the unit.
• Vertical or horizontal snapping.  I.e. the camera freely follows the character along 1 axis, but the other is locked.
• Camera Window. I.e. the camera stays put until the player moves just outside of the camera window.  The window is smaller than the screen.
• With Lock: This forces elements to move with the camera when needed.  Like Street Fighter.
• Works best with Zoom To Fit
• Platform Snapping.  I.e. The camera remains locks when there is nothing for it to do.  Once the player jumps and lands on another platform, the camera quickly (not instantly) moves vertically to that next section.

Next he talks about using the physics to smooth the production.  I tend to use Impulse (small measurable unit of speed) and Velocity (direction * speed).  I.e. as you move, the unit is the target.  As you move, the camera first moves slowly, then picks up speed every frame until it catches up to the target.  (Turns out he talks about this a moment later, as Lerp Smoothing.  :) )

• Forward Focus.  I.e. the camera will show more ahead of the player.
• Dual Forward Focus.  I.e. if the player turns around, the camera switches to provide more space in front of the the direction they are facing.
• Threshold triggered.  I.e. The character can move back a little before triggering camera movement.
• 2D Forward focus.  Any direction the player moves.  the camera moves a little ahead of the player.  Requires smoothing physics for the player control and the camera with Lerp based velocity.
• Target Based focus.  I.e. giving some camera shift based on targets.  such as are the targets in view and important?  Is the mouse over a target?
• Position Averaging.  I.e. focus on multiple players on the screen who both always show up in the same view.  like gauntlet
• Shake.  I.e. Lack of control, something emphasizing the player's lack, or the impact something just had, because the whole world shakes.

The Directors Chair

Next Itay moves on to Directed Paths.  Everything so far has been based on game play focused camera movements.  I personally have provided very little direction in my game development.  A major distinction, is that (typically) the game play focused camera controls are all code based.  A programmers makes them happen as expected.  While a Director's perspective puts more control in front of a level designer.

Note that with the Director's perspective, your still coding all the camera movements, but you are providing tools for the designer to make changes to that mid game.

• Region Based Anchors
• Level or areas in a game change how the camera focus works.  
• If a portion of the game is mostly vertical, then the camera option changes to focus on vertical assist.
• Zoom To fit.  
• zoom in/out to show/focus on key elements in a scene.  
• Example for boss levels
• Cue Focus
• Attractors found in levels that try to shift the camera to it based on its distance from the player.  
• Center Region/Camera
• Focuses on player, but takes an value between the target and the center of the region.
• This gives a sense of where you are in the region, because the camera movement compared to the unit position helps express your location.
• Camera Track
• The camera follows a set track in the game, and moves to keeps its closest position along that track to the player.
• Gives feeling of control of the camera, while allowing the designer complete freedom to setup each angle, zoom/pan, etc...
• Gesture Cues
• Focuses either on actions, or elements in the game, where the camera perspective changes to better show something.  For instance as you hang on an edge, the camera focus might switch from side scroller, to emphasize downward fall more.
• This may also focus on player events, like picking up an object to temporarily highlight the object over their head, or a particular attack, that if it catches, will run several slow motion hits.
• Cinematic Paths
• Predefined set of paths, outside any player control, that shows things happening, 
• This might emphasize an even just off scene event, that helps the story along.  You don't control it, but its very important for story/emphasis.
• This stops actually cut scenes and allows the game to move on without scene loading.

Italy then goes on to talk about Mushroom 11, and all the camera modes that went into it.  I strongly recommend reviewing it.  I'm planning on organizing these thoughts a little further, and write up some code examples, perhaps a Lynda or Udemy class to show it.

So here is another link to "Scroll Back: The Theory and Practice of Cameras in Side Scrollers." I strongly recommend watching it, as Itay goes into far more detail and explanation on each area.