Heroic vs Photon Cloud

This is intended to be a brief, objective, technical comparison of Heroic Labs and Photon Cloud. If you feel this comparison is unfaithful for whatever reason, please send an email to contact@heroiclabs.com .

At A Very High Level

  • Heroic Labs' service is hosted on Amazon Web Services; Photon Cloud is hosted by Exit Games.
  • Heroic Labs' multiplayer engine is written primarily in Erlang with some C; Photon Cloud is written in C++ with some .NET.
  • Heroic Labs' handles persistent users and shared match state.
  • Heroic Labs' SDKs are open source on GitHub .

Features/Capability Comparison

The table below gives a high level comparison of Heroic Labs' and Photon Cloud's multiplayer engine features and capabilities. 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 Cloud.

Feature/Capability Heroic Labs Photon Cloud
Multiplayer Engine Turn-based. The asynchronous engine supports multiplayer sessions like Worms, Advance Wars, and Words With Friends. Turn-based and Realtime. The engine is realtime, it works like a message broker with different limits set for Turn-based games.
Turn Data Persistence Yes. Every player submits a JSON object and matches rotate between all players. Players can re-sync to retrieve all turns if needed. 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 Random, Social Friends, Criteria-based Random, Criteria-based
Manual Matchmaking User IDs Arbitrary room lists and filters
Number of turns / sec Unlimited 100 per second
Hosted Amazon Web Services (AWS) Exit Games
Self-hostable No Windows Only
Query Engine User-generated content can be queried expressively with a Lucene-based query language. The queries "score" results so more relevant results are returned (like a search engine). Only possible for finding rooms, not available for in-game data. SQL-like queries can be used to filter matches based on certain criteria. The SQL dialect is built on SQLite.
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 securely persisted by the service. Clients can access matches at any point until they end, or the client opts to leave the match. Match data is tracked and versioned so clients can catch up at any point if they've missed updates. 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 HTTP Socket-based
Sync Behaviour Adaptive. Clients can request new data as often as required to support the desired level of user interactivity. Data is persisted by the service, and state is tracked, so clients losing network connectivity can rejoin at any 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.
Max Player Limit Per Match 16 8 approx. Message and acknowledgement rate requirements, coupled with room 100/sec message limit, effectively limit the possible number of players per room.