chips-blockchain / pangea-poker Goto Github PK

If a log of each bet could be added in a text box down the bottom left corner of the display. So people can see a text log of each hand/bet played on the table. (by @NutellaLicka)

Add the log box from the original designs and display player actions in it.

• Add basic logging
• Fix logging for All-In
• Add test coverage

If there are no prior bets, the first bet should be called bet instead of raise.

We should provide public URLs of the releases so players don't have to go through the cloning/installation process.

In case of All-In during any of the screets, the remaining cards don't get shown at all. The winner gets selected, and the game goes on.

If one player goes All-In post-flop (and only post-flop) the opponent does not have time to preform any action, and the Show Down instantly begins.

See this video: https://share.getcloudapp.com/7KuygONE

And this recording from 00:20: https://share.getcloudapp.com/DOuvwWjp

It seems like that this is an issue with the backend.

Any first bet pre-flop, weather it is call or raise, results in FAILURE on the player node that initiated the action.

Pastebin: https://pastebin.com/Qt4dq4Mv

Branches used:

• frontend: master at 0bb0701
• bet: master at sg777/bet@bcc864f

When a new hand starts after an All-In, the palyer at the Big Blind has negative stack. The problem appears to be that the first round_betting message does not have player_funds property, as seen bleow.

After the opponent folds, the hole cards of the previous hand get dispalyed of the winner. This happens only when there was a previous hand that reached Show Down.

The issue might be that playerCards does not get cleared properly.

Video: https://share.getcloudapp.com/kpumEG7b/

The first hand plays just fine. During the second hand, however, DCV crashes with Bus error (core dumped) every time when using the current test nodes.

There is an action in poker called Muck. It is essentially the same as a Folding, but it happens during the showdown and allows a player to not show their cards, therefore signaling that they have a worse hand and loose the pot.

Consider the following scenario:

River

1. Player A bets 1000
2. Player B calls 1000

Showdown

