Game Lobbies
The GAME domain: a lobby is a smart product that hosts a series of two-player matches for a pot. What it is made of, and what it guarantees a caller.
A game lobby is a smart product in the GAME domain, of product type game-lobby. One lobby
is one table: one contract that hosts a series of matches, each played by two seats for a pot.
Tic-Tac-Boom and Drop Four are both built on it; the protocol does not know which game an app is,
only which board the lobby was deployed with.
The model
| Protocol | What it is | The word a player sees |
|---|---|---|
SmartProduct, domain GAME, type game-lobby | One table: its board and pot share fixed at deploy, its buy-in locked while anyone holds a seat | lobby, table |
ProductInstance | One match, created when it starts | match |
| The match's product image | The result, drawn from the final board | trophy (a win), match picture (a draw) |
| A buy-in | A seat's payment, split by the lobby's frozen contributions | buy-in, seat |
| The kitty | The pool share of each buy-in, held by the contract until the match settles | the pot |
The bomb capability | An item a spectator uses during a live match | bomb |
| The host | The lobby's creator, paid a contribution share of every buy-in | host |
A lobby is created from the smart-lobby recipe (rtClient.games.createDraft). Opening one
requires the CREATE_GAMES entitlement, which only Admin holds today, so the tables that exist are
opened by the Rising Tide team. Lobbies are scoped by sourceAppId: an app lists its own tables.
The protocol names each domain's thing in the user's words at the app layer. A caller builds against the left-hand column; an app's copy uses the right.
What a lobby guarantees
These hold on chain, whatever client calls the contract.
- The terms freeze at the first seat. While anyone holds a seat, the lobby's price and product info cannot be changed, and its contribution split was fixed at deploy. A player who sits down pays what they were shown.
- Every buy-in splits the moment it lands.
poolPctof it stays in the contract as the kitty; the rest settles to the lobby's frozen contributions, the way a mint does. Their percentages sum to100 - poolPct. A seated creator of the lobby does not pay their own share to themselves. - A seat is refundable until the match starts.
leavereturns the seat's recorded pool share to the player who left; the contribution legs stay paid. When the first seat leaves, the second moves up. Once the match starts, neither seat can leave. - Only the winner can claim the kitty, and the claim is the trophy. A won match pays the kitty to the winner and mints the match to them as a numbered edition. A draw pays each seat half and mints nothing.
- A spectator item comes only from a spectator. The bomb is refused on chain for either seated
player, so only a signed-in viewer who holds no seat can use it.
gameLobbyDetails.itemAudiencesays who an item is for; the contract enforces it. An item's payment splits like a buy-in, so its pool share grows the kitty; an item priced at 0 moves nothing and leaves the kitty as it was. - A stalled match can be closed, but not by a player. If no move lands for 144 Bitcoin blocks, the lobby's creator can close the match as a draw - unless they hold a seat in it.
The match picture
Each game's lobbies draw their result through a style set owned by the app, drawn to its own
scene. The picture is rendered when the match is decided, before anyone claims, so a draw has one
too. To draw one from a sample match instead, see rtClient.gameStyles.generateLivePreview on
rtClient.games. Read a real match's picture the way any instance image is read: rtClient.productImages.list("product_instance", [instanceId]), with the instanceId from a match row. The style set's artist is a
contributor on the lobby, paid from every buy-in.
See also
- rtClient.games - reading lobbies and matches, opening a table, and the
game-actioncommand - Games API - the routes
- Capabilities - the bomb, and what an item is
- How a Lobby Works - the same rules, as a player reads them
Capabilities, Constraints & Attributes
The three composition kinds. A capability says what a product does, a constraint says what it may not do, and an attribute says what it is. Products are composed from these, not forked from product types.
Chainhooks
Chainhooks are how the protocol observes confirmed on-chain transactions on your behalf, and the event types your app sees the results of.