How does an instance server actually work?

robertlabrie

Would love if someone from ZOS would explain (even if that's unlikely). What's going on under the hood? I expect it's a state machine with multiple inputs (maybe some kind of a message bus) a huge logic block tracking the state of all the players in the instance, updating statuses based upon player inputs and then sending the updated state of the world back to the client. If thats the case, is that way perf is so hard to fix in cyrodiil? Too many computations per cycle and no way to parallelize because of the need to finalize the state after each transition? Do other multiplayer games work the same way?

A few of my guild members are into IT/cloud operations and we were discussing this and I figured I'd come and ask. Don't need the whole recipe, just the "how it's made" level explanation would be fun to have.

Drinks_from_Ponds

What you’re describing is actually **pretty close to how most MMO servers work**, just with a few extra layers.

At a high level, most MMOs (ESO included) use a **server-authoritative model**. That means the **server owns the “truth” of the game world**, and the clients mostly send inputs like movement, skill casts, targeting, etc. The server processes those inputs, updates the world state, and sends the results back to everyone nearby.

So the flow is roughly:

1. **Client sends inputs**

* Move
* Cast skill
* Attack target
* Use item

2. **Server simulation tick**

* The server runs the game simulation in small time steps (ticks).
* It validates inputs and applies game logic.

3. **World state update**

* Positions change
* Damage is applied
* buffs/debuffs update
* AI acts

4. **State broadcast**

* The updated world state is sent to nearby players.

So conceptually yes — you can think of it as **a big state machine advancing the world simulation every tick**.

---

### What an “instance” really is

An instance is basically just **a separate copy of the game world simulation running on a server**.

For example:

* Dungeon instance → server spins up a simulation for your group
* Trial instance → another simulation
* Another group entering → new instance

MMOs do this so players aren’t competing over the same enemies or quests.

Under the hood it’s typically:

```
Game Server
├── Instance #123 (Dungeon)
├── Instance #124 (Dungeon)
├── Instance #125 (Trial)
└── Zone Simulation (Open world)
```

Each instance tracks:

* player states
* NPC states
* combat events
* timers
* scripted mechanics

---

### Why Cyrodiil is so hard

Cyrodiil is difficult for a few reasons that don’t exist in small instances:

**1. Player count explosion**

Instead of:

```
12 players in dungeon
```

you get:

```
100–300+ players
siege weapons
NPC guards
projectiles
AOE abilities
```

All interacting in the **same simulation tick**.

---

**2. Combat interactions scale badly**

Many MMO combat systems are **O(N²)** style problems.

Example:

```
50 players casting AOEs
Each ability checks:
distance
line of sight
buffs
debuffs
mitigation
procs
```

That becomes thousands of calculations per tick.

---

**3. Synchronization limits parallelism**

You were also right about the parallelization issue.

Because the server must maintain **a single authoritative state**, it can’t always freely split things across threads. Many systems must be processed in order so the final world state is deterministic.

For example:

```
Player A stuns Player B
Player B tries to dodge
```

The server must decide **which happened first**.

That ordering requirement can limit how much of the simulation can run in parallel.

---

### Why instanced dungeons run better

Instanced content has advantages:

* small player counts
* limited AI
* fewer combat calculations
* controlled scripts

So performance is much easier to maintain.

---

### Do other multiplayer games work this way?

Yes — **almost all large multiplayer games use this same model**:

* World of Warcraft
* Final Fantasy XIV
* Destiny
* Battlefield servers
* most competitive shooters

The main differences are:

| Game type | Architecture |
|

---

|

---

|
| MMO | server authoritative + world simulation |
| FPS | server authoritative but smaller matches |
| RTS | deterministic lockstep sometimes |
| peer-to-peer games | clients share simulation |

But MMO combat systems tend to be **far more simulation heavy**, which is why large-scale PvP (like Cyrodiil) is historically hard for every MMO.

---

### TL;DR

You’re basically right:

* MMO servers run **authoritative world simulations**
* Instances are **separate simulations of a zone**
* The server advances the world **in ticks**
* Inputs come from players → server computes new state → broadcasts updates

And Cyrodiil is difficult because **huge player counts + heavy combat calculations + synchronization constraints** make scaling the simulation very hard.

robertlabrie

and in a huge zone like cyrodiil they can't break it up, so all the combat has to eval on every tick even if there are multiple fights that couldn't possibly interact with each other. That aligns with my mental model pretty well, thanks Ponds.

In cyro I guess one thing they could do would be to make the gates and bridges transition areas where passing through them moves you to another instance but I think what's happening there is that your client is paused, your state is written to an RDBMS or some other stateful store then gets reloaded into the new instance. That would be action killing in Cyro.... Kind of a hard problem to solve.

Or reduce the logic being run per tick, which is what Veng was all about.

Thanks again!