1. Board reveals AKT23
2. Player A shows AA and has three of a kind (set)
3. Player B has `KT and has two pair and chooses to muck the hand

In this scenario, Player A has to act first and must show their cards. Player B has a worse combination of cards with two pair, therefore he can just "fold" their cards, which is called muck in this case. Note that he has the option to either muck or show, default setting usually being muck. PokerStars even has a Show/muck hand preferences option.

Had Player B had a better hand, they would have to show it in order to win the pot.

In live poker, a mucked hand is never shown, and although technichally could be requested to be shown, it is considered to be a huge briech of etiquette. In online poker, many of the poviders show mucked hand during replay or hand histroy, but not during the actual game.

How should the muck be handled?

My suggestion is to not to show mucked hands by default, but provide a hand history text file, where it will be available.

The front-end originally started naming players with 1, as player1. The backend however, starts counting from 0, as player0. This is causing some unnecessary and sometimes confusing code all around the app.

We should fix it and the frontend should begin counting form 0 to match the backend.

The backend should send a message to all the players informing the UI which player is currently active. The message should be sent at the same time the round_betting method is being sent to the currently active player.

This will be very important to have for 2+ player tables. Also, it's currently blocking #17 and #20.

Currently, the app uses a theme.js to handle theming. CSS variables might be a more appropriate and more dry solution.

Following the next hand after a player folds, the new holecards don't display at the GUI for some reason. The message is correctly received from the backend, just no GUI update.

For some reason, sometimes the opponent's cards don't show up during showdown.

For example:

Player 1 did not display Player's cards and vice versa.

The finalnfo message was:

{
  "method": "finalInfo",
  "showInfo": {
    "allHoleCardsInfo": [
      [
        "KS",
        "8C"
      ],
      [
        "JD",
        "10D"
      ]
    ],
    "boardCardInfo": [
      "5S",
      "7C",
      "JS",
      "2H",
      "7S"
    ]
  },
  "win_amount": 4,
  "winners": [
    1
  ]
}

In some cenarios, when one player goes All-In, the other cannot call it, because the button is not responding. Furhter investiagtion is needed.

In the above scenario, player1 went All-In before the flop and player2 called. Since there is only one player left with funds (as it is currently player_funds: [0, 200]), it is impossible to do any more betting, therefore the showdown has to begin Pre-Flop.

finalInfo has to be sent to the players before the flop. It is the equivalent of both players going All-In with equal stacks (eg. if it was player_funds: [0, 0]).

If there was a third player who had chips (eg. player_funds: [0, 200, 200]), then the betting round has to continue and we will have to create a side pot that the player1 cannot win. But that's only once we get pass heads-up.

Instead of going into the next hand straight away, is there a way to add a couple of seconds after the hand finishes, for people to digest who won the hand and with what cards.

Also, if a log of each bet could be added in a text box down the bottom left corner of the display. So people can see a text log of each hand/bet played on the table.

We will need a landing page that will display the available tables. Displaying the number of players on the table would be a nice to have, but it might entail some extra work on the back-end.

Tasks

• Design the page
• Build it
• Deploy it to https://pangea.chips.cash

1. The user visits the landing page (eg. https://pangea.chips.cash)
2. The user selects a table from a list of available tables
3. The joins an available seat
4. The user begins to play

The current README does not contain much information for either players or developers who'd like to contribute. I should spend some time to update it.

Currently the GUI expects the players to click on the player widget in order to join the table.

This is only a requirement if the game has not started yet. If it's already on and the backend returns Table is Filled, it means that the player has already joined and the GUI should be in the appropriate state.

This raises some UX questions that need to be addressed in the future.

Once the game started, player1 goes all-in and when player2 also goes all-in, in the GUI everytime I'm getting the error as mentioned below:

Controls.tsx:88 Uncaught Error: Something is wrong with the betamount.
    at handleButtonClick (Controls.tsx:88)
    at onClick (Controls.tsx:177)
    at HTMLUnknownElement.callCallback (react-dom.development.js:362)
    at Object.invokeGuardedCallbackDev (react-dom.development.js:411)
    at invokeGuardedCallback (react-dom.development.js:466)
    at invokeGuardedCallbackAndCatchFirstError (react-dom.development.js:480)
    at executeDispatch (react-dom.development.js:612)
    at executeDispatchesInOrder (react-dom.development.js:637)
    at executeDispatchesAndRelease (react-dom.development.js:743)
    at executeDispatchesAndReleaseTopLevel (react-dom.development.js:752)
handleButtonClick @ Controls.tsx:88
onClick @ Controls.tsx:177
callCallback @ react-dom.development.js:362
invokeGuardedCallbackDev @ react-dom.development.js:411
invokeGuardedCallback @ react-dom.development.js:466
invokeGuardedCallbackAndCatchFirstError @ react-dom.development.js:480
executeDispatch @ react-dom.development.js:612
executeDispatchesInOrder @ react-dom.development.js:637
executeDispatchesAndRelease @ react-dom.development.js:743
executeDispatchesAndReleaseTopLevel @ react-dom.development.js:752
forEachAccumulated @ react-dom.development.js:724
runEventsInBatch @ react-dom.development.js:769
runExtractedPluginEventsInBatch @ react-dom.development.js:914
handleTopLevel @ react-dom.development.js:5848
batchedEventUpdates$1 @ react-dom.development.js:24343
batchedEventUpdates @ react-dom.development.js:1463
dispatchEventForPluginEventSystem @ react-dom.development.js:5943
attemptToDispatchEvent @ react-dom.development.js:6059
dispatchEvent @ react-dom.development.js:5963
unstable_runWithPriority @ scheduler.development.js:815
runWithPriority$2 @ react-dom.development.js:12188
discreteUpdates$1 @ react-dom.development.js:24359
discreteUpdates @ react-dom.development.js:1486
dispatchDiscreteEvent @ react-dom.development.js:5926

If toCall is bigger than the player's stack, it should display the player's stack as call amount.

Currently:

Console error:
Warning: Slider[max] - Slider[min] (-96) should be a multiple of Slider[step] (196)

Actions:

1. Player2 raised to 100
2. Player1's turn now

The slider climbs out it's container as seen on the screenshot above. The game does not break.

Currently, the all-in showdown only works at the river. This should work on all other stages of the game as well.

We had some back end limitations, but it seems to have been solved.

Instead of having all 3 options (dealer/player1/player2) selectable at the start, maybe just prompt "Are you a Dealer or a Player?", then go into the next menu to add the appropriate IP data. For players, instead of selecting player 1 or 2, have the nodes connect and then select a seat, which then defines what player number they are.

https://i.gyazo.com/4003a0e86e261409a23df751dd4ec406.png

Integrate Storybook for better visual testing.

Currently, the front-end is sending possibilities: [4] even if the player goes All-In. When I fixed this and properly sent [6] to the backend, the game stopped responding.

Scenario:

1. SB Calls raises to 4
2. BB Re-raises to 200 and is All-In
3. Backend is frozen.

I am wondering how important it is to actually send possibilities: [6]. Does that make any difference in the game? All-in can happen by calling or by raising or even by posting the blinds.

Therefore maybe we should just ignore this possibility and remain using raise instead?

The original designs have a "Sit Here" state for the player widgets to indicate which seats are available. This feature should be added for clarity.

HTTPS is also more secure, and in order to go to production on the web, we would have to switch.

I would like to use netlify for continous deployment, but currently we are using ws which only work on non-secure http connections, and is not supported by Netlify.

In order to use https, we need to use wss.

Sometimes during the game, the active player highlighting does not update properly.

It would be great to get out from the browser and have a standalone app, in order for better window management when it comes to playing on multiple players.

Actions on the flop

1. Player1 opens with a bet of 2
2. Player 2's turn

Expected behavior

The Raise button should show Raise to 4, due tominRaiseTo being 4.

Actual behavior

The Raise button showsRaise to 6, due tominRaiseTo being 6.

Thoughts

Not sure why this is happening. Player1's first action to open with a bet of 2 is being interpreted by the backend as a raise (possibilities: [4]) -- however, technically it is called a bet, because there are no prior bets in this betting round that the player can raise compared to.

I don't think we need to create a new backend message type for the possibilities, raise should be fine, but the GUI should receive the proper number.

The game currently doesn't feature any sounds. For better UX and accessibility, we should add audio feedback to certain actions.

Some todos:

• Integrate a sound library
• Sample sounds
• Add fold, call, raise, check sounds
• Add chips movement sounds
• Add alert sound
• Add card deal sound
• Add chips collection sound for each street (currently only works for the river)
  • Address the winner selection flow glitch that was caused due it
• Do not trigger chips collection sound when there are no chips to collect
• Add flop sound
• Add turn and river sounds
• Set bet sound to the same as call
• Add alert sound to when the time is about the be up
• Add mute option
• Add test coverage

The timer functionality has been disabled. We should enable it again.

If one player folds during the River (the last boardCard), the backend sends allHoleCardsInfo for both of the players. This should not happen, hole cards should only be disclosed if all of the River bets get called, which is called the Show Down.

See this video from 00:54: https://i.norbert.dev/a534bf

The bet on the River does not get called, the allHoleCardsInfo array gets filled up with the all players' cards. This should not be the behavior.

On the test nodes, one of the player's balance is -1. This should not be possible.

I thought that once a player's fund reaches zero, it will automatically recharge to 200. Also, the some of the two player's funds should always be 400. Am I wrong about it?

The slider maxes out just 1 chip less than it is the total balance, not allowing the player to go all-in.

Currently, calculating the pot happens on the frontend. Recently, the pot property has been added to the betting messages, thus the pot should be calculated from the backend to avoid mistakes.

The player balances are currently all calculated at the front-end. Recently, the back-end began to send an array of balances, thus, we should also use this data to update the balances.

Currently, the balances get reset after each hand to 200, however, the front-end does not do this reset, which results in mismatching values.

@sg777#2257 there are two missing pieces for the Table Select feature to work:

1. The ability to check how many people are currently at the table before joining the table
This is important to know to which table the user can join to when she picks from the list. (https://share.getcloudapp.com/NQuv1qkg).

2. A way for the player node to know where the other players are sitting at the table
When the player joins the table, before sitting down to an available seat, we must update the GUI with all the other players currently sitting at the table. This way the player can know which seats are free and we can seat the player there.

A potential solution may be for both of the above is to have a method (eg. game) that responds from the dcv (or even from the player) with the following info:

• number of seats available at the table
• number of players currently at the table
• small blind/big blind
• game type
• which seats are occupied and which are empty

The Chat Box might have been properly implemented in the original Pangea Poker repo. We need to look into it and determine how it will be ported to the new GUI.

For a split second, the turn board card starts to flip. This is because we receive finalInfo, but the allBoardCards array is actually empty.

Currently, after a hand ends and the winner gets announced, the winner's stack does not get updated with the amount the winner won. The GUI should do the math until this has been solved via a property from the backend.

https://i.gyazo.com/65255770ee4d9ead5701b2793c81c0a0.png

The wording shows RAISE when I clicked ALL IN.

Sometimes possibilities does not contain 4 for raise, but it should.

For example:

• Pre-flop for the small blind: https://share.getcloudapp.com/GGuAxZZd
• Post-flop for the second player to act: https://share.getcloudapp.com/d5uexlrA

When the method: reset is received for the players, the table should reset to it's initial state. There is an existing action called nextHand that does the reset, it just needs to be linked with the new reset method.

Each time we refresh the game when testing, the startup modal appears again an we have to do multiple clicks to start the game. Having query strings such as ?nodeType="dcv"?ip="192.168.0.1 in the URL would make the refresh a bit faster.

In the above scenario, re-raise should not be possible, only the Call and Fold buttons should be displayed.