Cooldowns and rate limiting

Even well-formed Coin Quest requests can be sent far more often than the game design allows.

Store the last accepted time on the server, keyed by Player. Compare the server clock with that value before doing expensive or consequential work.

Update the timestamp at the point your policy defines, and clear player keys during lifecycle cleanup.

--!strict asks Studio to check your code for type mistakes. It is an instruction for the editor and produces no Output message.

print(...) calls the built-in print function. Put the values to show inside its parentheses; separate multiple values with commas. Read the result in Studio's Output panel.

local is read as “local”: it creates a name that is available only in the current code scope.

if is read as “if”: it starts a decision by evaluating a condition.

then is read as “then”: it marks the body that can run when the condition is truthy.

end is read as “end”: it closes a block such as a decision, loop, or function.

return is read as “return”: it ends the current function call and sends a value to its caller.

{ } is read as “opening and closing braces”: it creates a table value around its entries.

Read one statement at a time: name the value being read, what the operation does, and where its result goes. Keep identifiers exactly as written so you can find them again in the code.

Pause at calls, conditions, and loops. Explain when the body runs before moving to the next statement; use the line notes above when a symbol is unfamiliar.

Start with the statements outside function bodies. A function definition creates a callable value; its body runs when a call, event, or scheduled task reaches it.

Trace the arguments at each call and the branch or loop inside that call. Return to the caller when the function returns. For an event, use the action named in Try it to trigger the callback.

Line 3: The policy duration is named with its unit.

Line 4: Timestamps are separate for each Player.

Line 7: The server clock supplies current elapsed time.

Line 8: The previous timestamp may be absent.

Line 9: Too-small elapsed time is rejected.

Line 13: An accepted attempt updates server state.

Before running, identify the starting values and any existing Studio objects this example needs. List what you expect to change.

After your practice change, check this result: Each player has independent bounded request timing and cleanup.

Reading or printing a value leaves it unchanged. Look for assignments, calls that change state, and property updates to explain each change you observe.