Consider an illustrative request: 'Make a candy Obby.' It names a theme but says nothing about what a player does, how failure works, or when the game ends. The next useful step is not adding more decorations; it is choosing an observable loop. This is a writing example, not a published customer game or a Studio-tested case study.
Split the request into four decisions
Goal: reach a visible finish line. Route: teach a simple jump, introduce moving platforms, then combine them with hazards. Recovery: respawn at the last checkpoint after failure. Reward: grant coins once at the finish. During plan review, the creator can change route length or hazard placement. After generating a Draft, open the exact Build in Studio and check each behavior. If a checkpoint fails, request that specific change instead of rewriting the whole game idea.
The revised one-sentence brief
Make a candy Roblox Obby with a three-part route, checkpoints before hard jumps, optional coins, and a one-time finish reward. Show the plan before building; I will test respawn and rewards in Studio.
Take this with you
- Always retain the previous usable Build.
- Runtime evidence belongs to its current Build and cannot be carried forward.
- Write unknown as unknown—never paint it passed.