It's primarily a feature handled by game design and engineering. The designers figure out how the camera needs to behave for the intended player experience and then the engineers figure out how to translate those behavior rules into code.
Let's say that we're working on the camera functionality for in-game cinematics for a narrative-heavy AAA game like the Witcher or Dragon Age. The cinematic designers need a solid toolbox to build cinematics with, a set of tools that they will use to create most of the cinematics of the game. That toolbox might include things like:
- Look at X (cut)
- Look at X (pan)
- Zoom in/out
- Move to point Y
- Ease In/Out (acceleration control)
- Camera Shake
As a designer, I would expect that I would be able to activate one or more of these tools at specific time stamps (e.g. at frame 32, pan to Desmal while moving to point A and zooming in) while I script my cinematic. As an engineer, it would be my responsibility to take the description of each of these tools and create them in code. I would then integrate them into the in-game cinematic editor so that the cinematic designers can use them to create the in-game cinematics.
Similar discussions and work take place for things like what the camera should do while the player is in combat, what the camera should do while the player is exploring, and so on.
[Join us on Discord] and/or [Support us on Patreon]
Got a burning question you want answered?
- Short questions: Ask a Game Dev on Twitter
- Long questions: Ask a Game Dev on Tumblr
- Frequent Questions: The FAQ
