The gameplay camera

The camera your players look through is a camera entity with isMain turned on. Its camera component decides how the game is framed, and the framing is part of what a game feels like: a platformer wants to see the ground ahead, a shooter wants to be close behind a shoulder.

Everything here reaches all three places a map runs — the published game, a standalone build, and the editor's Play button — because they share one camera step.

Modes

Mode	What it does
Third person (default)	orbits behind the player on the mouse
First person	sits at the player's eyes
Fixed	stays where the camera entity is, pointing where it points
Follow	trails a chosen entity at the offset you placed it
Cinematic	circles the player slowly, hands off

Third and first person are the same rig, and players move between them with V. A map that picks one in the component starts there.

Framing the third-person camera

Three numbers, all on the camera component:

Field	Default	What it does
distance	8	how far behind the player the camera orbits
heightOffset	2	how high above the player it looks — the point it pivots around
shoulderOffset	0	how far to the SIDE it sits: the over-the-shoulder framing

The defaults are a wide, high, centred view. That reads well for building and platforming, where you want to see where you are going, and it is deliberately not a shooting camera.

Over the shoulder

shoulderOffset slides the camera sideways without turning it. Positive puts it over the player's right shoulder, which draws them on the LEFT of the screen — the framing most shooters use. Negative swaps sides. Zero is the centred orbit every map had before the field existed.

A shooter framing is roughly:

distance      3
heightOffset  1.6
shoulderOffset  0.8      (or -0.8 to put the character on the right)

Combine it with a fov of 70 or so. Lower heightOffset toward the shoulders and the camera stops looking down at the player from above; shorter distance puts them in the frame rather than in the middle distance.

Two things the offset deliberately does not do. It does not turn the camera — the view is slid sideways, not swung inward, so the horizon stays level and the crosshair keeps pointing where the camera points. And it does not move your shots off the crosshair: what you hit is still what the crosshair is over, at every range. Zooming to first person walks the offset back to centre on its own.

What it does change is where a shot comes FROM. The camera looks past the player's shoulder, so you can see — and shoot — around a corner your character is still behind. Every over-the-shoulder game works this way; it is worth knowing when you place cover.

The camera also stays out of walls, and pulling in from an obstruction gradually gives the offset up as it closes on the player. In a tight corridor an over-the-shoulder camera becomes a centred one, then a very close one. Give a shooter room to back into.

The mouse wheel

By default the wheel does nothing. Game Settings has one choice for what it should do, in gameSettings.mouseWheel:

Choice	What the wheel does
Nothing (default)	the wheel is free for your own map to use
Zoom the camera	moves the camera in and out, reaching first person at the closest end
Switch tools	steps through the hotbar slots that hold something

It is one choice rather than a switch for each because there is only one wheel — a map that turned on both would be asking for two answers to the same input.

One physical click of a wheel is one step, whatever the player's hardware reports and whether they are on a mouse or a trackpad. A trackpad's small continuous movement adds up to whole steps rather than racing through the hotbar.

Zoom bounds

Two more fields on the camera component, and they only matter when the wheel is set to zoom:

Field	Default	What it does
zoomMin	0	closest the wheel may pull in. 0 reaches first person
zoomMax	40	furthest it may push out

distance is where the camera starts, and it is clamped into this range.

Set zoomMin and zoomMax to the SAME number to lock the zoom. That is how you keep an authored framing: an over-the-shoulder shooter camera is not worth setting up if a player can scroll out of it, and locking is also what frees the wheel for weapons.

A notch moves further when the camera is already far out and less when it is close, so you get fine control over the framing that matters and quick travel over the range that does not.

Switching tools

By default the wheel walks the slots that actually hold something and wraps at both ends, so a hotbar with weapons on 1-4 and building tools on 7-9 steps 4 → 7 and never stops on the empty 5 and 6.

Two toggles change the shape of that rotation, and they are independent:

Setting	Default	Rotation
neither		1, 2, 3, 4, 7, 8, 9, 1, …
mouseWheelNoItem	off	1, 2, 3, 4, 7, 8, 9, no item, 1, …
mouseWheelIgnoreEmpty: false	on	1, 2, 3, 4, 5, 6, 7, 8, 9, 1, …
both		1, 2, 3, 4, 5, 6, 7, 8, 9, no item, 1, …

mouseWheelNoItem adds a stop where the player is carrying nothing. One per lap, at the wrap between the last slot and the first — not one per gap. Some games want to be able to put their hands down; in others that is an accident waiting to happen mid-fight.

mouseWheelIgnoreEmpty is on unless you turn it off. Off means every slot is a stop, gaps included, and passing through an empty one puts the player's hands down.

Without the no-item stop the wheel never unequips: a number key means "this one", a notch means "the next one".

Reading the wheel from a script

input.getMouseScrollDelta() returns this frame's movement as [x, y], y positive for scroll up — the same shape and sign as Input.mouseScrollDelta, which is also accepted as an alias.

It reads the machine the script runs on. That is the player's own mouse in the play-test and in a standalone build, and nothing in a published multiplayer game, where scripts run on the server and there is no mouse attached to it. This is the same rule that applies to input.getKeyDown, and for per-player input in a room the answer is the same too: input.watchKeys with onPlayerKeyDown (see Multiplayer scripting). For a wheel that acts in a published game, set mouseWheel above and let the engine do it on each player's own machine.

Field of view

fov is vertical, in degrees, and defaults to 60. Shooters usually run wider — 70 to 90 — which shows more of the room and makes movement feel faster. Very wide values bend the edges of the screen. The usable range is 1 to 120, and a value outside it is pulled back to the nearest end when the camera is applied. The ceiling is about what you can play through rather than what the maths survives: a perspective view has no valid projection at all at 180 (past it the picture comes out mirrored), and long before that the world has already squeezed itself into a spike in the middle of the screen.

focalLength is there for anyone who would rather think in millimetres: set it and it takes over from fov, with sensorSize for the film gauge. Around 24mm is wide, 50mm normal, 85mm long.

More than one camera

With several isMain cameras in a map, the one with the highest depth drives the view; on a tie the one higher in the hierarchy wins. Unticking a camera's component checkbox takes it out of the running, and so does deactivating its entity (or any parent) — so keeping two shots authored and switching between them is a matter of depth, the checkbox, or the entity's active toggle.

A camera entity without isMain can still render: give it a viewport rect for a minimap or a split-screen pane, or turn on renderToTexture to draw its view onto a surface in the world for a security monitor. depth orders the panes too — higher draws on top. See Rendering.

Taking the camera over from a script

camera.setType('scriptable') detaches the rig so a script can place the camera itself — cutscenes, kill-cams, a fixed shot for one room. camera.setType('custom') gives it back to the player. On a map with no built-in character the camera entity's own transform is the camera, and script pose writes go straight to it. See Scripting basics.