Game & Scene Settings

Two settings windows, and which one a setting lives in is not arbitrary:

	Where	Scope
Game Settings	project	every map in the game — gravity, the player, the economy, the built-in HUD
Scene Settings	this map	one map at a time — sky, fog, lighting, the world border, the void

The rule behind the split: if it describes your GAME it is a Game Setting, and if it describes a PLACE in your game it is a Scene Setting. A game's players jump the same height everywhere, so jump force is project-wide; a cave level is darker and deeper than the surface, so fog and the kill plane belong to each map, and sub-maps each keep their own.

Everything here defaults to the behaviour maps already had. A map that never opens these windows plays exactly as it did.

Where a setting reaches

A map runs in three places, and not every setting means something in all of them. Each table below says which, in these terms:

	What it means
Published game	your game on the platform — a multiplayer room, which is what players join
Standalone	an exported single-player build (Exporting a standalone build)
Play-test	the editor's Play button

The distinction that matters most: anything about OTHER players only exists in a published game. A standalone build and the play-test have one player, so there are no usernames to hide and no remote characters to draw. Those settings are marked "published game only" — they are not broken elsewhere, there is simply nothing for them to act on.

The player

Setting	Default	What it does	Reaches
playerSpeed	7	movement speed	all three
playerJumpForce	16	jump strength	all three
playerHeight / playerRadius	1.8 / 0.3	the capsule players occupy	all three
respawnSeconds	3	seconds between dying and respawning. 0 is instant	all three
disableDefaultPlayer	off	no built-in character at all — you script your own. See Scripting your own player	all three

respawnSeconds is counted by the same rule everywhere a player can die: the room, the death notice on screen, and the editor play-test. A racer might want 0.5; a survival map 10.

The room

Setting	Default	What it does	Reaches
maxPlayers	20	how many players share one multiplayer room, 1-100. Leave it unset and a room seats 20	published game only
playerCollision	on	are players solid to each other	published game only
moveTolerance	1.5	how much faster than their own legs a player may report moving before the server clamps them	published game only

It caps the ROOM, not your audience. Set it to 2 and the third player to press Play is not turned away — they get a room of their own, and the platform keeps opening rooms as people arrive. That is what lets a duel, a co-op run or a 1v1 arena work without writing a lobby: every room of your game is one match.

Things worth knowing before you set a small number:

• It is project-wide, so every sub-map seats the same number. Two players who teleport together arrive in the same room.
• The Invite link next to a room in the server browser names that room, so a friend following it lands with you rather than in a fresh copy — unless the room is genuinely full by the time they click.
• A player who drops keeps their seat for about 45 seconds. At 20 you would never notice; at 2 it is the difference between a blink of packet loss and losing the match, so the room holds their chair and sends other joiners elsewhere until they are back or the hold runs out.
• The Max N players line on your game's browser card is this setting, read off the map when you publish it.

The ceiling of 20 is operational rather than a matter of taste: one room is one simulation running on one server, so a map can ask for a smaller room and never for a bigger one.

Turn playerCollision off for a race, a climb, an obby — anywhere the other players are competition rather than obstacles. They stay fully visible and their names still show; they simply stop blocking a doorway, standing on each other's heads, and shoving a rival off a ledge at the worst moment. Only player-against-player goes away: walls, floors, platforms and every other collider are untouched.

Leave it on for anything where bodies getting in the way is part of the game — a brawler, a sumo ring, a game of tag where cornering someone is the point.

How fast the server lets a player move

A multiplayer room does not re-simulate your character. Your own machine does that and reports where you ended up, which is what makes movement feel instant at any ping. The server's job is to check that the report is possible: each one is bounded by the map's own playerSpeed and playerJumpForce, times moveTolerance. A report over budget is pulled back toward where the client wanted to go, so an honest player on a bad connection slows down rather than rubber-banding.

The default 1.5 is right for almost every map, and for a competitive one it is the setting you want.

Raise it when your gameplay moves a player faster than their legs can explain, and the player's own machine is what does the moving — a bounce pad or launcher driven from a client script, a custom movement controller, a grapple. A launch at 45 units/second on a map whose jump is 16 needs about 3.

Two things the number cannot do:

• It cannot go below 1.5. A falling player already uses exactly 1 / moveTolerance of the descent budget at any speed, so the default's headroom is the margin that keeps long drops smooth; tightening it would rubber-band every fall and buy no real integrity.
• It cannot turn the check off. Even at the maximum the budget is still a bound, so a client claiming to have crossed the map in one frame is still clamped.

Falling is never the thing to worry about here. The descent budget carries the fall already in progress forward, so it accelerates with the fall — a drop of two metres and a drop of four hundred are both well inside it, and raising moveTolerance only widens that further.

Server-issued movement is exempt and needs no setting: a spawn, a respawn, a teleport, or a players.launch called from a server script all tell the room to expect the jump.

The built-in HUD

A published game draws a tool hotbar, a health bar, a death notice, and floating usernames over other players. Those are defaults, not requirements — each has a switch for a map that draws its own:

