Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Poker  RSS feed

 
Gavin Tranter
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
Well I got the Killer Java Games book, and guess what decided to write a game, I just wanted to test out one of the graphics techniques suggested, that of having one graphics file with a strip of your sprites in.

Anyway for one reason and another, basic lack of imagination and not wanting to do animation just yet, I decided to pick on Poker. I know the rules etc and thought it might be fun for the later network parts of the book.

Thats where the problems started rather then this being a graphics example its now turned into a war over how I computationally decided which hand in a game is the winning hand(s).

So I was wondering, if any of you guys had any pointers? I can curremntly considering this is a calculation I do as each card is delt. If this was a real system it is a calculation i could off load onto the client nad have it report back, so I am not worried about performance.

for example you get delt your two hole cards, it decides what you have say pair of 10's.
The flop gives you a 10, 9, J, so now you have 3 of a kind and so on.

I mean this is solvable obivously. Its not that I want you guyes tgo solve it, just some advice might, or perhaps pointing out how deceptivly simple poker is and i should picked something else like solatire or some such

G
 
Kyle Morgan
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm assuming you already have a Card class. If so, then you could (if you haven't already) create a Hand class that consists of 7 cards (2 + the 5 community cards). The Hand class could implement the Comparable interface, and you would put all your logic into the compareTo() method. It would then be very easy to decide which hand is the best among many players.
 
Gavin Tranter
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I do have a Card class, dealer class, table class (dont ask), Enum for the cards (Hearts Clubs etc).

I hadnt considered a Hand class with a comparable. hmmm.

Its more the logic of figuring out what each hand is, then which is the best espically if both have strights or flushes, pairs etc are fairly easy cases, (Flushes are going to be the hardest i think).
I think I see how having a hand class might solve a lot of the problems, as now I am looking for the best 5 cards out of 7.....

I was thinking about things like sets and collections, perhaps i was thinking to liturally and not abstract/"problem domain" enough.

Thanks for the pointer, I will get back to you if i get it to work
G
[ February 20, 2007: Message edited by: Gavin Tranter ]
 
Gavin Tranter
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Kyle I think that suggest of a Hand class has opened things up, also looking at things from the point of view of the table rather then the player helps too.

Also each one hand is one of a limited subset, and some of the hands are aggregations/composites of other hands, for example a full house is basicly three of a kind and a pair.

Not saying this will work, but I am seeing a hint of a solution now
 
fred rosenberger
lowercase baba
Bartender
Posts: 12440
42
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
off the top of my head, i'd probably write a method for each 'type' of hand. write a method to test for a straight, then a method that tests for a flush. if both these return true, then you know you have a straight flush.

make your test for a pair return false if you actually have trips (or 4 of a kind)- i.e. 10, 10, 10, 7, 2 will return "false" for a pair, but "true" for trips. then, a full house will be a hand that returns true for both of these.
 
Gavin Tranter
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
This is something along the lines that I am thinking, I am thinking each hand will be a comparable class, where things like a full house will be an aggregation of the hand types that make it up.

Flush I have decided will be a comparator, as it is a special case, working with suit rather then rank, the comparator will be used for flush and straight flush, straight flush being a special case of straight.

As each hand knows how to test for itself and compare itself to another hand of the same rank, we should be fine.
It is pretty much a brute force route, and this is where the most experimentation will be had.
Each hand testing for itself will make things easier to maintain, but I still think there are issues, (like you said trips also containing one pair, another aggregation perhaps), maybe a controllor will be needed to maintain this sort of thing, along with dealing with what hands are available from the community cards.

I think the approach you guys have been putting forward is a good one, and it has motivated to have a go at this project again, pity i have no time til teh weekend.

It would be nice if there was a PokerHand collection, but this would just be hiding all the hard work, perhaps this is a project I should work towards, if we made it a Card collection, then we could extend to Poker, and then the various forms of poker, perhaps to other games in the future.

Poker is deceptivily simple, you would think somebody who plays the game would know this

G
 
Kyle Morgan
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Be sure to check for more specific hands before more general hands. For example, a full house would be a more specific hand than a three-of-a-kind or a pair. Both a isFullHouse() and a isThreeOfAKind() method would return true if it was a full house, so check for the full house first. And remember that if there is a straight and a flush in one hand, it's not necessarily a straight flush since there is seven cards.
 
Kyle Morgan
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's always better to write code in a more OO way. It may be a slow start, but it makes things easier in the long run.
 
Gavin Tranter
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Its a good point, when I started the project I did in an OO way as I wanted to use generics and the collection frame work, so I have a card class and an enum of card suits, and a player object.

But when it came to trying to do the code for deciding who has one, all the OO went out of the window, and I must have spent a week hacking around various ways.

I think along side the lack of OO in that part of the project was the focus on the player, rather then the table.

G
 
Garrett Rowe
Ranch Hand
Posts: 1296
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What I love about poker is that there are so many different variations many of which have different but similar rules for dealing, betting, and scoring of hands. Maybe in the future you could extend your poker program to be able to handle some subset of these using the same general engine. I'm not saying your project is going that far, but if it does, you'll be glad you thought of the object oriented side of things in the beginning. Being able to re-use an interface and get different behavior based on run-time decisions is a powerful thing.
 
Gavin Tranter
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well thats what I have in mind. When I started the project its purely to see if i could make use of the sprite graphics technique, which i havent even tried out.
But then I identified I wanted to make use of Colelctions and generics as I had no experience of Java 5, and after that I thought it would be nice if i was able to plug other poker games in. I just know how to play one, but I thought it might be nice.

Then I hit the snag of figuring out who had what hand and the "model" was out the window, but I think I will bring it back "inline", and have a proper think of who these things well go together.

Currently the Dealer object has control of the type of game, he deals the hole cards and then the community cards, I have a hold 'em dealer that implements/extends this, but i dont think my original Dealer is generic enough, mostly because I am unsure of the rules controling the other types. So the generic dealers methods reflect a hold 'em view of poker.

I think once I have the hand evaulator working, I will go back, and figure out how the model will work, and what patterns might help me to achieve this. Oh then turn it into an actual game that can be played rather then watched.

Diffently a bigger project then I entended when I started, which has kinda pushed my other projects out :S

G
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!