Domain Driven Camera System

Cameras - The things we use to see in games. They're amazingly handy tools that almost every type of game requires. Much like in film and photography though, their role is more important than just simply showing the scene. Everything from the framing to the nuanced movement can help evoke different feelings and perceptions. They can make characters seem small and insignificant in a large world or make the player feel as if they're in an uncomfortably small space with cameras almost hugging the characters. In this post, I'll be discussing a concept I've been working with recently that revolves around the idea of making it much easier to change the behavior of game cameras to best convey specific feelings within reoccurring areas. So let's get to it!

Two games using a similar type of camera for very different effects
Left: Metal Gear Solid V: The Phantom Pain
Right: Dead Space 2

To start with, let me take a minute to introduce the idea of Domains. There's nothing too complex to them, they're essentially volumes within a level that hold a String which we'll use later. Why are they so important? Domains are used to denote what areas should use camera values that deviate from the normal ones, essentially acting as a way to say "This area is special". For example, if you had a forested area within a larger world you could make the entire area a Domain, you could also say that the forest is one domain and within it is a clearing which is a separate Domain! The nice thing with this approach is that a Domain can be as big or small as you'd like.

So how does this concept work? Well remember that String the Domain's use? That acts as an ID which, when the Domain is entered, the Camera uses to search in a table to find what values it should start transitioning to and use while in the area. The idea behind this approach, rather than storing the values within each Domain individually, is that it allows for easy reuse of already existing values. After all, if you want every forest to use the same Domain then why make a new Domain that uses the same values every time? The other benefit to this is that while you can assign different values to different areas, similar areas can still feel similar and connected to each other!

So that's the concept in a nutshell - You have a volume that, when entered, searches a table for what values the camera should use! Seems simple enough, right? Well, that was honestly the high level breakdown of it. I'm sure some of you are reading this and thinking "Well, what values are affected here and how does the camera change?" And the answer to that is: Find out for yourself!...Seriously, this is where it starts going from 'my idea' to 'how you use it' since your Camera could have a lot of different stuff that one I've made doesn't. With that said, I will try to give a starting off point: The Camera I was using to test this concept was a pretty simple third person set up.

The main values used were:
- An Offset/Dolly (with a min/max clamp and speed) for how far from the Player it should be
- A Horizontal Pan/Truck and Vertical Pan/Pedestal (max clamp and speed) for how far it could move vertically and horizontally away from the Pivot Point
- Pivot Point Offset, which is where the Pivot Point is offset from the Player's position
- Pitch Clamp, the max and min Pitch for the Camera's orientation
- A bool for whether or not the Horizontal Pan would either center the Player (the offset value moves towards 0) or Push the player to the side (value moves towards the max)

Each of these values could be changed upon entering a new Domain and all but the last of them (which was a bool) were blended into over time. This allowed for a decent variety of different Camera configurations.

The Layout indicating the different areas in a small test map I was using. Any area outside of the Domains (Red - Field, Cyan - Cliff) shown uses the default Camera settings

The above images use free assets from the UE4 Marketplace (Paragon: Shinbi & Soul: Cave)
Left:The view in a Field – The Camera is further away and the Player is more centered to better show the area around them
Right: The Default Camera – It’s pulled in closer and forces the Player to the side

In addition to controlling which parameters are affected by Domains, there's plenty of room for personal touches within the Domains themselves! A very simple one would be adding the option to control how long a blend takes so that specific Domains could have longer transitions than others, while a more complex one would be how to deal with overlapping Domains. How you choose to take this concept further is completely up to you and, much like with Cameras themselves, should be carefully considered based on what you want your game to be like!

I hope that those of you who have made it this far have found this read to be a useful one. I'm looking forward to seeing what others can come up with using this simple concept!