Setting	Default	What it does	Reaches
hotbarSlots	9	how many hotbar slots are drawn, 1-9	all three
hotbarBinds	none	extra keys per slot, and what the slot's corner shows instead of its number	all three
hideEmptyHotbarSlots	off	draw only the slots that hold a tool — no boxes over holes	all three
hideHotbar	shown	no hotbar. Number keys and tools.equip keep working — this hides the display, it does not take the tools away	all three
hideHealthBar	shown	no health bar or numbers. The death notice stays	published game only
hideNameplates	shown	no floating usernames over other players	published game only
mouseWheel	nothing	what the mouse wheel does: zoom the camera, or switch tools. See The gameplay camera	all three
mouseWheelNoItem	off	adds one "no item" stop to the wheel's rotation, at the wrap: …8, 9, no item, 1…	all three
mouseWheelIgnoreEmpty	on	skip hotbar slots with nothing in them. Off makes every slot a stop, gaps included	all three

The last two only do anything while mouseWheel is set to switch tools, and Switching tools has the four rotations they produce side by side.

hotbarBinds gives a slot extra keys and its own key-cap label — the number keys always keep working, a bind only adds ways in. Each entry names a 0-based slot, the keys that should equip it (spelled the way scripts spell them: 'c', 'x', 'arrowup'), and an optional label of up to four characters for the slot's corner. Several keys may point at one slot, and digits cannot be re-bound. A bind takes its key over: the engine's own command on it stops firing — V no longer toggles the camera, E no longer boards a vehicle, Backspace no longer drops the tool — which is what a builder game re-keying to Z X C V wants. Those three commands are also each player's own to re-key (Settings, on their device), and a bind captures whichever key a command was moved to. Movement keys (WASD, Space, Shift) keep moving either way. A custom-bound key reaches its slot even past hotbarSlots — naming a slot is more deliberate than the display count is.

"hotbarBinds": [
  { "slot": 8, "keys": ["c", "x"], "label": "C" }
]

Slot 8 is the key marked 9; with this it also equips on C or X, and the slot's corner reads C.

Scripts can read and replace the binds at runtime with tools.getHotbarBinds and tools.setHotbarBinds — re-keying the bar mid-game, with every player's keyboard and hotbar updating at once and late joiners getting the current binds. See the tools API reference.

The engine command keys themselves — camera toggle, interact, drop tool — are each player's own to re-key in their Settings, and a map may override that where its control scheme depends on a key: gameSettings.commandKeys forces a command onto specific keys or disables it outright (null), and input.setCommandKeys / clearCommandKeys / getCommandKeys do the same from a script at runtime.

"commandKeys": { "interact": ["f"], "toggleCamera": null }

Interact is F for everyone in this map and there is no camera toggle at all. Use it sparingly: players re-key commands for reach and accessibility, so take the choice away only where the scheme genuinely needs the key. The built-in prompts always name whichever key actually works, a disabled interact draws no prompt, and hotbarBinds capture their keys above even a forced command. The precedence, highest first: a hotbar bind on the key, the map's commandKeys, the player's Settings, the default.

hotbarSlots is worth setting the moment a map has fewer than nine tools: three tools in a nine-slot bar is six empty boxes telling the player they are missing something.

hideNameplates combines with each player's own Settings toggle — either one off means off. The player's choice is about their screen; the map's is about its world (an anonymous shooter, a hide-and-seek round).

The last two reach the published game only because that is the only place the thing they hide exists: a standalone build and the play-test draw neither the multiplayer health bar nor other players' names.

Raycasts and trigger zones

Setting	Default	What it does	Reaches
queriesHitTriggers	on	whether a script's physics.raycast / raycastAll / sphereCast counts a trigger collider as a hit	all three

A cast hits triggers by default, so asking what your crosshair is over finds a zone as readily as a wall. That is the standard default, and what a cast written elsewhere will expect.

Most of the time the decision belongs to the individual cast rather than the whole map, and every cast can make it: pass 'ignore' as the last argument and the ray flies through every trigger, 'collide' and it hits them even on a map that turned this off.

// a shot: an invisible zone must not stop it
const hit = this.physics.raycast(from, dir, 80, -1, undefined, 'ignore')

Reach for the map-wide setting only when nearly every cast in the map wants the same answer — a shooter where no weapon should ever stop on a zone. Leaving it on and marking the few casts that care is usually clearer, because the reason lives next to the cast.

The void

Setting	Where	Default	What it does	Reaches
killY	Scene Settings	-50	fall below this Y and die	all three

Per map, because how deep a world goes is a fact about its geometry. A mining map with caves at -200 lowers it and nothing else changes; a surface map beside it keeps -50. Setting it very deep effectively removes the void.

This is the setting to reach for the first time a player dies walking through your own basement.

Two things that live on an entity instead

Neither of these is in a settings window, because each belongs to one object rather than to the game or the place. Both reach all three runtimes.

	Where	Covered in
gripScale	each tool entity	Multiplayer scripting, with grip offset and rotation
distance / heightOffset / shoulderOffset	the main camera entity	The gameplay camera — how close the camera sits and which shoulder it looks over

Setting them from a script

The settings windows are the usual way, and the AI editor writes them through setSceneSettings, which routes each key to the right bucket for you. Scripts read the effects rather than the settings: a script that wants a different respawn delay for one player is describing gameplay, and belongs in that script.