Nakama Multiplayer Engine #

The Nakama Multiplayer Engine can be used to power cooperative and competitive gameplay across all game categories, with a single Nakama node capable of running hundreds (or thousands) of matches depending on the gameplay. See the benchmarks for more details.

Multiplayer functionality is distinguished from other real-time features (i.e. chat) as it is the real-time exchange of gameplay data (i.e. player position, movement). The format of your game dictates the nature of the gameplay data that must be exchanged between players and, ultimately, how multiplayer is best built into the game.

Multiplayer games can fall into one of two categories: Synchronous Real-time or Turn-based.

Synchronous Real-time #

As the name suggests these are games that require the fast, continuous exchange of gameplay data such as player movement, projectiles, and the like. There are two types of implementations for synchronous real-time multiplayer games: relayed (also known as client-authoritative) and (server-)authoritative.

Relayed #

In the relayed multiplayer model Nakama functions as a relay for gameplay data between clients, it has no insight into what the data being sent is and no oversight into whether the data is correct.

The only information maintained by the server are the ID of each match and a list of presences for each match. Users can create, join, and leave matches with messages sent from clients. Any data sent through a match is immediately routed to all other match opponents.

Relayed matches are kept in-memory and exist on the server until their last participant has left.

Authoritative #

In the authoritative multiplayer model all exchanges of gameplay data are validated and broadcast by the server. In this model you write custom server runtime code for the gameplay rules to be enforced by Nakama (i.e. how many players can join, whether matches can be joined in progress, etc.).

Authoritative multiplayer is suitable for fast paced real-time gameplay. Messages are sent to the server, server calculates changes to the environment and players, and data is broadcasted to relevant peers. This typically requires a high tick-rate for the gameplay to feel responsive.

Turn-based multiplayer #

In turn-based multiplayer games the gameplay alternates between players. The frequency of each player turn varies according to game type. These games can be “active” or “passive.”

Active #

In “active” turn-based games players alternate turns quickly and remain connected for the duration of the match - think Clash Royale or poker games as examples. In such games the server receives input, validates them, and then broadcasts to players. The expected tick-rate is quite low as the rate of messages sent and received is low.

Passive #

In “passive” games the gameplay can span several hours to weeks - think Words with Friends. Here the server receives input, validates them, stores them in the database and broadcasts changes to any connected peers before shutting down the server loop until the next gameplay sequence.

Your multiplayer implementation for passive-style gameplay will vary depending on whether the game is entirely asynchronous or has elements of real-time gameplay - times when players may be online together and you want to enable real-time interactions between them.

For the former, with no real-time functionality, a group can be used to represent the multiplayer “match”, with all match participants being members of the same group. The “match” owner can be either the user that created the group or the system user.

The Nakama storage engine can be used to store the match state, with the group ID of each “match” being the key under which it is stored. You can then use a series of RPCs to manipulate the stored state and send notifications to the group (match) participants.

For a game with some elements of real-time functionality, you can use an authoritative match with the lowest tick rate allowed (1).

In your match logic, the list of match participants should be stored in the match state. While any match participants remain online, send them the match state and keep the match loop running. When all participants are offline, at the end of the match loop you write the match state to the database - using any desired key and the system user ID - and then terminate the match.

Session-based multiplayer #

See the dedicated session-based multiplayer page.

Match listing #

Match listing is one of two methods, along with the matchmaker, available in Nakama for your players to find a multiplayer match.

Match listing is used to show players a list of existing matches to join and can be used to create a match lobby. The list can be refined based on match labels and any other desired query.

Matchmaker #

Where match listing is used to find existing matches for players to join, Nakama’s matchmaker allows users to find opponents and teammates for creating new matches, groups, and other activities.

The matchmaker maintains a pool of users that are currently looking for opponents (or teammates) and places them together whenever a good match is possible. It receives and tracks matchmaking requests then groups users together based on the criteria they’ve expressed in their properties and query.