Module 9 · Events and scheduling
Mini-project: A checkpoint
Validate touches, debounce by player, and release temporary state after a bounded delay.
What you will learn
- Validate a touched character
- Debounce repeated signals per player
- Schedule bounded debounce cleanup
- debounce
- A guard preventing repeated handling during a short active interval.
- per-player state
- State keyed separately for each connected player.
Loading saved progress…
Understand
Read the idea and follow a worked example.
Why this matters
A character has many body parts, so one checkpoint contact can fire repeatedly. Coin Quest should award or announce the checkpoint once per intentional touch window.
The mental model
Validate the touched Part's parent as a connected character, then check a dictionary keyed by Player. Mark before doing work and clear after a short delay.
This reduces duplicate event handling; it is not a security boundary for rewards, which remain server-owned.
New words and symbols
--!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.
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.
== is read as “equals equals”: it compares two values and produces a boolean.
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.
A tiny example
--!strictlocal Players = game:GetService("Players")local checkpoint = script.Parentassert(checkpoint:IsA("BasePart"), "Controller must be under a BasePart")local touchingPlayers: { [Player]: boolean } = {}checkpoint.Touched:Connect(function(otherPart: BasePart) local character = otherPart.Parent local player = character and Players:GetPlayerFromCharacter(character) if player == nil or touchingPlayers[player] then return end touchingPlayers[player] = true print(player.Name, "reached a checkpoint") task.delay(1, function() touchingPlayers[player] = nil end)end)Line by line
- 3
Players validates candidate characters.
- 4
The selected target is the Script's parent.
- 7
The debounce dictionary tracks players independently.
- 10
The event supplies a contacting Part.
- 12
The combined guard rejects non-players and active debounces.
- 16
State is marked before the checkpoint work.
- 18
Cleanup is scheduled after a bounded second.
- 19
Removing the key permits a later intentional touch.
Read the code aloud
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.
Execution trace
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: Players validates candidate characters.
Line 4: The selected target is the Script's parent.
Line 7: The debounce dictionary tracks players independently.
Line 10: The event supplies a contacting Part.
Line 12: The combined guard rejects non-players and active debounces.
Line 16: State is marked before the checkpoint work.
Line 18: Cleanup is scheduled after a bounded second.
Line 19: Removing the key permits a later intentional touch.
State before and after
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: The source structure validates identity and rapid contacts do not produce duplicate handling.
Reading or printing a value leaves it unchanged. Look for assignments, calls that change state, and property updates to explain each change you observe.
Predict before running
What does a second immediate touch from the same player do?
Try it
Mark each step after you have tried it.
Common mistake
A single global boolean blocks every player when one touches the checkpoint. Key debounce state by Player so users do not interfere with each other.
Checkpoint
Submit once you have considered every question. Retries are unlimited.
Recap
- Validate event parameters before use.
- Per-player debounces isolate users.
- Bounded cleanup permits later interactions.
Next: Module 10 crosses the client-server boundary and treats every client request as untrusted.
Studio challenge
A checkpoint
Checks are formative feedback, not cheat-proof certification. You can finish this lesson without the plugin.
- Target
- Workspace/LearningLuau/Checkpoint/CheckpointController
- Check mode
- source structure
Challenge state: idle
Studio Companion
Not connected
Connect once. Compatible challenges will prepare automatically as you reach them.