Games & Aynchronous Integrations
When a game network attaches external integrations, such as remote wallets, asynchronous communications becomes important. This can be any kind of integration, but in this blog post we'll assume it's a wallet we're talking with. So, what's our problem?
- If the network has several operators no operator must block players from another operator. If the wallet operation is synchronous, one call to an integration may lock the entire table. It is more acceptable if there is only one operator, but when there's several, we must make sure no-one is penalized by another players operator.
- Similarly, we may have other integrations that takes time even for a single operator and don't want to block game play during it's operation. This might include interactions with national gambling authorities, etc.
- Send buy-in information to player
- On buy-in request from player, set player state to "buy-in in progress"
- Hand-off buy-in operation from the game to a wallet service
- When buy in is complete, wallet service notifies game
- Game sets player as "in game" and notifies the same
Asynchronous Games in Firebase; pt II
Last post I looked at the motivation for writing asynchronous multiplayer games on top of Firebase. This post I'll sketch an outline on how to actually do it. The first thing to consider is that we now have two notions: The
Asynchronous Games in Firebase; pt I
Since the social web started to expand, asynchronous multiplayer games seems to really have taken off. So my immediate question is obviously, can I do that on Firebase? And the short answer is: of course. For the long answer, please