Guarded by default
Every remote served through Net.Handle is metered from its first line,
whether or not you asked for it. Rank, schema, and your own checks stack on
top, cheapest first, so a caller flooding one remote is turned away before
anything expensive runs for them.
Only what moved leaves the server
Replication keeps a private copy of what each player last received and diffs against it, so one field deep inside a large table travels alone and a frame that changed nothing sends nothing. State is pushed, never pulled: a client holds what the server decided to send, and the metering algorithm, each player’s allowance, and every line that touches saved data live where no client can read them.
Failures are loud
A critical service that fails to boot refuses players instead of serving a
game quietly missing a system. Data that will not load kicks rather than
opening a session that would overwrite progress. Text that cannot be
filtered comes back as nil, never as the original.
Player data, carried through
Sessions, templates, versioned migrations, and branches. A write reaches a player on any server and never overwrites a session it does not own, and naming a field is all it takes to send it to its owner’s client.
Every lifetime has an owner
Nothing here starts a connection nobody owns. Bags close when a player leaves, when a character is removed, or the instant that character dies, so work stops with the thing it belonged to instead of outliving it.
Adopt as little as you like
Only Lifecycle calls your code. Everything else is a library you call, so
reaching for Twill.Log and nothing else is a legitimate way to use this.
Every dependency is bundled and nothing is built, so it runs the same
whether the place was assembled by hand, synced from files, or generated by
tooling of your own.
local Twill = require("@game/ServerScriptService/Twill")
Twill.Data.Configure({ Store = "PlayerData", Version = 1, Template = { Coins = 0 },})
Twill.Lifecycle.SetPlayerGate(Twill.Data.Gate)Twill.Lifecycle.Start(script.Parent.Services)That is a server which loads player data, boots your services in a defined order, and announces each player once their data exists.
Install and boot
Put both modules in place, configure player data, and watch a service boot. Start here.
Learn the shape
Services on the server, controllers on the client, then data, remotes, replication, and cleanup. Core Guides.
Solve one thing
Practical recipes for the systems most games end up needing, each starting from the problem and naming the trap. Begin with Gate actions by rank.
Read the API
One page per module, with every signature taken from the source and the side it runs on marked on every member. Module reference.