If you’re coming from a client-only background (Unity, Unreal, web apps, etc.), it’s natural to ask:
Why do I need a server at all? Can’t the game just do this itself?
For small prototypes, the answer is often “yes.” For live games with progression, rewards, purchases, or leaderboards, the answer quickly becomes “no”, and here’s why:
The Core Problem: Trust #
A game client runs on the player’s device. That means the player controls it.
They can:
- modify memory
- intercept or replay network calls
- fake events
- patch or replace client code
If the client is responsible for deciding:
- whether a mission was completed
- how many points were earned
- whether a purchase is valid
- whether a reward should be granted
…then those systems are not secure.
What a Server Does #
A server exists to act as an authoritative source of truth.
Authoritative code:
- runs in an environment the player cannot modify
- validates what actually happened
- makes final decisions about permanent game state
In practice, this usually means:
| Action | Responsibility |
|---|---|
| Player input | Client |
| Rendering / UI | Client |
| Game rule validation | Authoritative Code |
| Progression updates | Authoritative Code |
| Rewards & inventory | Authoritative Code |
| Leaderboards | Authoritative Code |
| Purchases | Authoritative Code |
The client requests changes. Authoritative code approves and applies them.
Where Does Authoritative Code Run? #
In many systems, authoritative code runs on your own game server. Elements fully supports a server to server model.
However, Elements also supports another option: Custom Elements.
Do I Always Need My Own Server? #
It is completely optional, and dependent on the architecture of your game.
Elements supports Custom Elements, which are your own server-side applications that run inside Elements itself.
A Custom Element:
- runs in a trusted, server-side environment
- can access Elements systems directly (users, inventory, progress, leaderboards, direct db access)
- executes authoritative logic
- cannot be modified by players
This means you have two valid deployment models:
- External Game Server – your own backend service calls Elements APIs (still authoritative!)
- Custom Elements – your authoritative code runs inside Elements
Many teams use both, especially when their teams are more familiar with modeling the game logic in their preferred game engine (for example, running Unity in headless mode).
A Simple Mental Model #
Think of Elements as both a platform and a runtime:
That authoritative step may live:
- on your own server, or
- inside Elements via a Custom Element
Why Elements Assumes Authority #
Elements manages high‑trust systems:
- digital goods and inventory
- reward issuance
- mission progression
- leaderboards
- scheduling and time‑based content
These systems require:
- protection against duplication
- safe retries (idempotency)
- consistent timekeeping
- validation of events
Those guarantees are only possible when changes are applied by authoritative code.
How This Affects the Rest of the Docs #
When the docs say:
- “server-side”
- “authoritative”
- “safe to retry”
- “idempotent”
They refer to code that runs outside the player’s control — either on your server or inside a Custom Element.
Understanding this mental model will make the rest of the documentation much easier to follow.