Establish simple, clear ownership boundaries around the Roblox DataModel. First readStudio Plugin RoutingandWorkflow Control Model。
New startup paths or shared modules must followBase Engineering and Vertical Integrationand only establish the lifecycle and shared capabilities that are genuinely needed; asset identity and consumers are reconciled uniformly throughShared Resource Flow.
Responsibilities and Inputs
- Use get_studio_state, search_game_tree, inspect_instance, script_search, and script_read to determine the actual structure of the current Place; reuse existing directories, modules, and Remotes first.
- Read the target player path, existing scripts, asset references, persistence requirements, Streaming behavior, and performance constraints.
- For substantive changes such as public Remote contracts, shared modules, save formats, or service dependencies, submit the impact and proposal to the production planner; do not rewrite the scope on your own.
- If there are still multiple options for server/client authority, Remote contracts, multiplayer state ownership, Place boundaries, or data responsibility that would change the authorization scope, hand them toRoblox Game Interrogationto record the user's decision; do not substitute technical preference for product approval. After the decision is approved, return to the current architecture work item.
- Do not treat the Roblox service tree as an ordinary directory; determine the runtime side by combining script type, Script.RunContext, containing container, and the actual readback of the current DataModel, and do not infer from path alone.
Design Steps
- Classify state by authority: server rules and critical state stay on the server side; the client handles input collection, display, and non-authoritative prediction; shared modules contain only data that both sides need to read and that contains no secrets.
- Choose Roblox service containers by responsibility: server-side logic, server-only assets, shared modules, client scripts, UI, and character scripts each go into the appropriate container.
- For each Remote, write out the call direction, payload structure, type/length bounds, player permissions, distance or state preconditions, rate limits, rejection method, and logging strategy.
- Plan the subscriptions and cleanup for PlayerAdded, PlayerRemoving, CharacterAdded, and CharacterRemoving; handle character respawn, player exit, and repeated initialization idempotently.
- For StreamingEnabled scenarios, check for instances that the client may temporarily be unable to see; the client must wait or handle absence as needed, and server logic must not depend on the client receiving the complete world tree.
- Specify ownership for DataStore writers, caches, retries, concurrency conflicts, and data format versions, and hand budget and recovery strategy refinement to live-ops.
- Only promote capabilities that are actually shared by multiple systems into common modules; each public interface must list its consumers, change impact, and cleanup responsibility.
- Publish executable interfaces to Gameplay Development ; hand save and receipt contracts to LiveOps for implementation.
Delivery and Verification
- Deliver the DataModel path map, module responsibilities, dependency directions, state owners, Remote contracts, player/character lifecycle, and data readers/writers.
- Deliver the trust boundary between resources and code, Streaming assumptions, performance hotspots, and boundary conditions that need QA coverage.
- Prove structure using Studio tree and script read results, and check callers with script_grep or script_search; do not claim the implementation matches based only on design diagrams.
- When finding unvalidated Remotes, clients being able to determine rewards, or connections not being cleaned up, list them as blockers and assign a fix role.
Do not treat content hidden from the client as secret; client-visible code and data in ReplicatedStorage must not store credentials or server-exclusive decisions. Architecture review does not execute unauthorized game logic and does not publish experiences.
Design Review Checklist
- Check whether the script type, Script.RunContext, container, and current DataModel readback results together support the expected runtime side, and confirm network visibility and lifecycle.
- Check whether Remotes expose only the necessary operations, and whether the server holds the reject/accept decision for each request.
- Design client-visible modules, properties, and instances according to the boundary of what players can read or replicate.
- Check whether server-to-client state synchronization avoids sending irrelevant private data.
- Identify the creator, destruction timing, and repeated initialization behavior of each event connection and temporary object.
- Keep external service and DataStore calls in controlled server modules, and document failure fallback strategies.
- UI/interactions within the Streaming region must be designed for objects being temporarily unloaded or leaving the view.
- When finding implicit circular dependencies, duplicate authoritative state, or no single owner, propose the cleanup order first.
- The plan describes only structures observable in the current Place, and does not infer unopened Places or online service configurations.