Skip to main content
Glama

scene_set_camera

Destructive

Sets play camera distance, field of view, a locked fixed view, and player turn limits in a copy of the save, so side-view and top-down games keep a stable angle.

Instructions

Change how far the play camera stands from the character, its field of view, and whether the player can turn it, in a copy of a save. fixedView {yaw, pitch, ignoreCollision} locks the view (the 2.5D camera of the editor, 2.5D镜头): the camera looks from one horizontal angle (yaw 0 looks towards +z from the -z side, so that A and D walk along x; 90 turns it a quarter round) at one pitch (positive looks down: 20 to 25 for a side view, 50 to 60 for a view from above), the player cannot turn it with the mouse, the zoom is held at the distance, and with ignoreCollision (on unless switched off) the camera does not jump close when a wall or an invisible wall comes between it and the character. Every game that is built for one direction of view (a side-scroller, an arena seen from above, a lane) needs this: without it the first movement of the mouse turns the camera and D no longer walks along the lane. Read from a template switched to that mode by hand in the editor on 2026-10-13 and written the same way; seen in play that day (examples/hazards/hazards_fixed_view.json: the same mouse movements that swing the free camera right round leave the fixed view where it is; hazards_free_view.json is the comparison). Without fixedView: The picture shows about 2distancetan(fieldOfView/2) metres of height at the character and 16/9 of that across (at 45 degrees: 14 m shows about 20.6 m across, 18 m about 26.5 m; in a side-view game whatever stands further from the character than half of that is off the screen): 6 m at 45 degrees is a close shot (5 m tall, large buildings are cut off), 14 m shows about 11.6 m and whole buildings with sky above them. yawRange and pitchRange ([min, max] in degrees) limit how far the player can turn the camera; a new template allows everything (-180..180, -89..89). The camera starts behind the character, wherever the character faces: set the facing with scene_set_spawn (rotation [0,0,0] faces +z, so the camera looks from the -z side and A and D walk along x; turned 90 degrees, D no longer walks along x). yawRange did not fix the starting direction in playtests, and a yawRange of [0, 0] is dropped when the editor saves; pitchRange [55, 55] does give a top-down view. The camera template must already exist (create it once in the editor). Writes a new .gil in the workspace and returns its path; the official save is not touched.

Input Schema

NameRequiredDescriptionDefault
nameNo
mapPathNo
distanceNo
yawRangeNo
fixedViewNo
outputNameNo
pitchRangeNo
fieldOfViewNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the destructiveHint=true annotation: it discloses that a new .gil is written to the workspace, that the official save is untouched, that the returned value is its path, that yawRange [0,0] is dropped on save, and that yawRange did not fix starting direction in playtests. These are non-obvious engine behaviors an agent could not infer elsewhere.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action, but the body sprawls with editor provenance ('Read from a template switched to that mode by hand in the editor on 2026-10-13'), dated notes, and example filenames that do not help an agent invoke the tool. Several sentences could be compressed without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter mutation with nested objects and no output schema, the description supplies prerequisites, side effects, return value, and the semantics of the risky fixedView mode. Only the naming/path parameters are left to the schema, so it is nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage the description carries the burden, and it does so for most parameters: distance is tied to a metres-of-visible-height formula with worked examples, fieldOfView to frame height, fixedView's yaw/pitch/ignoreCollision each get meaning plus recommended values (20-25 side view, 50-60 top-down), and both ranges get units and failure notes. name, mapPath, and outputName are left unexplained, keeping it short of a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Change how far the play camera stands from the character, its field of view, and whether the player can turn it, in a copy of a save') and clearly separates itself from siblings like scene_list_cameras and scene_set_spawn by naming the latter for facing setup. An agent can identify the tool without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete when-to-use trigger ('Every game that is built for one direction of view ... needs this') and explains the failure mode without it. It also states a prerequisite ('The camera template must already exist'), but never routes to alternatives such as scene_list_cameras to inspect existing cameras or when to prefer a plain free camera over fixedView.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools