Worlds

Give every player or team their own persistent world that boots on demand and sleeps when idle.

Worlds let you give each player (or team) their own world that boots the moment they open it, saves itself across sessions, and goes back to sleep when nobody is in it. Think a Hay Day-style farm: one world per player, always there when they come back, costing nothing while they are away.

You declare a world in your game manifest and open it through the SDK. Hive handles the rest: picking a node, restoring the latest save, booting the world, routing the player in, and snapshotting it back when they leave. You never manage save files or servers by hand.

Available now for single-owner persistent worlds. Cross-server routing and a few placement controls are still landing. See What is still preview.

How it works

A world belongs to an owner (a player or a team), not to a server. It is only hosted on a node while it is active, and it can come back on a different node next time. That is what makes worlds portable instead of pinned to one box.

The lifecycle is automatic:

1. Open. Your game calls openPlayerWorld (or openTeamWorld). If the world is already running, Hive routes the player straight to it. If not, Hive leases it, restores the latest save, and boots it on a node.
2. Play. The hosting node keeps the world alive while players are in it.
3. Idle. When the last player leaves, Hive snapshots the world and unloads it after a short grace period. A sleeping world costs only its stored snapshot.
4. Re-open. Next time the owner opens it, the save is restored exactly as they left it.

A single writer owns a world at any moment, so two nodes can never boot the same world and corrupt it.

Using it from the SDK

Declare the world in your hive-game.json manifest:

{
  "gameId": "farmlife",
  "engine": "HYTALE",
  "worlds": [{
    "key": "farm",
    "lifecycle": "PERSISTENT_SINGLEOWNER",   // one saved world per owner
    "ownerScope": "PLAYER",                   // PLAYER or TEAM
    "snapshotPolicy": { "onIdleSeconds": 120, "intervalSeconds": 300 }
  }],
  "playerData": [{ "namespace": "farmlife" }]
}

Then open it when a player joins:

hive.worlds().openPlayerWorld(player.uuid(), "farmlife", "farm")
    .thenAccept(route -> {
        // READY: route the player now. LOADING: wait for the world-ready
        // event, then route. The node boots + restores the save for you.
    });

// Force a save point, or hint a world can be put to sleep:
hive.worlds().snapshot(worldInstanceId, "after harvest");
hive.worlds().release(worldInstanceId);

Where the bytes live and how leasing works is handled for you. Your game only opens, saves, and routes. Player progression (currencies, stats, inventory) stays in player data; the world holds the built environment.

Local and cloud storage

A world’s snapshots can live in one of two places, chosen per network. The SDK and your manifest do not change between them.

The thing the cloud plan unlocks is world mobility, not storage for its own sake. On the local plan a world is tied to one machine; on the cloud plan the same world can wake up wherever there is capacity, which is what you want once you run more than one box or want players close to their region.

Switching a network to the cloud plan is a settings change, not a migration. New saves go to shared storage from then on. Your game code is untouched.

Teams and visiting

Worlds are owned by a player or a team, so the same machinery powers shared team worlds. A team world is just a world whose owner is a team id instead of a player.

Visiting another player’s world already works at the platform level: a world is just a world, and you can teleport any player into one that is active. The catch is that today you wire that routing yourself. The SDK opens and routes a world for its owner; sending a visitor into someone else’s world (deciding who is allowed in, booting it if it is asleep, and where to drop them) is your own logic for now.

A native visiting API is coming soon to make this first-class. Until then, treat visiting as something you build on top: get the target world active, then route the visitor in with your own rules. It is on the roadmap.

What is still preview

Shipped narrow and honest. Working today: per-player and per-team persistent worlds, on-demand boot and restore, automatic idle snapshotting, and both the local and cloud storage plans.

Still landing:

• Cross-server routing, so a lobby can open a player’s world on a dedicated world node (the scenario the cloud plan is built for). Today a world boots on the node that asked for it.
• Placement and snapshot-cadence controls from the manifest. Defaults are sensible; tuning them is next.
• Snapshot size and download in the dashboard, which arrive with the cloud plan.

For how worlds relate to the servers that host them, see Managed servers and Server registry.