This is intended to be a brief, objective, technical overview of Nakama and Photon
| Feature/Capability | Nakama | Photon Server |
| Multiplayer Engine | Turn-based and realtime. The engine itself is realtime and works as a message broker. Turn-based games have their state managed in-memory on the server. The server can also be switched into authoritative mode with a game loop in Lua managed per match. | Turn-based and Realtime. The engine is realtime, it works like a message broker with different limits set for Turn-based games. Server authoritative code can be written in C++ or C#. It’s unclear how game state is managed by the server. |
| Turn Data Persistence | Yes. | No. Like a message broker messages are delivered to all connected participants. If a participant drops their connection there is no built-in way to re-sync. |
| Automatic Matchmaking | Yes. | Not available in the on-premise server. |
| Manual Matchmaking | Yes. | Arbitrary room lists and filters. |
| In-game Chat | 1 on 1, group, and room-based chat. Available as part of Nakama server and can be self-hosted. | Not available in the on-premise server. |
| Chat History | Persistent chat history, can be kept as long or short as required by the studio. | Ephemeral chat history with a temporary message buffer. |
| Hosted | Any cloud of your choice, local or bare metal. | Windows-only VMs and local or bare metal. |
| Self-Hostable | Windows, macOS, and Linux. | Windows only. |
| User Identification | The service has built-in support for many different login options including reliable unique identifiers and email/password accounts. You can also connect the user via Facebook or Google accounts. | Requires external solution. The multiplayer service does not provide any way to reliably identify players. This must be handled separately through custom service integrations, and requires special consideration on the client side. |
| Match Persistence | All matches are persisted by the service. Clients can access matches at any point until they end, or the client opts to leave the match. Match state with multiplayer matches can be suspended and resumed via custom functions. | Rooms have no built-in persistence. Custom external integrations may be provided to persist room data on a message by message basis. There is no built-in mechanism to allow clients to find and rejoin a room if they've disconnected for any reason. |
| Transport Protocol | WebSocket, secure rUDP, WebRTC. | Socket-based (UDP, WebSocket etc.) |
| Sync Behaviour | Data is pushed to clients over a background socket. Data is persisted by the server, and state is tracked, so clients losing network connectivity can rejoin at a later point. | Mandatory polling callback expected to be triggered at least 10-50 times per second. Failing to maintain expected rates can lead to client disconnects. Because rooms are stateless, clients re-joining rooms after connection loss cannot catch up, by default. |
| Open Source | Fully open source server. | Closed source. |
Turn-based and realtime. The engine itself is realtime and works as a message broker. Turn-based games have their state managed in-memory on the server. The server can also be switched into authoritative mode with a game loop in Lua managed per match.
Turn-based and Realtime. The engine is realtime, it works like a message broker with different limits set for Turn-based games. Server authoritative code can be written in C++ or C#. It’s unclear how game state is managed by the server.
Yes.
No. Like a message broker messages are delivered to all connected participants. If a participant drops their connection there is no built-in way to re-sync.
Yes.
Not available in the on-premise server.
Yes.
Arbitrary room lists and filters.
1 on 1, group, and room-based chat. Available as part of Nakama server and can be self-hosted.
Not available in the on-premise server.
Persistent chat history, can be kept as long or short as required by the studio.
Ephemeral chat history with a temporary message buffer.
Any cloud of your choice, local or bare metal.
Windows-only VMs and local or bare metal.
Windows, macOS, and Linux.
Windows only.
The service has built-in support for many different login options including reliable unique identifiers and email/password accounts. You can also connect the user via Facebook or Google accounts.
Requires external solution. The multiplayer service does not provide any way to reliably identify players. This must be handled separately through custom service integrations, and requires special consideration on the client side.
All matches are persisted by the service. Clients can access matches at any point until they end, or the client opts to leave the match. Match state with multiplayer matches can be suspended and resumed via custom functions.
Rooms have no built-in persistence. Custom external integrations may be provided to persist room data on a message by message basis. There is no built-in mechanism to allow clients to find and rejoin a room if they've disconnected for any reason.
WebSocket, secure rUDP, WebRTC.
Socket-based (UDP, WebSocket etc.)
Data is pushed to clients over a background socket. Data is persisted by the server, and state is tracked, so clients losing network connectivity can rejoin at a later point.
Mandatory polling callback expected to be triggered at least 10-50 times per second. Failing to maintain expected rates can lead to client disconnects. Because rooms are stateless, clients re-joining rooms after connection loss cannot catch up, by default.
Closed source.