Debugging, testing, and profiling

The final Coin Quest prototype combines many systems. A repeatable debugging process prevents random changes from hiding the actual cause.

Read the error message and first relevant project frame. Reproduce with the smallest inputs, inspect boundaries, and change one factor at a time.

Use multiplayer Studio testing for networking and profile a named region before optimizing code that merely looks expensive.

--!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 “plus equals”: it reads the current value, adds, then stores the result back.

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.

else is read as “else”: it provides the fallback branch.

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

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 calculation has a small typed boundary.

Line 4: A named profile region begins immediately around measured work.

Line 6: The loop is the behavior being isolated.

Line 9: The profile region ends on the normal path.

Line 13: pcall contains this deliberate test boundary.

Line 15: Learner-facing output is safe and concise rather than a raw stack trace.

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: You can reproduce one issue, identify its boundary, and explain what evidence supports the fix.

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