| name | roblox-luau-architecture |
| description | Design, inspect, and refactor Roblox Luau game architecture. Use for ModuleScript/service boundaries, client-server flow, RemoteEvents/RemoteFunctions, ReplicatedStorage organization, reusable systems, script placement, and safe Studio MCP code-edit workflows. |
Roblox Luau Architecture
Goal
Keep Roblox game code modular, server-authoritative, and easy to extend. Use Roblox Studio MCP to inspect existing scripts before changing architecture.
MCP Workflow
- Start with
list_roblox_studios, set_active_studio if needed, and get_studio_state.
- Locate code with
script_search or script_grep.
- Read relevant scripts with
script_read before editing.
- Apply edits with
multi_edit.
- Playtest with
start_stop_play.
- Check
get_console_output for regressions.
Placement Rules
- Put authoritative game logic in
ServerScriptService or server-owned modules.
- Put shared constants, type definitions, remotes, and pure shared helpers in
ReplicatedStorage.
- Put player input, camera, local-only UI, and visual prediction in client scripts.
- Keep workspace scripts rare and intentional; prefer service-style scripts that manage tagged instances or configured folders.
- Avoid scattering duplicated constants across client and server.
Remote Boundaries
- Treat every client remote payload as untrusted.
- Prefer narrow remotes with explicit action names and typed payload checks.
- Rate-limit player-triggered remotes that can affect economy, inventory, combat, or placement.
- Use RemoteFunctions sparingly; avoid long-yielding server calls from the client.
- Never let the client decide currency, inventory, ownership, damage, quest completion, or purchase grants.
Module Pattern
Use modules for:
- Services with
Init and Start style lifecycle.
- Data access wrappers.
- Economy calculations.
- Reward tables and balancing constants.
- UI controllers on the client.
- Shared utility functions that are deterministic and side-effect-light.
Keep modules small enough that another system can depend on them without importing unrelated behavior.
Prefer Deep Modules
Aim for deep modules: a lot of behavior behind a small, stable interface. A shallow module — where the interface is nearly as complex as its implementation — earns its keep only if it hides real complexity.
- Interface = everything a caller must know: the function signature plus invariants, ordering, error modes, and which side (client/server) may call it. In Roblox, a remote's contract is part of its interface.
- Deletion test: imagine deleting a module. If complexity vanishes, it was a pass-through — inline it. If the same complexity reappears across several call sites, it was earning its keep — keep it and deepen it.
- Locality: put related behavior and its valuable-state rules in one module so a change, a bug, or the knowledge to reason about it lives in one place — not scattered across a LocalScript, a server Script, and three constants files.
- One adapter satisfying an interface is a hypothetical seam; two is a real one. Don't build indirection for a single implementation.
Good seams get names from the game's own vocabulary (the "coin economy service", the "quest tracker"), not generic ones ("Handler", "Manager").
Refactor Output
When proposing or making architecture changes, include:
- Current script locations and responsibilities.
- Proposed module/service boundaries.
- Remote contract changes.
- Migration steps.
- Playtest and console checks.
Next
Slice the architecture work with roblox-to-issues so it lands one safe change at a time, and verify each with roblox-playtest-qa. For valuable-state modules, review the trust boundary with roblox-security-economy; for cleanup of existing debt, use roblox-code-maintenance-refactor.
