The canonical prompt for a Roblox game — complete architecture

What this prompt produces

A complete, publishable Roblox game in the chosen genre (obby / tycoon / simulator): full file architecture, game state entirely server-side, progress saving with error handling, one developer product and one game pass, touch controls, and a Studio publishing checklist.

You are a senior Roblox developer with front-page games. You write Luau with --!strict, never trust the client, and know Roblox's moderation and monetization rules by heart.

Build a complete game: [GENRE: obby / tycoon / simulator] themed [THEME]. Target audience: [AGE]. First player satisfaction: within 3 minutes.

GENERATE THE FULL ARCHITECTURE (every file complete, paste-ready):
ServerScriptService/ — game logic, server-side validation of EVERY player action, a data service (DataStore: pcall + 3 retries + session lock, save on progress/exit/every 120s), a monetization service (idempotent ProcessReceipt!)
ReplicatedStorage/ — Remotes (typed payloads), Config.lua (all balance numbers as data, not code)
StarterPlayerScripts/ — HUD, a loading screen shown until data is confirmed loaded

HARD RULES:
- --!strict in every file.
- The client NEVER saves progress, counts currency, or decides rewards. The server validates: distances, stage order, costs, cooldowns (server clock).
- Every DataStore call in a pcall with failure handling — lost progress is the death of a game (1★ ratings).
- ProcessReceipt: check the purchase history first, then grant, and return the correct Enum in EVERY branch.
- Full touch controls — ~75% of Roblox players are on mobile.
- Difficulty/economy curve: first reward < 30s, first decision < 3 min.

OUTPUT FORMAT: each file as a separate code block with the exact path in the header. At the end: a Studio configuration checklist (product IDs, DataStore API access, a 2-player test procedure).

BEFORE ANSWERING, CHECK: no game state is authoritative on the client; every pcall has an error branch; the game is playable on mobile.

Why this prompt works

• ✓Forcing a file architecture turns 'make a game' into a checkable engineering task.
• ✓The 'client decides nothing' rule closes an entire class of exploits that kill young games.
• ✓An idempotent ProcessReceipt guards against the most common Robux-losing bug.
• ✓Requiring a first reward < 30s reflects the real physics of retention on Roblox.

What weaker prompts get wrong

• ✕Currency logic on the client — exploited within hours of launch.
• ✕DataStore without pcall — random wiping of player progress.
• ✕A game designed for keyboard — mobile players physically can't play.
• ✕Balance hardcoded in the logic instead of Config — every change means digging through code.