top of page

Site Unseen Tools - The Camera Director


Site Unseen's most unique and visible technical feature is the multi-camera display. The very earliest prototypes of the game used multiple screens and required the player to physically move around a space to explore the views. Over time (and mainly because we wanted it to playable outside of specifically built installations.) this developed into the current dynamically splitting screen system we have now.

Under the hood the game uses Unity's layer culling system on the cameras and moves the camera rects around to achieve the overall effect. There are tradeoffs to doing it this way, with the biggest drawback being that we're limited to only using square edges. The main benefits are in reducing the amount of rendering overhead (compared to something like render textures with a stencil buffer) and having the in-built camera systems in unity handle things like FOV and scaling.


Because the camera changes dynamically during exploration, this led to some specific challenges with prototyping levels. The main problem we faces was that there was no way to reliably guess what the layout would look like until in play-mode. The other big drawback was that each puzzle had to be coded to specifically override the default layout.

To solve these issues I created a series of tools that work together to make it much easier and artist friendly to develop levels. The core of this is the "Camera Layout" object. This component stores a specific layout and adds a visual representation of the final screen view in the inspector so choosing layouts is less of a guessing game. These layouts are then passed into the camera manager (the "Director") which sorts them to create the final layout.


The two biggest benefits of this are that changing the layout no longer requires a lot of guesswork and code; and that as a scriptable object it can be passed to the director via some simple code in pretty much any way we can think of. The most common methods we currently use is are simple trigger volumes or view targets, but layouts can be coded to sync with music or even be animated using the timeline.


These layouts are finally sent to the camera manager object which sorts them by their influence value (We can use this with things like distance checks to create slow transitions).

The manager component also has a couple of extra features to control the default animation speed, override the FOV of all cameras, and ensure the correct culling masks are applied to each camera object.


bottom of page