Cameras are hard. If you’ve ever found yourself fighting against a camera that would really like to pivot in a direction you don’t want it to, you’ve been on the receiving side of this technical difficulty. The reason behind your struggle is simple: spiteful developers.

Not really. Or at least probably not. The fact of the matter is that making a camera which balances the atmosphere of a game, moves quickly enough to keep up with the player, moves slowly enough to not move around with the player’s jitters, and accounts for the corner cases like a player getting teleported — it’s not a simple thing.

I’d like to talk about the different methods I’ve been experimenting with in Clearing Skies. This is as much a journal entry for me to see what I’ve tried and why it works or doesn’t work as anything else. I hope that someone may find some insight in it.

Approach 0: Strap the camera to the player.

This is the simplest and most straightforward approach to moving the camera. Wherever the player moves, the camera follows.

• Simple! Easy to implement and understand.
• Basically no corner cases where movement will be odd.

There are some drawbacks, and they’re not too hard to see. When the player shakes or moves about drastically (like if she shakes after a shock or hit), the camera is liable to jitter along with her. Shaking the camera is a good way to induce nausea or eye strain in the player. Additionally, you lose the sense of level depth. The entire space is continuous. This is fine, generally, but for the first dungeon in particular, this felt to me like it shrank the space considerably.

• Can cause eyestrain for sudden movements.
• No way to add ‘cinematic’ elements on transitions between rooms.

Maybe there’s an easy solution to the rapid movement problem? Indeed, we can try…

Approach 1: Smoothed Camera Movement.

The camera smoothly transitions between where it is and where the player is located. This solves a lot of the issues with the player shaking rapidly. It’s like attaching a spring to a camera gimbal.

• Still easy to implement.
• Reduces eye strain from rapid motion.

The downsides are visible in the gif above. The biggest issue we run in to is the rapid movement of the player between rooms. The camera has to spend a few frames catching up to the player location on transport to a distant location. This can be solved by snapping the camera (disabling smooth on transition), on setting a max threshold before the camera teleports, or a few other tricks. No matter what, it’s a bit more involved than simply assigning a location, and it still doesn’t give us the cinematic room sweeping we want.

• Camera has to catch up on long moves.
• No cinematic controls.

Approach 2: Camera Zones

When the player character enters an area, the camera’s bounds are set to match the region. This means the camera moves smoothly inside the zone, sliding to follow the player and ‘transitioning’ when the player moves between regions. I like the way this looks — it divides the map in such a way that it makes things appear larger than they are.

• Looks good. Cinematic.
• High degree of control over where the camera moves. Can cut off areas outside of the map to avoid wasting screen real estate.

It’s not perfect, though. Transitions are very abrupt and might cause issues with visual tracking of the player. It’s also very cumbersome to implement, as the zones need to be defined manually:

Furthermore, troubles come in the way of overlapping rectangles. Not the region on the bottom where it may be necessary for two zones to overlap. Plus, when we finally leave the map, the bounds for the camera will need to change. Lastly, when we change the camera bounds, we lose the ability to smoothly transition between states.

• Possibility of weird edge cases when moving between zones.
• Time consuming to put together regions.
• Not clear how to restore full camera zone when leaving dungeon.
• No smooth transitions.
• Visual tracking is hard on screen switches.

In a more perfect world, I’d love to be able to define small pins which act as boundary keepers for the camera, then, if a distance is exceeded, have the camera quickly tween to the player location and return to tracking. I don’t have a solution for that worked out yet, however. Time will tell if I get it solved.