Table and Players

[tonyday567]

I think something like Player and Table belongs in base. They kind of go together and it may be a matter of taste as to what parts are a Table and what parts are a Player.

A Player has a Seat, a Stack and, once cards are dealt, some Hole cards. A player acts via BetAction. They have "Bets" which are chips that have been anted or bet so far. They also have some state like "BettingOpen | BettingClosed | Folded | NeverSatDown"

A Table, which is composed of ante structure, TableSize, list of Players, Board, Pots (consisting of folded antes and chips, and plural due to side pot potential), BigBlind (a cursor of which Player is/was the big blind), NextToAct (a cursor for the current actor) & ActionToDate (some history of Table State). Also (maybe) Focus, which might be sort of your Hero, representing what parts of the Table are visible. Tricky to define that.

I separate Bets and Pots as this seems to be the easiest way to work out side pots, split pots and all of that. It may not be.

[tonyday567]

If this covers all usage cases then there is a heap of functions I have that also fit in here, and shouldn't be a matter of opinion.

Table updates get driven by bet :: BetAction -> Table -> Table for example.

[santiweight]

I think this is out of scope. Let me split up what I find less controversial and what I think is not for poker-base...

Less controversial:

• TableSize: we should support the range 2-10 for time being I think
• Board: at least for non-mixed-games this is uncontroversial (we could support non-holdem-like games later down the line if needed). I have this definition elsewhere - we could pull it in. Perhaps there is space for controversy here?
• NextToAct: a newtype around Maybe Position I should think?
• IsHero: Hero | Villain
• BetAction - mildly contrversial... Bovada calls a Call that is all-in in an AllIn, and a raise that is all-in an AllInRaise. I personally don't mind having what I have in this package currently minus AllInRaise and AllIn. I think the differences isn't that important, and PokerStars' hand histories seem to agree. I'm happy to include BetAction if you agree with this assessment :)

Controversial:

• Player - I found this to be an unsolvable one. Take, for example, the difference between my poker-game, and poker-maison. Should player include Position? I think not personally - some players might be at the table, but not in the current hand. Someone might think Players are only those players in the hand. Does Player have a name? Even seemingly basic stuff like having a Maybe Position is not how I do this - I keep each Player to just a stack, and store the mapping of Seat -> Position globally in the GameState. I think we'll find too many design choices here sadly.
• Anything along the lines of HandState, TableState etc. I'll describe below.

A good way to handle State, in my experience, is to have granular effects, which is what I attempt to capture in poker-game (perhaps poorly named?). That package handles only your bet :: BetAction -> GameState -> GameState along with availableActions :: GameState -> [AvailableAction].

That way, someone who comes in to use our ecosystem does something like:

data GameState = GameState
  { activeHandState :: Poker.Game.GameState
  , seats :: Map Seat Position
  , tableState :: Map Position Player
  ...
  }

I think this works out, because poker-game is just the absolute bare minimum stuff to keep track of what action can occur next - nothing_else. This is what we would end up with there:

data GameState b = GameState
  { _potSize :: Pot b,
    _street :: Board,
    _stateStakes :: Stake b,
    _toActQueue :: [Position],
    _posToPlayer :: Map Position (Stack b),
    _streetInvestments :: Map Position b,
    _activeBet :: Maybe (ActionFaced b)
  }

data ActionFaced b = ActionFaced
  { _amountFaced :: b,
    _raiseSize :: b
  }

I've trimmed some fluff, because that really is all we need afaik.

I would suggest that our approach should be to keep this in an external package for the time being, because even if we find a unification of all the above, I think it would take a couple of weeks. Maybe one way we can do this is if I clean up poker-game and then we can discuss concretely based on that. And then when we agree on something, we can then merge poker-game into poker-base. For the time being, let's just defer this addition though, and get poker-base up on hackage and recruit some OSSers.

Sorry for the wall of text! Do you have a personal project like poker-game or know of some similar package? I know poker-maison has this logic, but a lot of the logic there is hard-baked for maison and I don't think the author wants to extract a package for his game logic (see here).

[tonyday567]

Ok, your GameState is my Table. I've coded up pre-flop only, getting a sense of it.

My TL;DR is yes, I agree that GameState is a hard slog to get right and shove in to poker-base.

However, just glancing at your GameState (I haven't seen poker-game before now, or poker-maison), I can tell that you've spent some time whittling it down and that it is close to the bare minimum needed to model a real-life game of holdem. My Player example is just a semantic difference. If it is actually that then anything else is isomorphic or not a game of holdem.

[tonyday567]

Closing. This covers material in poker-game but with different namings and might be a bit confusing to newcomers.