Architecture
Core concept
The architecture of integrating Idem is simple: Using the API, players are added to the matchmaker, the matchmaker finds matches and sends them back to the game, the game is played, and after completion the results are returned to Idem to update rating & ranking.
![Basic architecture idea](/img/architecture/base_idea.png)
In the further steps, we will walk through the other components of your backend and how this affects how to set things up.
Integration Types
Idem can be connected in two different ways, depending on whether your game operates its own backend, that connects to players, or whether you rely on Idem to directly interact with players and startup game-server instances on your behalf. For a guide on which to choose, see Choose your architecture
Server-based
In the default integration, the matchmaker communicates directly with the backend of your game. Your server sends new players to the matchmaking-API and will receive paired players back.
![server based](/img/architecture/server-based.png)
Player-based
For games that do not have a backend (or choose not to use it for this purpose), Idem allows for players to submit themselves for matchmaking. Once two players are matched, a game server of one of our infrastructure partners is spun up and the players are given access to the game server.
![player based](/img/architecture/player-based.png)
Choose your architectures
Here are the things to consider, when thinking about how to interact with Idem:
1. Own backend, 3rd party backend, or no backend?
The most important question is how you want to call the Idem API and receive your matches back. Idem generally supports any kind of game-backend, whether self-built or 3rd party Game-Backend-as-a-Service (GBaaS). Idem is agnostic, since it only requires its API to be hit with requests.
Own backend
If you are building your own backend, you can simply go ahead and connect to Idem through its API directly. This also applies if you are relying on a 3rd party game backend for certain aspects of your game backend (e.g. collectibles), but you handle matchmaking out of your own code.
Your architecture ->
Third party backend
In case you are using a GBaaS, you might be in luck, because we have already done lots of the work for you. We have reference implementations and tutorials for a number of popular GBaaS, so go check out the list here. We are also continuously adding integrations to additional GBaaS, so in case your favourite GBaaS is not yet available, get in touch to see whether we might already be working on it.
If you are only using GBaaS for functions not related to matchmaking, see own backend.
If an integration to your favourite GBaaS is not yet available, you can still use Idem matchmaker. You will need to find a way to make API calls through REST or Websockets. For support, please get in touch with us.
Your architecture ->
No backend
For certain games, a backend is not required (e.g. web-based games). The players (or rather the game-client on the players machine) calls Idem's matchmaker directly to enqueue themselves for matchmaking. Idem finds a match, starts a game server and provides the connection details to the game-server to the players.
This architecture can be used if you are utilising one of the hosting providers that Idem supports.
Your architecture ->
2. Who handles game-servers?
If your game relies on game-servers, as opposed to player-hosted games, you need to launch an instance of your game server, as soon as a match is found.
Backend initiated
If your own backend handles the launching of instances, no need to read further. You're sorted.
Launched through Idem
Idem can launch a game-server instance on your behalf, as soon as a match is found. This can be useful e.g. for player-based architectures or if for some other reason (e.g. simplicity), you want the creation of the game instances handles by Idem.