Module 12 · Modules, persistence, and the capstone
Organizing server, shared, and client code
Place authoritative services, shared contracts, and local controllers where their audience can access them.
What you will learn
- Choose server, shared, and client containers
- Avoid _G and hidden shared state
- shared module
- Code intentionally accessible to both server and client without containing secrets.
- controller
- A component coordinating one focused area of input or presentation.
Loading saved progress…
Understand
Read the idea and follow a worked example.
Why this matters
Coin Quest becomes maintainable when file location communicates trust and responsibility before someone reads the source.
The mental model
ServerScriptService holds authoritative bootstrap and services. ReplicatedStorage holds safe shared types, constants, and remotes. StarterPlayerScripts or PlayerGui holds client controllers.
Do not put secrets in replicated code and do not use _G to connect unrelated modules. Pass dependencies through explicit APIs.
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.
local is read as “local”: it creates a name that is available only in the current code scope.
{ } is read as “opening and closing braces”: it creates a table value around its entries.
: is read as “colon”: it calls a method with the object supplied as the first receiver value.
= is read as “is assigned”: it evaluates the right side and stores that value in the name on the left.
. is read as “dot”: it accesses a named property or table field.
A tiny example
--!strictlocal ServerScriptService = game:GetService("ServerScriptService")local CoinService = require(ServerScriptService.Services.CoinService)CoinService.Init({ coinValue = 10 })CoinService.Start()Line by line
- 3
The bootstrap requests the authoritative service container.
- 4
It requires a focused server-only module.
- 6
Dependencies are passed explicitly.
- 7
Active behavior starts after initialization.
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
Begin at the first executable statement. Comments and blank lines do not run; a branch chooses which block runs, and a loop may revisit its body.
Line 3: The bootstrap requests the authoritative service container.
Line 4: It requires a focused server-only module.
Line 6: Dependencies are passed explicitly.
Line 7: Active behavior starts after initialization.
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: Every file location communicates who can access it and what responsibility it owns.
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
Where should a DataStore service module live?
Try it
Mark each step after you have tried it.
Common mistake
_G.CoinService = CoinServiceShared globals hide dependencies, permit accidental replacement, and complicate tests. Require modules and pass dependencies explicitly.
Checkpoint
Submit once you have considered every question. Retries are unlimited.
Recap
- Location communicates trust and audience.
- Replicated code cannot contain secrets.
- Explicit module dependencies replace global state.
Next: Next, you will add careful server-only persistence with defaults and versions.
Studio Companion
Not connected
Connect once. Compatible challenges will prepare automatically as you reach them.