Refresh GUIs, the clicker loop, idle income, upgrades, and modules before you start building the world around them.
You built a real game — a clicker with a GUI, idle income, an upgrades shop, and organized modules. That's a complete economy running on the secure pipeline from the data section. One lap around it before we build the world it lives in:
Everything on screen hangs from a ScreenGui in the player's PlayerGui. The recipe is always the same: create it with Instance.new, set its properties, parent it. Frames hold children, TextButtons get clicked, and positions are UDim2.
Where must a GUI live for the player to see it?
The clicker is the whole course in miniature: the button reports clicks with FireServer, the server verifies and awards coins, then sends the new total back with FireClient — and the client's label just mirrors what the server said. Clicks are never trusted; rewards never come from the client.
Idle income is the same loop minus the click: a while true loop with task.wait(1) pays every player, guarded by if coins then. The upgrades shop follows one rule — the server checks the bill. The client sends an intent like "multiplier", the server prices it, verifies the wallet, and only then spends.
Where does the price check happen when a player buys an upgrade?
One giant script gets hard to read fast. ModuleScripts split it up: a file that ends in return, loaded anywhere with require. Every script that requires a module shares the same copy — so config and math live in one obvious place.
Two scripts require the same ModuleScript. What do they get?
Interfaces, economies, and organization are built. Next section, you'll fill the world around them — players, characters, parts, sounds, and smooth movement.