Camera
One rig, first or third person, owned by the character it follows. It is also the thing WASD is relative to — which is why the camera is a gameplay component here rather than set dressing, and why each split-screen player carries their own.
The camera is part of the character
CameraRig is normally a child of the character it follows, not a scene-level object watching from outside. That is a deliberate structural choice, and three things follow from it.
First, movement has a reference frame. PlanarForward and PlanarRightare the camera's yaw flattened onto the ground plane, and they are what "forward" means when a player pushes the stick up. Without a rig, WASD has nothing to be relative to.
Second, input routing is free. Because the rig is under the character, it receives that player's input the same way the character does — its own device, never another player's.
Third, split-screen works without a special case: each spawned player instantiates the whole prefab, camera included, and Unity's input manager arranges the viewports.
// What "forward" means for movement, from CameraRig:
public Vector3 PlanarForward => Quaternion.Euler(0f, Yaw, 0f) * Vector3.forward;
public Vector3 PlanarRight => Quaternion.Euler(0f, Yaw, 0f) * Vector3.right;Fields
| Field | Type | Default | What it does |
|---|---|---|---|
target | Transform | — | What the rig follows and orbits. On the player prefab this is already wired to the character. |
mouseSensitivity | float | 2 | Degrees of look per unit of mouse delta. |
gamepadLookDegreesPerSecond | float | 120 | Stick look speed. Separate from mouse sensitivity because the two devices are not the same units and a shared number always feels wrong on one of them. |
thirdPersonDistance | float | 5 | How far behind the target the camera sits in third person. |
thirdPersonHeight | float | 1.6 | Height of the third-person orbit above the target's root. |
firstPersonHeight | float | 1.6 | Eye height in first person. |
minPitch | float | -40 | How far down the player can look. |
maxPitch | float | 75 | How far up the player can look. |
hideInFirstPerson | Renderer[] | — | Renderers switched off while in first person — the character's own head and body, which would otherwise fill the view. |
showFramingGizmo | bool | true | Draws the third-person orbit and first-person eye height as a Scene-view gizmo while the rig is selected, so distance and height are visible without pressing play. |
First and third person
The view toggle is an input action, not a key check: ToggleView, bound to V on keyboard and right stick click on a gamepad. Both schemes can switch, and rebinding is editing the input asset.
IsFirstPersonis readable from code, so anything that needs to behave differently in each view can ask. Setting it is deliberately not part of the public surface today: the view is the player's choice, and the toggle is theirs to press. If you need a scripted sequence to force a view, that is a gap worth telling us about rather than one to work around.
Yaw and Pitchread the rig's current look angles, and the Inspector shows both live in play mode — along with which look device is driving the rig and whether a UI panel currently has it paused — so a "why is look not responding" report starts from a readout instead of a debugger. Selecting the rig in the Scene view also previews the third-person orbit and the first-person eye height as a gizmo, so distance and height are visible before you press play.
Cursor focus, and why it is counted
Opening the inventory needs a cursor. Mouse-look needs the cursor locked. Those two facts fight, and the referee is SetUiFocus.
While any panel holds focus:
| Field | Type | What it does |
|---|---|---|
Cursor | effect | Unlocked and visible, so the panel can be used. |
Look input | effect | Paused — moving the mouse over a panel does not swing the camera. |
Click-to-relock | effect | Suppressed, so clicking a button in the panel does not immediately recapture the cursor. |
Movement | effect | Untouched. WASD never involved the cursor, so it keeps working — walking while a panel is open is deliberate, not an oversight. |
using Curitor.PartyCoreKit.CameraSystem;
using UnityEngine;
public class CustomPanel : MonoBehaviour
{
[SerializeField] private CameraRig rig;
// Balanced calls -- one release per request, or the cursor gets stuck.
private void OnEnable() => rig.SetUiFocus(true);
private void OnDisable() => rig.SetUiFocus(false);
}Mouse and gamepad are not symmetric
Look works on both. Cursor locking is Keyboard&Mouse only, because a cursor is inherently a mouse concept — a gamepad player looks with the stick and never involves one. UsesMouseLook reports which world this rig is in, and the focus machinery above simply does nothing on a pad.
Split-screen
In local co-op, Unity's player input manager instantiates the whole player prefab — capsule and child camera — once per joined device, and enables split-screen viewport management from each player's camera. The kit adds only the part that is not automatic: giving each new player a distinct spawn point instead of stacking everyone at the prefab's authored position.
The practical consequence for you: there is nothing camera- specific to configure for split-screen. If the camera is a child of the player prefab, it works. If you lift it out to a scene object, it stops working, and it stops working for two players rather than one — which is the failure mode worth knowing about before you refactor.
Feedback: camera shake
CameraShake is an optional companion component on the rig — add it and a Feedback Definition with a non-zero cameraShake amount can add trauma to it, decaying on its own and offsetting the camera every frame through OnAfterPositioned, the seam this rig raises immediately after it sets the frame's base transform. With no trauma active it writes nothing, so the camera sits exactly where the rig alone put it.
The affected player named by a play gets the full shake amount on their own camera regardless of distance; every other local camera falls off by distance instead — the split-screen-aware behaviour a shared hit needs, since several rigs are active at once and each judges its own falloff independently. Full field-by-field reference, the trauma model, and how hit-stop interacts with it live on the Feedback page.