Rooms and Worlds

coherence provides two types of online replication services: Rooms and Worlds. Read about the different uses cases for each.

Rooms

Rooms are best for session-based gameplay where the match between players takes place in a short-lived environment.

Use case

A good example is a first person shooter multiplayer match. The match takes place between two teams in a single game session, and players enter through a lobby and matchmaking. When the match is concluded, the multiplayer environment the match took place in is closed and players return to a lobby.

This is one example of how Rooms can be used, but it is by no means the only use case. The important distinction between Rooms and Worlds (see below) is that Rooms are relatively short-lived and are meant to be created and closed by the Game Client through the coherence SDK.

See Rooms API.

Current limits for Rooms are as follows: Players

The default setting is 10 players hosted, but you can specify your own value anywhere between 2 and 100 players.

To support more than a 100 players per room, write to [e-mail]

Entities

1000 by default, but can be increased up to 65535 in local development or client-hosted scenarios.

There is no UI button for increasing the supported player count, so you need to work through our Rooms API.

When creating a room viaReplicationServerRoomsService.CreateRoom you can pass SelfHostedRoomCreationOptions as creation options.\

To change the Entity limit just set the SelfHostedRoomCreationOptions.MaxEntities to a desired value.\

Worlds

Worlds, as opposed to Rooms, are long-lived and permanent multiplayer environments provided by coherence. Using the Developer Portal, your project will easily define and manage your World configurations.

See Manage Worlds.

Use case

A good example of a World is a permanent environment for an Massively Multiplayer Game (MMO). Regardless of the number of players connected, the environment is always available, and players can connect and disconnect at will.

Entities can be permanently saved in the World so that even if there are no active connections, they still persist when players do connect.

See Worlds API.

Rooms and Worlds work together

Your project does not have to choose one-or-the-other. A project in coherence can contain both World and Rooms.

Use case

A good example of this scenario is again, our MMO. Although players connect to a permanent and persistent World, they may enter a dungeon instance with other players. These dungeon instances can be Rooms.

The primary difference in the configuration and usage of Room and Worlds is that Worlds are managed in the Developer Portal, whereas Rooms are created and managed through the SDK.