Skip to content

Commit

Permalink
Update player_rejoining.md
Browse files Browse the repository at this point in the history
  • Loading branch information
sg777 committed Mar 25, 2024
1 parent e031783 commit 3e6203e
Showing 1 changed file with 7 additions and 6 deletions.
13 changes: 7 additions & 6 deletions docs/verus_migration/player_rejoining.md
Original file line number Diff line number Diff line change
@@ -1,12 +1,13 @@
## Player Rejoining
-------------------
Bet stores secret information local to the node in whcih its running either on local DB or in local files. If not all, most of the game related public information of the player is stored across verus IDs(specifically in table/dealer/cashier IDs). When the player gets disconnected, bet allows the player to rejoin and if the player fails to rejoin within the agreed time interval(atm, its 20s) then bet allows the dealer to take a predtermined action for the player inorder for the game to moveon.
Bet stores the game related confidential information either in local DB or in local files on the node in which bet is running. If not all, most of the game related public information and the players information is stored across the verus IDs(specifically in player/table/dealer/cashier IDs). When the player gets disconnected, bet allows the player to rejoin and if the player fails to rejoin within the agreed time interval(atm, its 20s) then bet allows the dealer to make a decision based on the defined rules in order for the game to move on.

The action taken by the dealer depends on the game state, i.e
- if the disconnection happens before betting then the correponding player is dropped from the table and dealer(or player) raise a request to reverse the payin_tx of the player.
- if the disconnection happens during the game, then the dealer considers players move as <b>fold</b> and proceeds with the game.

It's also possible that the player can raise a dispute request to claim the payin_tx while being in the game, to prevent any misuse of the dispute handling cashiers will always check if that payin_tx is not attached to any table and if its attached to any table then cashiers reject the dispute handling.
The action taken by the dealer depends on the game state, and at any state player has the choice to rejoin with in the 20s window of time, if by any reason player fails to rejoin the following will be the dealers action towards it:
- if the players disconnection happens before the deck shuffling then dealer raise a request to reverse the payin_tx and removes the corresponding players join info from the table and dealer IDs.
- if the players disconnection happens during the deck shuffling then dealer raises a request to reverse the payin_tx(dealer may chose to impose a penanlty of 5% on payin_tx or some fixed amount based on whichever is lower. The reason for penanlty is because as a part of deck shuffling players has already been spent many block fees for deck shuffling) and removes the corresponding players info from the table and dealer IDs and reset the game state to player joining state and will wait for other player to pitch in and fill the position.
- If the players disconnection happens during the game, then the dealer considers players move as <b>fold</b> and proceeds with the game.

It's also possible that the player can raise a dispute request to claim the payin_tx while being in the game, to prevent any misuse of the dispute handling cashiers will always check if that payin_tx is attached to any game ID in any of the active tables exist atm, if the payin_tx is attached to the active game ID then cashier nodes will wait until the game gets finished to handle the dispute request from the player.

### Data Needed for Rejoin
---------------------------
Expand Down

0 comments on commit 3e6203e

Please sign in to comment.