Roblox Luau Scripting Services

Luau scripting is where a Roblox game is won or lost. Art gets players to click. Scripting decides whether they stay, whether the economy holds, and whether a single exploiter can undo months of progression in an afternoon.

We write Luau for a living. This page describes how we approach it, in enough technical detail that you can judge whether we know what we are doing.

Server-authoritative by default

The single most common failure we find in inherited Roblox codebases is trusting the client. It usually looks harmless: a LocalScript awards currency when a player touches a coin, or validates whether a purchase is affordable before firing a remote. Both are exploitable in minutes.

Our rule is that the client is an input device and a renderer. It reports intent. The server decides what happens. Every remote event validates its arguments, checks that the requesting player is actually entitled to the action, and rate-limits callers to prevent flooding.

-- The server decides. The client only asks.
local function onPurchaseRequested(player, itemId)
    if type(itemId) ~= "string" then return end          -- validate shape
    local item = Catalogue[itemId]
    if not item then return end                          -- validate existence
    local balance = Economy.getBalance(player)           -- server-held state
    if balance < item.price then return end              -- validate affordability
    Economy.debit(player, item.price)
    Inventory.grant(player, itemId)
end

Nothing in that flow believes anything the client said beyond which item it wanted. Our client-server architecture guide covers the full model in depth.

Data persistence that survives production

DataStores are the least forgiving part of the platform, and the part most likely to quietly destroy a game. The failure modes that matter are not exotic:

• Duplicate sessions. A player joining two servers at once, with both writing the same key, silently discards one side's progress. Session locking prevents it.
• Unhandled write failures. DataStore calls can and do fail. A save that is not wrapped, retried, and logged is a save that will eventually be lost.
• Shutdown races. Without BindToClose, a server shutting down takes unsaved progress with it.
• Unversioned schemas. Changing your data shape without a migration path corrupts every existing player's save.

We design the schema and its migration path before writing the systems that depend on it, because retrofitting versioning onto live player data is considerably more expensive than planning it.

Performance as an architectural concern

Most Roblox performance problems are structural, not micro-optimisations. Polling loops that should be event-driven, per-frame work that should be cached, and unbounded instance creation account for the majority of what we find.

We profile before changing anything. The MicroProfiler and Script Performance panel tell you where frame time is actually going, which is regularly not where the team assumed. Our performance optimisation guide documents the specific techniques, and it is the most-read page on this site by a wide margin.

Code you can hand to someone else

A codebase that only its author can maintain is a liability you are paying for. We organise systems into ModuleScripts with explicit responsibilities and narrow interfaces, keep gameplay logic decoupled from Roblox service calls where practical, and comment the decisions that are not obvious from the code.

The practical test: if you brought in a new developer tomorrow, could they add a feature without reverse-engineering the whole project first? That is the standard we build to, and it is the standard you should hold any developer to.

Monetisation systems

Developer Products, Game Passes, and subscriptions each have different receipt-handling and failure semantics, and getting ProcessReceipt wrong means either double-granting items or taking payment without delivering. We implement purchase flows to be idempotent and auditable. Our monetisation guide covers the implementation patterns in detail.