Create a class Dealer

[GoogleCodeExporter]

The Dealer class should give cards to players, ask them for their actions
and just run the game :)

It takes a GameDescription and populates the PublicGameInfo and
PublicPlayerInfo accordingly.

Original issue reported on code.google.com by bluegasp...@gmail.com on 16 Mar 2010 at 10:50

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

By chance found some old code of the UniversityOfAlberta. 
Contains a dealer class which might be good for some inspiration (didn't look 
into it
yet). Meercat seems to be the successor of the code.

http://www.deducer.org/pmwiki/index.php/pokermisc

By the way: on this site also too very good limit heads-up bots (FellOmen + 
INOT) are
open-sourced.

Original comment by bluegasp...@gmail.com on 16 Mar 2010 at 11:45

[GoogleCodeExporter]

Should the Dealer really handle a GameDescription? What about if we want multi 
table
tournaments. Wouldn't we need multiple Dealers? 

I think a better way to do this might be to make an Interface Tournament which 
can
then be implemented as Single Table Tournament which takes in its constructor a
GameDescription.

I'm not even sure a GameDescription makes sense in this case, each tournament, 
ring
game etc. would have different requirements for its description so it may just 
make
sense to leave those for the constructor.

For example: A tournament would require a list giving the payout structure, 
Players,
blind levels & hands per level. While a ring game would require Players, blind
levels, minimum bankroll, etc.

Original comment by schatzbe...@gmail.com on 17 Mar 2010 at 12:00

[GoogleCodeExporter]

I think of a Dealer like in real live: just shuffling cards, asking for blinds,
showing flop/turn/river.

So actually a Dealer-class would just look for the blindlevels and after how 
many
hands the the blinds increase (-1 for cashgames, as blindlevel never changes). I
think it's ok for a Dealer-class to read this values from a GameDescription 
directly.

Initial bankrolls are set when the game begins, so the dealer doesn't need to 
look at
minimum-bankrolls and the like.

It's also ok to have multiple Dealers and one GameDescription in a
multi-table-tournament scenario. 

I think we should start easy, introducing abstractions at the time when they are
needed and when we get a better picture of how the various parts should 
interact.

Original comment by bluegasp...@gmail.com on 17 Mar 2010 at 12:23

[GoogleCodeExporter]

I see the dealer as being useful on a per-hand basis. Each hand the dealer will
shuffle/deal cards, ask for actions, collect blinds, give winnings, update the
GameInfo, etc. It can get information like blind level, where the button is, 
from the
GameInfo.

So I think the Game (be it Tournament or RingGame) should change blind levels, 
set
initial bankrolls, seat the player. And then give its Dealer (or Dealers) the
PublicGameInfo, Players and GameObservers and tell it to playHand(). If we want 
to
configure how the Game changes through GameDescriptions then thats fine. 

Original comment by schatzbe...@gmail.com on 17 Mar 2010 at 12:53

[GoogleCodeExporter]

Ah - ok - so if one has a higher 'FloorAssistant'-class :) (ok, we could also 
call it
'Game' *g*) who tells the Dealer to change the blinds, moves players in a 
multitable
tourney and pays the payouts ...

Yeah I like that. Makes the Dealer-class more concise.

Original comment by bluegasp...@gmail.com on 17 Mar 2010 at 10:25

[GoogleCodeExporter]

Ok, we're agreed then. I'll take over this since I'm also working on 
PublicGameInfo
and PublicPlayerInfo and they're all related.

Original comment by schatzbe...@gmail.com on 17 Mar 2010 at 7:22

• Changed state: Started

[GoogleCodeExporter]

can u show the basic interface of the Dealer? one thing i'll need for the GUI 
is the
progress bar support(long running tourneys/operations should show their 
progress)
i.e. the method Dealer#playerTournament(GameDescription, IProgressMonitor)
and u'll have to update it after each game and check if the User cancelled the
tournament altogether.
once i have a basic GUI u will have a good example of what i'm talking about.

Original comment by absolut...@gmail.com on 18 Mar 2010 at 8:28

[GoogleCodeExporter]

I haven't started on it yet as I need to finish the GameInfo stuff first.

Its important to note that the Dealer handles each hand individually. The Game 
class
would be responsible for the differences between tournaments or cash games. The
Dealer just asks for actions from players, collects blinds, deals cards and 
gives out
per hand winnings (eg who wins what in the pot).

Original comment by schatzbe...@gmail.com on 18 Mar 2010 at 8:38

[GoogleCodeExporter]

Since GameInfo is taking me longer than expected and due to work picking up I 
will
remove ownership of this task. Feel free to get started on it whenever. I will 
do it
once GameInfo is done though if no one else gets to it.

For reference I feel that most steps should occur in the GameInfo part and the 
dealer
should more or less just be responsible for keeping the game moving along and 
linking
between the players, actions and the gameinfo.

Original comment by schatzbe...@gmail.com on 22 Mar 2010 at 3:25

• Changed state: Accepted

[GoogleCodeExporter]

So I'll be starting on this one.
The dealer will have a method for playing one round, moving the dealer button, 
making
players post their blinds, give them their hole cards, asks for their actions 
and
informs the GameInfo. It also deals community cards after each round.
It will use a 'Deck' class which I'll write on the fly.

Original comment by bluegasp...@gmail.com on 23 Mar 2010 at 8:59

• Changed state: Started

[GoogleCodeExporter]

commited first version of the Dealer - its not always easy to decide which
functionality should be in the Dealer class and what in the GameInfo. 
Feel free to move parts.

As its very difficult to see/debug what is actually going on in the game, I'll 
be
implementing the GameObserver events, so that with the HistoryWriter one can 
easily
see what happened.

After that I'll decide if the Dealer can be considered finished.

Original comment by bluegasp...@gmail.com on 24 Mar 2010 at 9:38

[GoogleCodeExporter]

My thought is to make the Dealer responsible for asking for actions, making sure
these actions are valid, and then asking for the next action. The GameInfo will
subtract chips, end the round, etc. The dealer just has to figure out that its 
time
to deal more cards, or do a showdown, or start a new hand. But feel free to do 
it how
you want.

Original comment by schatzbe...@gmail.com on 25 Mar 2010 at 12:34

[GoogleCodeExporter]

I guess its exactly like that now - showdown is not handled yet as you wrote 
that you
wanted to handle it in the GameInfo.

Original comment by bluegasp...@gmail.com on 25 Mar 2010 at 10:27

[GoogleCodeExporter]

I set this to finished - test was written and (except the missing showdown) this
seems to be working fine

Original comment by bluegasp...@gmail.com on 26 Mar 2010 at 1:06

• Changed state: Done