Follow up to the camera question. Who is usually responsible for how the game camera act? Is that a problem for engineers/programmers for the engine or do Game Devs need to have discreet control over what the camera does?
Generally speaking, game designers are responsible for determining how something in game acts and game programmers are responsible for making that something act appropriately. Let’s take a reasonably simple example here - let’s say we wanted to have short cinematic scenes in our game. Let’s use this conversation from one of my favorite films, the Princess Bride:
What is the minimum necessary feature set someone would need to recreate this scene? In no particular order, here’s what I came up with:
Play animation on character body
Deliver Dialogue (including lip sync)
Gameplay programmer Cleo would be tasked with writing a tool that designers could use to specify commands to run at specific times, and she would be responsible for making those commands actually do that. Then she would pass the tool on to the cinematic designers to create cinematics with.
Cinematic designer Ranzal would be tasked with writing a cinematic script that uses these commands to bring this particular scene to life, like so:
0:00 SetPosition Inigo InigoPosition1
0:00 SetPosition Roberts RobertsPosition1\
0:00 INIGO: I could do that. I have got some rope up here. But I do not think you would accept my help, since I am only waiting around to kill you!
0:08 Play RobertsClimbAnim1
0:08 ROBERTS: That does put a damper on our relationship
0:11 INIGO: But… I promise I will not kill you until I reach the top
0:16 Play RobertsClimbAnim2
0:16 ROBERTS: That’s very comforting, but I’m afraid you just have to wait.
0:20 INIGO: I hate waiting… I could give you my word as a Spaniard!
Then, Ranzal would place location markers within the environment for Camera1, Camera2, Camera3, InigoPosition1, InigoPosition2, RobertsPosition1, RobertsPosition2, etc.
For a particular cinematic, the features of the camera like placement, orientation, zoom, field of view, etc. are determined by the cinematic designer, depending on the sort of feeling that’s intended for the player. Maybe that’s a close up shot to show sincerity, or a long shot to show the difficulty of the task at hand.
Often we take a more generalized approach - a gameplay camera that follows the player at a distance, doesn’t clip through walls, and generally tries to frame the action. In that case, the breakdown is still the same - the designer (usually the creative director in this case) in charge figures out how she wants the camera to behave (including the edge cases), and the gameplay programmer is tasked with making it happen. Here’s a few example edge cases:
If the camera can’t clip through walls, what happens if the player backs into a corner?
Should the camera behave differently in combat?
If the player is locked on to a specific enemy, what should the camera do?
If the player is being targeted by an enemy, what should the camera do?
When the camera has multiple different commands all trying to run at the same time, what takes priority?
The designer figures out what the camera should do and the programmer is responsible for identifying those situations and making the camera choose appropriate behavior. The nice thing is that we don’t have to set any of these in stone as we go. We can iterate on the design and feel of the camera by experimentation and obtaining feedback, add additional features like more granular camera controls (e.g. look at this, move to there, rotate, pan, zoom, etc.), and so on as time progresses, based on the needs of the game, the schedule, and the budget.
The FANTa Project is currently on hiatus while I am crunching at work too busy.
[What is the FANTa project?] [Git the FANTa Project]
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
