blushneybusiness-glitch/roblox-omniskills/rbx-architecture

rbx-architecture

When to load

Every new game skeleton, every "where does this go" question, every feature that crosses the client/server line, and every rbx-comprehend pass over an unfamiliar place. rbx-frameworks sits on top of this foundation; this file is true no matter which framework wins.

Container law

RunContext bends container rules: a Script with RunContext = Client runs on every client from anywhere (workspace-local spinners, ambient FX); RunContext = Server runs server-side from any container; the default Legacy lets the container decide. LocalScript has no RunContext — client containers only, always.

The client/server split

• The server owns every gameplay-relevant value: currency, health, inventory, cooldowns,

odds. Clients render, predict, and request.

• A client may ask ("use ability 2 on target X"); the server computes the result. A damage

or price number arriving over a remote is already an exploit — payload rules in rbx-net-remotes.

• Client-made world changes stay local unless the server handed that instance's physics to

the client via network ownership. "Only I can see it" is the replication model working.

• PlayerGui, Backpack, and PlayerScripts are per-player clones — editing the StarterGui

template at runtime does nothing for players already spawned.

The seven foundational patterns

1. Thin bootstrapper. One Main Script server-side, one client-side; each requires and

boots modules and stays under ~20 lines. All logic lives in ModuleScripts.

1. Two-phase startup. Every module gets init() (wire references, no cross-module calls

yet) then start() (begin behavior). Startup-order bugs die here.

1. Centralized remotes. One server script builds every RemoteEvent/RemoteFunction into

ReplicatedStorage/Remotes before any client can fire — never scattered Instance.new across feature scripts.

1. One shared Constants + Types pair. Both sides compile against the same numbers and

shapes from ReplicatedStorage; no magic values duplicated per script.

1. Server owns state; clients mirror it. Mechanics of the mirror: rbx-state-replication.
2. Configure, then parent. Set every property first, .Parent last.

Instance.new("Part", workspace) replicates a half-built part and yields mid-construction.

1. Events over polling. .Died, GetPropertyChangedSignal, CollectionService tags —

never a while true do task.wait(0.1) scan doing an event's job.

Sharp edges

• CRITICAL — Server rule logic in ReplicatedStorage: exploiters decompile it and reverse

your validation and drop odds. Fix: anything with rules, odds, or secrets moves to ServerScriptService/ServerStorage; ReplicatedStorage keeps only what both sides genuinely share.

• CRITICAL — Server applies client-sent numbers (damage, price, quantity). Fix: the

server recomputes from its own state; treat the client's number as a hint at best.

• HIGH — Scripts buried inside Workspace models: exploiter-visible if not server-run,

invisible to audits either way. Fix: one script in ServerScriptService, CollectionService tag to find its model.

• HIGH — RemoteFunction:InvokeClient() from the server: a client that errors or leaves

hangs the server thread forever. Fix: one-way RemoteEvent, or client-initiated invoke.

• MEDIUM — God script: 500+ lines doing data, combat, and UI. Fix: split along

rbx-module-design boundaries; the entry Script goes back to being a bootstrapper.

Load with

rbx-frameworks (which pattern scales past this foundation), rbx-module-design (boundaries inside the skeleton), rbx-state-replication (the sync mechanics), rbx-net-remotes (the remote layer), rbx-comprehend before touching any existing game.