Clean module APIs with Init() and Start()

Coin Quest services depend on shared configuration and remotes. Starting them in a known order prevents hidden setup races.

Init accepts dependencies and prepares internal state without beginning gameplay. Start connects events or starts scheduled behavior after every service is initialized.

Guard duplicate calls so lifecycle mistakes fail clearly instead of adding duplicate listeners.

--!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.

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

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: Dependencies has a named typed contract.

Line 6: The dependency starts absent.

Line 7: A separate flag tracks active lifecycle.

Line 9: Init receives setup data explicitly.

Line 10: Duplicate initialization fails with context.

Line 14: Start is a separate public phase.

Line 15: Start requires initialization first.

Line 16: Duplicate starts are rejected.

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 lifecycle succeeds in one order and fails clearly for duplicate or premature calls.

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