BC-0207 · TROUBLESHOOTING
Editorial review 2026-09-26
Roblox Build Prompt Is Too Complex
Reduce an over-complex request by finding a smaller interaction that can actually be tested from start to result. Splitting the text into shorter messages is not enough if each fragment depends on several unbuilt systems. Keep a closed playable loop and defer the dependencies that are unnecessary for its first test.
Symptom
The requested systems depend on one another so extensively that no result can be meaningfully tested.
Immediate action
Identify a start-to-result interaction and the dependencies it genuinely needs.
Diagnostic branches
- A feature depends on an unbuilt optional economy or catalog.
- Defer that dependency and state a legitimate prototype starting condition.
- A shortened message still leaves its result unreachable.
- Change the dependency boundary rather than only shortening the text.
- The current slice produces a complete observable interaction.
- Inspect it before adding the next connected system.
- A dependency requires an unverified capability.
- Keep it explicitly unresolved or use an appropriate inspected implementation workflow.
Least-destructive change
Remove optional dependencies while preserving a complete testable player interaction.
Retest
- The slice has an attainable starting state and a visible result.
- No required action silently relies on deferred work.
- The next addition states its boundary and preservation checks.
Escalation
If no useful slice avoids an unverified capability, treat that as a scope decision rather than proof that more prompts will make it supported.
Working notes
List what each requested feature needs before it can work. A delivery reward may need a collectible, a carrying state, a destination and visible acknowledgement. A shop that spends that reward adds another dependency. These are design relationships, not evidence of a particular internal implementation.
Find the smallest useful vertical slice through those relationships. A player can pick up an object, reach a destination and receive a local completion cue without a persistent economy or a large upgrade catalog. The test should demonstrate a complete interaction, not a screen full of disconnected unfinished systems.
When the proposed slice still depends on a deferred feature, revise its temporary scope explicitly. A route that requires buying a tool cannot be tested if the shop is postponed and there is no other authored access. Choose a legitimate simple starting condition for this prototype, with no claim that it is a production economy or a saved account entitlement.
Add the next dependency only after the current loop can be inspected. Record what that addition changes at the boundary: what input it receives, what visible output another step needs, and what working path must survive. Do not convert the staged plan into a promise that a complex feature is supported merely because it has been split up.
Examples
- Closed slice: retrieve a parcel, carry it to the marked desk and show delivery feedback. Defer a purchasable vehicle and session-spanning reputation because neither is needed to observe that delivery relationship.
- Broken decomposition: ask for the locked workshop first, then postpone the only key source indefinitely. The scene exists, but the meaningful workshop action remains untestable; include an explicit prototype entry condition instead.
- Dependency cut: required action / needed starting state / visible result / downstream feature deferred / preserved working route. Unknown platform capabilities stay unknown after the cut.