Nakama vs Photon Server
This is intended to be a brief, objective, technical comparison of Nakama and Photon.
If you feel this comparison is unfaithful for whatever reason, please send an email to firstname.lastname@example.org
At A Very High Level
- Heroic Labs' Nakama can be hosted on any cloud as well as locally. Photon Server can be hosted on any Windows Server environment, however it loses key capabilities (such as chat) when not hosted by Exit Games.
- Nakama server and the client libraries for various game engines are open source on GitHub.
- Nakama handles persistent users and shared match state as well as persistent chat history.
- Nakama comes packaged with a database to provide a fully capable collection of games services. No separate solutions are required for user accounts, social login, game storage, etc. Photon Server requires third party integration for all data persistence.
- Nakama can be run on Windows, macOS, and Linux for development and production. Photon Server is available on Windows Server with the .NET Framework.
- All of Nakama’s features: Realtime multiplayer, chat, matchmaker, server authoritative logic, etc. are available with the same server and license.
- Licenses for Nakama Enterprise (for multi-server clusters) includes all features and no artificial CCU limitations.
The table below gives a high level comparison of Heroic Labs' and Photon Server’s licensed self-hosted solution. To keep the page relevant in the face of rapid development on both sides, low level details are found in links to the online documentation for Heroic Labs and 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 (reliable-ordered and unreliable-unordered) based on the netcode.io specs.||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 game server.||Closed source.|