Mini-project: Secure coin collection

Coin collection is the first Coin Quest feature where trusting a client would directly damage shared game state.

The client may request a coin by stable ID. The server resolves that ID in its allowed folder, verifies collectible state and distance, applies a per-player cooldown, and owns the balance update.

A separate client controller receives an approved count for visible feedback. It never chooses the reward.

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

Matching quotes such as "hello" surround a string: a piece of text. The quotation marks tell Luau where the text starts and ends.

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

~= is read as “not equal”: it asks whether two values differ.

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.

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: Shared remotes come from a fixed path.

Line 7: Balances are server-owned state.

Line 11: The handler receives trusted Player identity and unknown payload.

Line 12: Type and size are checked first.

Line 13: The server resolves the coin inside its allowed folder.

Line 16: Server-owned collectible state is required.

Line 17: Server-observed distance bounds the action.

Line 20: A short per-player cooldown limits request frequency.

Line 22: The coin state changes before the reward.

Line 24: Only the approved balance is sent back for display.

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: Only plausible server-validated collection changes the balance, and the client displays approved state.

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