Gameplay implementation should make player actions produce clear results while letting the server decide key rules. Before starting, readStudio Plugin Routing、Control Modeland the architecture deliverables.
Responsibilities and Inputs
- Use search_game_tree, inspect_instance, script_search, script_grep, script_read to locate existing logic, then implement via execute_luau or multi_edit according to the current tool routing.
- First read the player flow, acceptance criteria, state owners, Remote contracts, numeric configs, asset registry, and target place.
- The server owns key rules such as damage, rewards, currency, item grants, cooldowns, and win/loss; client input is only a request or presentation hint.
- Report major rule, public interface, data format, or asset requirement changes to architecture/design first; do not expand task scope during implementation.
- When a rule or multiplayer relationship has a substantive tradeoff that evidence cannot eliminate, hand it toInterrogation Skillto record the user's decision; return to this work item after closure, and do not repeatedly ask about ordinary implementation details.
Implementation Steps
- List the states, triggering events, preconditions, success/failure results, and exit paths, then determine the respective parts the server and client handle.
- For every client request, re-check on the server the player identity, type and size, permissions, current state, distance, cooldown, and rate; safely reject illegal or excessive requests.
- Have the server compute key results and broadcast the required state; the client displays results and must not treat client-sent reward amounts or hit conclusions as fact.
- Make Player and Character event handling safe against duplicate calls; clean up connections, timers, and temporary state when players leave, characters change, or instances are destroyed.
- Handle temporarily invisible objects according to Streaming behavior, and avoid relying on the client always having a complete copy of the world.
- Consume registered asset and animation interfaces; hand feedback events and asset lifecycle to Feedback and Motion, and hand persistence flows to LiveOps。
- When modifying scripts, first read the complete relevant code; use multi_edit's Edit operation, and provide the correct className when creating a script for the first time.
Delivery and Verification
- Deliver the changed tree paths, script responsibilities, Remote inputs and server-side validation, state changes, and failure handling.
- Confirm call chains and ownership through script reading and code search; when runtime behavior is needed, use only the user-authorized Studio Play flow.
- Record console errors, uncovered multiplayer scenarios, Streaming assumptions, and data dependencies; mark NOT_RUN when evidence is insufficient.
- Provide QA with reproduction steps for normal flows, invalid requests, boundary values, exit/respawn, duplicate triggers, and multiplayer contention.
Do not treat NetworkOwnership, client collision, or local UI as security guarantees for key rules. Do not execute Luau, start, or stop Play when beyond the authorized scope.
State and Boundary Checks
- Determine the lifecycle and cleanup responsibility separately for player state, character temporary state, global round state, and persistent state.
- For RemoteEvent/RemoteFunction, specify request and response separately; the server recalculates key results and does not accept the final results declared by the client.
- On each call, check the type, numeric range, string length, instance ownership, distance, cooldown, and current game phase.
- Set up server-side throttling for high-frequency requests; when rejecting invalid messages, avoid excessive logging that causes additional burden.
- Establish cancellation or invalidation checks for asynchronous waits, character respawns, and player departures to prevent old tasks from modifying the new character's state.
- Provide recoverable behavior for targets outside the client's Streaming region, and do not rely on the client always caching instances.
- Cover boundary values with pure rule or configuration tests; when running the game flow, record the actual server/client perspective.
- Multiplayer competition, disconnect-and-rejoin, and concurrent rewards require evidence from a multiplayer environment; single-client results can only prove the single-client path.
- If a new script needs to be created, first confirm the correct service container, class name, execution context, and existing module dependencies.
- When discovering that key logic resides in a LocalScript, first confirm whether it is only presentation; if it is rewards or rules, move ownership back to the server.