Embed Size (px)
Citation preview
Online Poker Game
SOS 10
Dave Harnett
0225878
Supervisor: Dr. Seamus O Shea
Department of Computer Science and Information Systems
University of Limerick
B.Sc. In Computer Systems
2
This work is dedicated to the memory of my father, Patrick Harnett.
3
I wish to acknowledge the help and contribution of the following individuals.
Mam, Pat, Ita, Moss, Anne Marie and Kate, for all their support and
encouragement.
Paddy and Jack, for making things a little more interesting.
Seamus O Shea, for all his help, patience and faith.
The CSIS faculty and staff, for always looking out for me.
Michael Quealy, with whom you should never play poker.
And Noreen, for everything.
4
Declaration
This thesis is presented in partial fulfillment of the requirements of the degree of B.Sc. Computer
Systems at the University of Limerick.
It has not been submitted in whole or part to this or any other university for an academic award.
Unless clearly indicated in the text, it is entirely my own work.
5
Abstract
The objective of this project was to create an open-source, client-server
multiplayer java based poker application. It was to be sufficiently flexible
to allow the implementation of many different variants of the game. It
should also provide a simple interface to the definition of the variants, so
they could be written by third parties not familiar with all of the code.
The result here was a complete framework, and an implementation of one
popular variant – Texas Hold ‘Em. Adding new variants requires the
writing of an implementation of one interface (three functions), and can be
done in a matter of hours.
A solution was found to the major computational problem – evaluating the
players’ hands. It allows more than 10,000 such evaluations to be
performed per second, and uses >200Kb of memory.
6
1 Introduction ..................................................................................................................................... 8 1.1 Outline ..................................................................................................................................... 8 1.2 Motivation................................................................................................................................ 8 1.3 Objectives ................................................................................................................................ 8 1.4 Notes ........................................................................................................................................ 9 1.5 Chapter Guide .......................................................................................................................... 9
2 Background ................................................................................................................................... 10 2.1 Outline ................................................................................................................................... 10 2.2 The Game of Poker ................................................................................................................ 10
2.2.1 Gameplay........................................................................................................................ 10 2.2.2 Hand Values ................................................................................................................... 11
2.3 Key Terms.............................................................................................................................. 11 2.4 Variations of Poker ................................................................................................................ 12
2.4.1 Texas Hold ‘em .............................................................................................................. 12 2.4.2 Omaha............................................................................................................................. 13
2.5 Summary................................................................................................................................ 13 3 Design ........................................................................................................................................... 15
3.1 Outline ................................................................................................................................... 15 3.2 Requirements ......................................................................................................................... 15
3.2.1 Environment ................................................................................................................... 15 3.2.2 Correctness ..................................................................................................................... 15 3.2.3 Efficiency ....................................................................................................................... 16 3.2.4 Integrity .......................................................................................................................... 17 3.2.5 Usability ......................................................................................................................... 17 3.2.6 Maintainability ............................................................................................................... 18 3.2.7 Flexibility ....................................................................................................................... 18 3.2.8 Testability ....................................................................................................................... 18
3.3 User Interface......................................................................................................................... 19 3.3.1 The ‘Table’ Window (Client side only) ......................................................................... 19 3.3.2 The ‘Lobby’ Window (Client side only) ........................................................................ 20 3.3.3 The Admin Window (Server Side only)......................................................................... 20 3.3.4 Other Windows (Client side only).................................................................................. 21
3.4 Summary................................................................................................................................ 21 4 Implementation ............................................................................................................................. 22
4.1 Outline ................................................................................................................................... 22 4.2 Server Components................................................................................................................ 22
4.2.1 Server Control ................................................................................................................ 22 4.2.2 Tables ............................................................................................................................. 22
7
4.2.3 Game Control (Server) ................................................................................................... 23 4.3 The Hand Evaluator ............................................................................................................... 25
4.3.1 The Problem ................................................................................................................... 25 4.3.2 Approaches ..................................................................................................................... 25 4.3.3 Solution........................................................................................................................... 26
4.4 Communications (Client & Server) ....................................................................................... 29 4.5 Client Components ................................................................................................................ 30
4.5.1 Client Structure............................................................................................................... 30 4.5.2 Client Interface (Graphics) ............................................................................................. 31
5 Evaluation ..................................................................................................................................... 34 5.1 Outline ................................................................................................................................... 34 5.2 Usability................................................................................................................................. 34 5.3 Performance ........................................................................................................................... 35 5.4 Communications .................................................................................................................... 36 5.5 Accuracy ................................................................................................................................ 37
5.5.1 The Evaluator ................................................................................................................. 37 5.5.2 The Shuffle ..................................................................................................................... 38
5.6 Summary................................................................................................................................ 38 6 Conclusion..................................................................................................................................... 39
6.1 Outline ................................................................................................................................... 39 6.2 Conclusions............................................................................................................................ 39 6.3 Further Work.......................................................................................................................... 40
Appendices....................................................................................................................................... 41 Appendix A – Code ..................................................................................................................... 41
Note ......................................................................................................................................... 41 The Evaluator .......................................................................................................................... 41 Server.Card.............................................................................................................................. 42 Server.Comms.Message.broadcastCardDealt() ....................................................................... 43 Server.Player ........................................................................................................................... 44
References ........................................................................................................................................ 45
8
1 Introduction
There are few things that are so unpardonably neglected in our country as
poker... Why, I have known clergymen, good men, kindhearted, liberal, sincere,
and all that, who did not know the meaning of a 'flush'. It is enough to make one
ashamed of one's species. – Mark Twain
1.1 Outline This chapter will detail the motivation behind the project, as well as its major goals. It will also
provide a brief guide to the chapters to follow.
1.2 Motivation Online poker as a commercial entity took a huge hit in 2006, after its boom years of 2003-2006.
Declining player numbers can be attributed in part to the loss of novelty factor for players who
began playing online in previous years. A more important factor however may be that lawmakers in
various jurisdictions have raised barriers to participating in online gambling, or have banned it
outright. The most significant of these actions was the signing of the “US Unlawful Internet
Gambling Enforcement Act”, which makes it illegal for US banking institutions to make payments
to companies which host internet gambling. This barrier has proved sufficient to deter most casual
US players, the industry’s largest market.
In light of these developments, the time for an open source, free to use poker application seems to
have arrived. A poker application which does not allow play for real money does not constitute
gambling, and as such will be legal worldwide. It also makes security and user trust less of a crucial
issue (the only way for a commercial application to gain trust is to be so successful that the
administrators cheating would be financially unwise).
While free (and indeed open source) poker applications are already available online, most are
written in c or pearl script, and their source code tends to the cryptic. I see an opportunity for an
easy to use, easy to modify application under a GNU (or similar ‘copyleft’) license to be very
popular.
1.3 Objectives The major goal then is to create a framework for an easy-to-use, easy-to-modify client-server poker
application, written in Java. This framework should be sufficiently flexible to allow a wide variety
of card games to be implemented.
9
Secondary to this would be to implement at least one popular variant of poker, to provide a proof-
of-concept, and as an example to point the way for other future developers.
Additionally, after my development work on the project has been completed, I would plan to
publish the code on sourceforge, and/or similar open source development forums. This would allow
other interested developers to make modifications and additions to the project.
1.4 Notes Throughout this text I will use words such as ‘he’, ‘him’ and ‘his’ when referring to users. This is
strictly for brevity, as I find the phrase ‘he or she’ rather cumbersome. The male form is chosen as
most online poker players are in fact male (although it is worth noting that the ratio of female to
male online players is greater than that of ‘real-world’ players).
1.5 Chapter Guide Chapter 2 relates to the game of poker itself, and can probably be skipped by readers who are
familiar with the game of poker, and its popular variants, Texas Hold ‘Em and Omaha.
Chapter 3 details the original design requirements envisaged for the project. It attempts to describe
what the application should do. Where possible, requirements will also be justified (i.e. why the
application must do a certain thing).
Chapter 4 relates to the implementation section of the project. It is concerned with how the stated
design goals will be met.
Chapter 5 describes the methods used in testing and evaluating the application and its components.
These evaluations will tell us whether and how well the implementation meets the original design
goals.
Finally, Chapter 6 will be dedicated to drawing conclusions about the project, and suggesting
further work which could be undertaken to improve the application.
10
2 Background
Serious poker is no more about gambling than rock climbing is about taking
risks. - Alfred Alvarez, writer and critic.
2.1 Outline We will begin with a brief discussion of the game of poker itself. While it may not be of interest to
those who are familiar with the game, it is a logical and necessary starting point. It also helps to
define the scope of a general poker-playing engine.
For the sake of brevity, this report will make use of some poker-related terms which are not self-
explanatory to non-players. These will be explained in full. This will aid in the reader’s
understanding of later chapters.
Two of the game’s most popular variations are also described. These are the most popular games in
commercial online poker applications, and will be the first to be implemented in my project.
2.2 The Game of Poker
2.2.1 Gameplay
Poker is a popular card game where players hold fully or partially concealed cards, and compete for
a common pot against each other. The right to deal cards rotates clockwise among the players (see
‘button’ in Chapter 2.3). Cards may be dealt either faced up or down, depending on the variant of
the game. One or more players must make forced bets (a ‘blind’ or ‘ante’), in order to create an
initial pot for which the players will compete. After dealing has been completed, the first of several
rounds of betting begins. Players’ hands are developed between rounds, by dealing extra cards, or
replacing cards already dealt.
During a betting round, if one player bets, all other players are required to ‘call’, ‘raise’ or ‘fold’. If
one player bets and none of his opponents choose to match him, he immediately wins the pot. This
allows bluffing to take place.
At the end of the last betting round, if more than one player remains, there is a showdown, in which
players reveal their previously hidden cards, and evaluate their cards. Typically, the last player to
raise is required to reveal his cards first. Other players may then reveal their cards in clockwise
order. The player who reveals the best hand according to the poker variant being played wins.
11
2.2.2 Hand Values
Name Description Example
Straight Flush 5 cards with values in sequence, of the same suit. 3S, 4S, 5S, 6S, 7S
Four of a Kind 4 cards of the same value. 5C, 5D, 5H, 5S
Full House 3 cards of the same value and 2 cards of the same value. 3D, 3S, 3H, 2C, 2D
Flush 5 cards of the same suit. 3D, 5D, 8D, JD, KD
Straight 5 cards with values in sequence. 3S, 4H, 5S, 6D, 7D
Three of a Kind 3 cards of the same value. 3D, 3S, 3H
Two Pair 2 cards of the same value and 2 cards of the same value. 3D, 3S, 2C, 2D
One Pair 2 cards of the same value. 3D, 3S
High Card A single card. AS Table 2.1
Poker hand categories and their relative values (descending)
The relative values of these hand categories are different in some variants of the game.
A hand of a higher category beats one of a lower category. With two hands of the same category,
the hand with the higher card values generally wins. Eg: A pair of Kings beats a pair of Jacks.
2.3 Key Terms All In: If a player is faced with a bet which he has insufficient chips to call, he may declare
himself ‘all-in’. He may now hold onto his cards for the remainder of the deal, but
he may not win any more money above the amount of his bet. This means that a
“side-pot” must be created to accommodate any additional betting which the “all-
in” player is not eligible to win.
Ante: A forced bet paid by all players before dealing begins.
Blind: A forced bet, paid into the pot before dealing begins. Usually, one or two players to
the dealer’s left must pay blinds.
Bluff: Betting so as to suggest that one has a stronger hand than one actually has. The
purpose of bluffing is to force other players to fold.
Button: This is used to indicate which player is the dealer, particularly in casinos/online
games where the players do not literally deal the cards.
Call: To match a bet or a raise.
Cash Game: As distinct from a ‘tournament game’, players may join or leave a cash game at any
time. This project will deal only with ‘cash games’.
Cashing In: The act of purchasing chips for use at a particular table.
Cashing Out: The act of converting one’s chips back to cash before leaving a poker table.
Check: If no one has opened a round of betting, one may ‘check’. i.e. Call a bet of zero.
12
Dealer: A ‘title’, which rotates clockwise around a table’s players. Its significance varies in
different games. Obviously, in informal games the dealer also deals the cards!
Fold: In response to a player’s bet, other players may fold, indicating that they will take
no further part in this game. They forfeit any chips which they have already
committed to the pot. This is usually communicated by moving one’s cards toward
the centre of the table.
Limit: Betting limits apply to how much a player may bet or raise.
No Limit: A player may open or raise any amount up to his/her total chip value.
Fixed Limit: A player can raise only a fixed value. This does not prevent re-raises. The limit is
usually raised for the last one or two rounds of betting (to allow bluffing).
Pot Limit: A player can raise only the current value of the pot.
Seat: The position at which a player is located. Seats are described with reference to the
dealer. In most variants, being seated just to the dealers right confers an advantage,
since this player is the last to act in the first round of betting.
Spread Limit The maximum permissible raise increases at each round of betting.
Post: To join a cash game which is already in progress, a player may have to ‘Post’
(match) the big blind. This is to prevent players from temporarily leaving a table, or
switching tables in order to ‘miss’ a blind.
Table: A poker table consists of a group of players in competition with each other. A table
has a particular set of rules, limits etc…
2.4 Variations of Poker
2.4.1 Texas Hold ‘em
Before any cards are dealt, two players to the left of the dealer must pay the "Small Blind" and "Big
Blind" into the pot. The big blind is twice as much as the small blind.
Each player is given two cards face down. These are called the players’ "Hole Cards".
Once all the players have their hole cards, the betting starts. The player to the left of the Big Blind
player starts the betting. The lowest amount that can be bet is the amount of the big blind. The most
a player can raise is determined by the type of the game’s “limit”. Each player in turn may either
"Call" (pay the minimum), Raise, or "Fold" (quit the hand). This action keeps going around the
table until each player has called or folded his hand.
After the first turn of betting is over, the dealer lays three cards face up on the table. This is called
the "Flop". These three cards are "community cards". This means they are used by every player in
the game along with the two hole cards each player has. After the flop, another turn of betting takes
13
place. Players may "Check" if no player before them in the turn has bet. If everyone checks, or if a
player bets and all the others call or fold, then the turn of betting is over.
Next the dealer lays another community card face up. This card is called "the turn". Another series
of betting comes after this.
Finally the dealer lays the last community card, known as "the river". This card is again followed by
a turn of betting.
With the five community cards (which are collectively knows as “the board”) and their two hole
cards, each player makes the best 5 card poker hand he can. The player with the best poker hand
wins the round and the pot. If two or more players have the same hand, those players split the pot
evenly. If one person bets and all other players have folded, the hand ends then and that player wins.
Note that Texas Hold ‘em can be played with any of the four types of betting limit. In the case of a
fixed limit game, the higher limit is used for the last two rounds of betting.
Texas Hold ‘em uses a standard 52 card deck (no jokers), and usually has a limit of eight players.
However it is not unheard of to use a 104 card deck (two standard decks shuffled together) to
accommodate more players. (Wikipedia, 2007)
2.4.2 Omaha
Omaha is the same as Texas Hold ‘em, except that players are dealt four “Hole” cards rather that
two. However, when making their best 5 card hand, a player may only use a maximum of two of
his/her “Hole” cards.
2.5 Summary The purpose of this rather long-winded discussion of the game’s language and variations is to
highlight the flexibility required to accommodate different game types in a single program.
Note that to determine a winner for a game of Texas Hold ‘em, the program must choose the best
five-card hand from a pool of seven available cards. This is further complicated in Omaha, by the
fact that nine cards are available with restrictions on which cards may be included in the same
selection.
14
Also note that the program may need to determine a “runner-up” for a given game (see the
description of the “all-in” rule). In fact, with a game of eight players, there can potentially be seven
distinct pots, each with a different set of players competing for it!
15
3 Design
The gambling known as business looks with austere disfavor upon the business
known as gambling. - Ambrose Bierce, journalist and writer.
3.1 Outline This project’s design is logically split into two major components: server and client. The server
controls everything; tables, games, players etc… The client’s primary purpose is to allow the player
to passively view the match. The client may only reply to the server’s communications when
explicitly asked a question by the server (e.g. Does your player wish to Call, Raise or Fold?)
.
The system requirements are divided according to Galin’s (2004, p.38) software quality factors’.
The categories used here are a subset of those he lists.
3.2 Requirements
3.2.1 Environment
All software shall be written in Java, and shall operate in a windows XP environment. The eclipse
IDE will be used throughout, as this is the only fully-featured IDE with which I am familiar that
supports Java development.
It shall operate on a client-server basis, where the server program may run on a single machine, and
instances of the client may access the server from any machine with unrestricted internet access to
the server.
The server shall listen for client communications on port 80, as this is least likely to cause issues
with client side firewalls.
The client application shall be presented as an executable .jar file, which shall be compatible with
Sun’s Java Runtime Environment 1.5 or greater.
3.2.2 Correctness
The project shall not support gambling of any kind. For the purposes of keeping score players will
be assigned a number of ‘credits’, integer units with no monetary value. If a player loses all of their
credits, more will be assigned to them. As such, all amounts seen and entered by the client shall be
integers.
16
All normally visible game events shall be displayed in both graphical and text formats on the
client’s screen, where appropriate. Such events include cards being dealt, chips being moved,
players betting etc… One exception is that the deck will be shuffled invisibly before each game is
dealt.
When the game needs a decision from a player, the player’s options will first be established by the
server, then relayed to the client, and displayed to the user by an ‘option’ pane. Such options may
take the form of boolean (pay blind/fold), multiple-choice (fold/call/raise) or range (amount to raise)
requests. The client shall prevent the player from entering an invalid/illegal response.
The server shall be responsible for dictating and enforcing the rules of the game. Any invalid/illegal
requests or responses from a client shall be ignored, or altered to make them legal. This will prevent
altered versions of the client application from allowing players to cheat.
The server shall send regular ‘keep-alive’ messages to each connected client. If a client does not
respond to two consecutive ‘keep-alive’ messages, the player will be removed from his or her table.
The game’s evaluator shall accurately assign relative hand values to each of the 2,598,960 possible
5-card hands, according to the normal Poker hand value rules. All evaluation shall take place on the
server side.
3.2.3 Efficiency
The server shall support up to 50 concurrent users and 10 concurrent games while operating on a
modern desktop machine (2GHz processor, 1GB RAM).
The main evaluator shall be capable of performing at least 5000 5 card evaluations per second under
half of the load described above.
Under this load, update time (time between Client A responding to a decision request and Client B
being informed of this decision) shall be no more than 2 seconds (not including network latency).
Visible hand evaluation time (time between all players showing their cards and the server declaring
a winner) shall be no more than 5 seconds. This operation may begin in the background before cards
are shown in order to achieve this goal.
17
When a player is asked for a decision, he or she will have a limited period of time in which to
respond. If a response is not received, the server will ‘fold’ that player’s hand. This is to preserve
game continuity.
3.2.4 Integrity
Regular players shall not be permitted to create or administer tables. This shall only be possible for
those with physical access to the PC which is running the server. A password-protected remote
administration option may be added at a later date.
The server shall not remember players between sessions. This means that a player starts with a clean
slate whenever he or she logs on.
A player’s client will be mapped to a particular IP/port combination for the duration of the session.
Cards which are dealt to a player ‘face down’ will only be sent to this client. All other game
communications will be broadcast to all players at a table.
The server controls the game state at all times. It shall accept communications from a client only
when that client has been sent a request for a player decision. The only exception to this rule is that
a player may leave a table, or quit the game entirely at any time.
The server shall have the ability to keep a communication log in order to detect player exploits or
other misconduct.
3.2.5 Usability
The project assumes that users have a basic familiarity with PCs. This includes the use of a mouse,
keyboard, and basic form elements such as text fields, radio buttons etc… It is also assumed that the
user is familiar with the variants of poker which is to be played.
The client shall provide a graphical simulation of the player’s virtual ‘poker table’, which shall
show all game events. This information will also be shown in a scrolling text box.
Three types of help windows will be available to the user:
• Program Specific – How to request credits, how to join a table etc…
• Poker General – Relative values of hands, terminology etc…
• Poker Specific – The rules of Texas Hold ‘em, Omaha etc…
18
Once 5 cards are available to the player, the client shall tell the player (in text format) his best 5
card hand. This requirement is subject to adequate performance from the hand evaluation algorithm.
3.2.6 Maintainability
The server shall record any exceptions/errors to a log file.
Every function shall communicate its actions to a single ‘test function’ whenever it is called. If the
‘test function’ is enabled, it will record every function call to command line/file, allowing for on-
the-fly diagnosis.
3.2.7 Flexibility
The server shall be coded so as to allow new variations of poker to be supported. This means that
new variations may be added after the server’s initial launch.
The client shall require little or no modification to allow new variations of poker to be supported.
A single server may run several tables with different game types and different betting limits
simultaneously.
3.2.8 Testability
The development shall include basic regression testing for all major elements. These tests will be
run and updated throughout the development process. These tests will make use of the ‘test
message’ system to ensure all the low level functions and objects are also behaving as expected.
A stand alone application shall be created to test the performance of the hand evaluator. It shall
generate random 5-card hands, pass them to the evaluator, and count the number of evaluations
completed per second.
A standalone application shall be created to test the accuracy of the hand evaluator. Is shall pass
each of the 2,598,960 5-card hands to the evaluator, and ensure that each output matches the
expected one.
3.3 User Interface
3.3.1 The ‘Table’ Window (Client side only)
Figure 3.1 Prototype of the ‘Table’ window Created using NetBeans, Macromedia Freehand,
Card images courtesy of SourceForge.net
Players will spend most of their time looking at this window. It should convey all the information
and controls that the user requires to play the game. Note that the ‘card table’ graphic is dynamic,
but not interactive – all of the controls are available below the graphic, and will only appear as
necessary.
The large text pane on the right will show the player text notices of all game events, as well as
messages from other players at the table. He or she may also post messages using the small text
field and the ‘send’ button below the large pane. Messages will be broadcast to all players at the
table: private messages will not be allowed in order to discourage collusion between players.
The stacks of chips visible on the table will be accurate, I.e. the visible chip stack will agree with
the number beside the stack.
19
20
Note the ‘Wallet’ and ‘Stack’ values toward the bottom of the window. The wallet amount is the
Player’s total credits excluding those which are in chip form at this table. The stack is the number of
credits which the player may bet with at this table. The reasons for this distinction are as follows:
There may be a limit on the amount of credit which a player may bring to a table. This is to allow a
level playing field for all players.
A player may not wish to ‘risk’ all of his or her credits on a particular game. (See the ‘All-in’ rule
Ch. 2.2)
3.3.2 The ‘Lobby’ Window (Client side only)
The lobby window shall appear in the client once a player has successfully logged onto a server.
The lobby shall show the following information:
The player’s username
The player’s wallet
A list of all the server’s tables
Details of a selected table (Occupied/Total seats, game type, limits, etc…)
The lobby window shall allow the following operations:
Request more credits (Provided the player has fewer that 200 credits remaining).
Join a table (Provided the table has vacant seats and the player has sufficient credits to join).
When a player requests to join a table, he or she will be asked how many ‘chips’ he wants to buy.
Chips are credits which may be used at a particular table. This process is known as ‘cashing in’.
Each table will have its own minimum and maximum cash-in limits.
3.3.3 The Admin Window (Server Side only)
The admin window shall allow existing tables to be deleted and created. When a table is created, the
following parameters must be supplied:
The table name.
The game type
The limit type
The limit values (For fixed or spread limits only)
The Blind (or Ante) values.
21
3.3.4 Other Windows (Client side only)
When the client is launched, a small dialog box will appear asking for the address of a server. When
the address is supplied, the client will attempt to establish a connection with this server. If it is
unsuccessful, the user will be shown an error message and returned to the first dialog.
Assuming connection is successful, a second dialog box will appear. This box will ask the user to
supply a username. Provided this username is not already in use on the server, the user will be
presented with the main lobby screen, and granted 1000 credits.
3.4 Summary The headline design goals for this project are as follows:
Flexible table/rule coding, to allow additional game variations to be added.
Efficient implementation, to provide a satisfactory gaming experience to many simultaneous users.
Strong server monitoring and logging functions, to aid maintenance, and detect exploits.
22
4 Implementation
I must complain the cards are ill shuffled till I have a good hand. ~Jonathan
Swift
4.1 Outline The purpose of this chapter is to describe the operation of the application, as clearly and succinctly
as possible. This description will be carried out (for the most part) at the highest level possible. If
greater detail is required, please refer to Appendix A, where I will include any code which I feel
may be helpful.
4.2 Server Components
4.2.1 Server Control
The server’s control class is the creator of all the program’s main objects:
Players
Tables
Rule Sets
Limit Sets
Each instance of Player represents an active connected client, and contains a reference to that
client’s remote interface, so commands and information can be communicated to it.
Instances of Table, LimitSet and RuleSet are created statically, in the server’s main() function. Each
table is passed a name, a LimitSet and an instance of an implementer of RuleSet (e.g. Holdem,
Omaha). One instance of LimitSet may be shared by many tables. However, a new instance of
RuleSet must be used for each table, as each instance of ruleset launches its own thread.
The control class also implements a remote interface which allows clients to initiate communication
with the server (See Chapter 4.4 - Communications)
4.2.2 Tables
The table class contains all the data and functions required to operate the mechanics of the game. Its
member variables include:
The Deck – a stack of objects of type card.
The Board – an array to store ‘community’ cards.
23
The Burn Pile – an array to store discarded cards.
Players[] – all players seated at this table.
Button – a pointer to the player who currently is said to hold the dealer button.
Rules – an implementation of RuleSet, which will be used to ‘drive’ the table.
Limits – the players betting limits, the entry chip limits, the antes/blinds required etc…
Pot – an integer representing the current size of the pot.
It also contains member functions for all necessary operations in the game of poker. Examples
include:
shuffleDeck() – causes the deck stack to be shuffled.
dealCard(Player p) – pop a card off the top of the deck, and ‘give’ it to the player.
collectCards() – gather all cards from players, the burn pile and the board and return them to the
deck.
advanceToPot(Player p) – add a player’s ‘advance’ to the pot.
awardPot(Player p, int amount_won) – ‘give’ a certain amount from the pot to a player.
4.2.3 Game Control (Server)
Each table will be passed an object whose super-type is RuleSet, which can be thought of as an
interface. Examples of the functions it contains:
initTable() – Initializes the table before play begins, populates the deck etc.
welcomePlayer() – Give an inactive a chance to join the next game – collect posts, if necessary.
bettingRound() – Referee a round of betting, according to the variant’s rules.
awardPot() – Decide who wins what, based on the game’s rules, and players’ hands.
Games are controlled by implementations of the abstract ‘RuleSet’ class. Each implementation
corresponds to a variation of poker. These classes will drive the server’s decision making, and
determine ‘what happens next’ at any given table. Ruleset cannot be static – a new, identical
instance will have to be created for each table, since ruleset will contain the thread that ‘drives’ the
table. Inheritance can be used to minimize redundancy, where common steps can be found in
different variants e.g. betting works in exactly the same way in both Hold ‘em and Omaha.
Figure 4.1 Class Diagram of the Client-Server Architecture
24
25
4.3 The Hand Evaluator
4.3.1 The Problem
For a normal 52 card deck, there are 2,598,960 possible unique 5-card hands. However, by the
normal poker rules, there are only 7,462 possible hand values. For example, there are 4 hands which
are considered a ‘royal flush’ (Clubs, Diamonds, Hearts and Spades), all of which have the same
value. So the problem is to create a function which accepts a hand (or 5 cards) and returns a value
from 1 to 7,462 corresponding to that hand’s value, according to the normal values (Where 1
represents the best possible hand – royal flush, and 7,462 represents the worst – 7 high).
4.3.2 Approaches
The most straightforward approach is to use a lookup table, containing the value of each of the
2,598,960 possible hands. On closer inspection, this approach is fraught with difficulties. Firstly,
how does one map a hand to a unique index for the table? The best solution is to assign each of the
52 cards to a distinct prime number, then multiply each of the 5 numbers to produce a unique
product for that hand. The downside is that this results in a huge index (from 2,310 to
784,484,653,991). Given that each entry will need to be at least 13 bits in length (to accommodate
hand values from 1 to 7,462), the memory requirements for such an approach would be colossal
(~1.15 TB at best!).
However, given that most elements in such a lookup table would be empty, a hash table presents
itself as a more realistic option. Assuming minimal perfect hashing is achieved, lookup will only
take 1 probe, and memory requirements will be tolerable (~4.1 MB at best). Even imperfect hashing
with a load factor of .75 results in acceptable figures (~5.5 MB at best).
A more elegant approach to the problem is to use recursion – compare each card against the others
to find cards of the same suit, the same value, or of subsequent values. However, such a solution
incurs a huge cost in terms of processor cycles. Also, the time constraints of the project mitigated
against the writing and debugging of such a complex algorithm.
The solution which I decided upon lies somewhere in the middle; breaking down the problem
sufficiently to allow very small lookup tables to be used, without necessitating excessive
computation or coding. The inspiration for this method came from Kevin L. Suffecool aka ‘Cactus
Kev’, whose ingenuity I cannot praise highly enough.
26
4.3.3 Solution
4.3.3.1 Representation
The key to this solution is to represent each card in a way which makes it computationally easy to
break down and compare:
|xxxb bbbb|bbbb bbbb|cdhs rrrr|xxpp pppp| Each character in this field represents a single bit, in a 4 byte representation of the cards. It breaks
down as follows:
• p= (Integer) prime number representing the card’s rank (two=2, three=3, four=5,...,ace=41).
• r= (Integer) rank of card (two=0, three=1, four=2, five=3,..., ace=12).
• cdhs= (Boolean Flags)suit of card (bit turned on based on suit of card).
• b= (Boolean Flags) bit turned on depending on rank of card
• x= empty.
To give some examples:
|xxxA KQJ10 | 9876 5432 | C DH S r r r r |xxpp pppp|
2 of Spades = |0000 0 0 0 0 | 0000 0001 | 0 0 0 1 0010 | 0000 0010| r=2, p = 2.
5 of Diamonds = |0000 0 0 0 0 | 0000 1000 | 0 1 0 0 0101 | 0000 1111| r=5, p=7.
King of Hearts = |0000 1 0 0 0 | 0000 0000 | 0 0 1 0 1101 | 0010 0101 |r=13, p=37
This two-byte representation will be created uniquely by each card’s constructor function. These
short representations, rather than the whole card objects will be passed to the evaluator, to save on
memory and computation.
4.3.3.2 Step One
By representing each card in this way, we can make certain broad evaluations of the hand using
simple bitwise operations. For example, by taking the ‘cdhs’ field from each of the 5 cards and
performing a bitwise AND, we can determine if the hand contains a flush (i.e. if all 5 cards are of
the same suit, the result will be non-zero).
Knowing that all cards are of the same suit, knowing which suit that is becomes irrelevant. This
means that to find a value, we need only concern ourselves with the ranks of the 5 cards. We can
also say that each card will have a distinct rank, since all cards are of the same suit. Therefore we
can use a bitwise AND of the ‘b’ field to make a relatively small unique lookup key
27
(2,3,4,5,6 = 0000 0000 0001 1111 = 31 to 10,J,Q,K,A = 0001 1111 0000 0000 = 7,936). Then,
using Stuffecool’s flushes[] array (length 7,937 entries, or ~15.8 kB), we can determine the value of
any flush. This lookup can be skipped entirely if the initial ‘cdhs’ operation shows that a flush is not
present.
4.3.3.3 Step Two
If the previous step determines that we do not have a flush hand, we will proceed to searching for
Straight and High-Card hands. Both of these hand types require that each card has a unique rank.
The same key is used again (a bitwise AND of the ‘b’ field) against another of Stuffecool’s arrays,
unique5[] (again, of ~15.8 kB in length). If the result returned is 0, we do not have a Straight or
High-Card hand. If it is non-zero, then it holds the actual hand's distinct value. For example, a King-
High Straight has a bit pattern of 0x0F80, or decimal 3968. This means that unique5[3968] should
hold the value 1601.
So far, using two computationally simple bitwise ANDs, and one lookup, we have eliminated a little
over one third of all possible hands. If a value has not been found so far, the evaluator will proceed
to the next step.
4.3.3.4 Step Three
The final step will evaluate all remaining hands: those that derive their value from having cards of
the same rank (i.e. pairs, three of a kind, full house, four of a kind). To accomplish this, we will
multiply each of the cards’ ‘p’ fields to create a unique key, even if cards are of the same rank.
These keys will range from 2*2*2*2*3 = 48 (four twos with a three kicker) to 41*41*41*41*37 =
104,553,157 (four aces with a king kicker).
Stuffecool’s approach called for a pair of lookup tables and a binary search, to map this key to a
value, however I realized that a hash table could accomplish the same result in O(1) rather that
O(log n) (where n = 4888, the number of remaining values). This hash table, which has a load factor
of .5, uses approximately 18kB in memory, and causes my adaptation to run ~2.7x faster than
Stuffecool’s original.
So, by reducing the problem from one step to three, and at the expense of 3 bitwise calculations and
one array lookup, we have reduced memory requirements from ~5.5 MB to >50 kB.
28
4.3.3.5 Further Reading
The full source code for my evaluator is available in Appendix A.
4.4 Communications (Client & Server)
Figure 4.2
Genadi’s ‘RMI Spy’ Readout of client->server rmi calls in an active game
Communication will be handled by a ‘control’ class on both client and server side. Each control
class will be responsible for responding to communications initiated by the other side. The server
registers its control object with the RMI registry, Java’s RMI service, running on the server’s port
80. Clients, when connecting to the server, lookup it’s RMI registry for a copy of the server’s
control object, then pass it their own control object to the server. In this way, the server has a
reference to each client’s control, and each client has a reference to the server’s.
29
Figure 4.3
The RMI Communication Sequence
Consideration has to be given to client-server communications at all stages in development. While it
can be implemented by a single class in each program, it must be called from many different places
i.e. when a card is dealt to a player, everyone at the table needs to be notified, and the player in
question needs to be told (privately) what card it is. Server.Comms.Message will handle this work.
Examples from Server.Comms.Message can be found in Appendix A.
4.5 Client Components
4.5.1 Client Structure
The client possesses three non-trivial screens:
• InitDialog – allows a user to connect his client to a poker server.
• Lobby – allows a user to browse the server’s tables.
• Table – allows a user to view and participate in a particular game.
The client’s launching point is the ‘InitDialog’. Its primary purpose is to instantiate ‘control’, an
implementer of the clients remote interface (aka the client’s ‘remote control’). This screen contains
two text fields, one for the player’s desired username, and one for the address of the server to
connect to. It also contains a ‘connect’ button. When this button is pressed, it attempts to send a
30
reference to ‘control’ to the specified server (See Chapter 4.3 – Communication). Control
implements all of the necessary functions for the server to ‘drive’ the client.
Note: Refer to Figure 4.1 for an illustration of the client structure.
4.5.2 Client Interface (Graphics)
When communications are established, the ‘lobby’ screen appears. The lobby allows players to:
• View a list (in hierarchical tree format) of all the server’s tables.
• View his username and his ‘wallet’.
• Request credits for his ‘wallet’.
• View the details of a selected table.
• Join a selected table (where vacancies and rules permit).
Figure 4.5
31
The ‘Lobby’ Screen
When the user successfully joins a table, the ‘table’ screen appears. The table screen allows users to
view the play, and interact with the game.
Figure 4.6
The ‘Table’ Screen To the bottom left of the table graphic you see the elements which allow players to make decisions.
In this case, the player is about to raise 31. The text boxes to the right of the screen allow players to
chat with one another. You will note that there are two visible copies of the player’s cards. This is
because the cards on the table graphic can be quite difficult to read, particularly if a player is on one
of the ‘side’ seats.
The text to the bottom right of the screen shows the game’s current statistics. Note the ‘Best Hand’
element, which shows the best hand currently available to the player. This shows that the evaluator
is already working in the background.
The graphic for the table proved quite problematic. The oval shape required me to manually set
locations for every item which could appear on the table. It also meant that cards needed to be
rotated to fit correctly. In hindsight, I would have chosen a simpler (i.e. rectangular) shape, which
would have allowed a more mathematical approach to object placement.
32
Figure4.7
The difficulty of placing cards on an oval table!
33
34
5 Evaluation
[Poker] exemplifies the worst aspects of capitalism that have made our country
so great. - Walter Matthau, actor.
5.1 Outline
5.2 Usability The basic idea of thinking aloud is very simple. The test moderator asks his users to perform a test
task, but also asks them to talk to him while they work on it. The moderator asks them to tell him
what they are thinking: what they are trying to do, questions that arise as they work, things they
read. The moderator makes a recording of their comments or can just take notes. This is done in
such a way that you can tell what they were doing and where their comments fit into the sequence.
This technique was first documented by Lewis and Rieman
‘Think aloud’ user testing was performed in early May 2007. This was the first date when the client
was sufficiently robust as to allow such ‘hands on’ testing. Unfortunately this was also too late to
implement all of the changes which the results suggested. Some changes which were implemented
for final submission were:
The ‘bet option’ radio buttons are unselected when they appear. The submit button is disabled until
the user selects one of them. This is to prevent users accidentally submitting as soon as the options
appear.
Users select the amount to raise using a slider rather than a text box. In ‘real world’ play, users tend
to raise a certain percentage of their total chips, rather than a certain amount.
The animations (cards/chips being moved around the table) should be time dependant rather than
cycle dependant. Moves happened too slowly/quickly on some systems. The animations should now
appear smooth, and take a fixed amount of time on all systems.
35
5.3 Performance The most crucial function in terms of performance will be the hand evaluation module. The
performance of this module may affect many key decisions:
If it performs well, allowing more tables and players on a server may be considered.
If it performs well, hands may be evaluated ahead of time. This means telling a player the value of
his or her best hand before the end of the game.
If it performs badly, the evaluation may have to start ahead of time i.e. before players have turned
over their cards.
If it performs badly, some of the evaluation workload may have to be moved to the client. This
would mean a player’s client evaluating his or her own hand, then sending the results to the server
to be verified.
The evaluator’s performance was tested by recursively passing it every possible hand (given a
normal 52 card deck). By counting the time taken, we can determine the average number of
evaluations performed per second. Evaluation 1: 2c, 3c, 4c, 5c, 6c. value=9. category = Straight Flush
Evaluation 2: 2c, 3c, 4c, 5c, 7c. value=1599. category = Flush
Evaluation 3: 2c, 3c, 4c, 5c, 8c. value=1595. category = Flush
Evaluation 4: 2c, 3c, 4c, 5c, 9c. value=1581. category = Flush
Evaluation 5: 2c, 3c, 4c, 5c, 10c. value=1547. category = Flush
… … … … … … … … … … … …
Evaluation 125396: 2c, 10c, 8h, jh, 9s. value=7221. category = High Card
Evaluation 125397: 2c, 10c, 8h, jh, 10s. value=4354. category = One Pair
… … … … … … … … … … … …
Evaluation 2598959: 9s, js, qs, ks, as. value=323. category = Flush
Evaluation 2598960: 10s, js, qs, ks, as. value=1. category = Straight Flush
evaluation took 196 seconds = 13260 evaluations per second
Figure 5.1 A sample of the output from a performance test,
run on a 1.7 GHz mobile Celeron Processor. This test produced an average of slightly over 20,000 evaluations/second on my home pc (an AMD
2GHz processor). Note that this evaluation method incurs the overhead of creating each hand on the
fly, before passing it to the evaluator. With this in mind, the results demonstrate ample performance
from the evaluator.
This meant that:
All evaluation work can be carried out on the server side.
The evaluator could begin work ahead-of-time. i.e. a player’s ‘best hand’ could be evaluated and
shown as soon as he has 5 cards visible to him.
36
5.4 Communications I arranged an informal load test, with clients (i.e. friends) in UL, Castletroy, West Limerick and
Dublin. All were using different ISPs with different connection speeds: (HEANet T3, Imagine 1Mb,
Eircom 56Kb, and NTL 500Kb respectively. The server was located on my home computer, at the
end of a 3Mb Digiweb line.
End-to-end communication time was measured using Genadi’s ‘RMI Spy’, which allowed me to
track communications to and from each client. Pings were used to measure the inherent lag on the
connections.
Unsurprisingly, the 56Kb analog line proved to be the slowest in terms of response. However, given
the tiny amounts of information being sent per message (>500bytes), the communication times were
quite acceptable. For example, when the user of the Dublin client raised, the user of the 56Kb client
in limerick would have seen his raise less that a second later (including a combined lag of ~200ms).
37
5.5 Accuracy
5.5.1 The Evaluator
The evaluator’s accuracy was tested by recursively passing it every possible hand (given a normal
52 card deck). As each hand was evaluated, a note was made (automatically!) of what category that
hand evaluated to (i.e. if it was a pair, a straight, a flush etc…). A count was kept of how many
straights, flushes, etc were counted in total. By comparing these total figures with the correct figures
(available on Stuffecool’s site, or via a simple web search), we can achieve a reasonable degree of
confidence in the evaluator’s overall accuracy. Manually inspecting some of the evaluations on the
list also provided a basic sanity test.
Evaluation 1: 2c, 3c, 4c, 5c, 6c. value=9. category = Straight Flush
Evaluation 2: 2c, 3c, 4c, 5c, 7c. value=1599. category = Flush
Evaluation 3: 2c, 3c, 4c, 5c, 8c. value=1595. category = Flush
Evaluation 4: 2c, 3c, 4c, 5c, 9c. value=1581. category = Flush
Evaluation 5: 2c, 3c, 4c, 5c, 10c. value=1547. category = Flush
… … … … … … … … … … … …
Evaluation 125396: 2c, 10c, 8h, jh, 9s. value=7221. category = High Card
Evaluation 125397: 2c, 10c, 8h, jh, 10s. value=4354. category = One Pair
… … … … … … … … … … … …
Evaluation 2598959: 9s, js, qs, ks, as. value=323. category = Flush
Evaluation 2598960: 10s, js, qs, ks, as. value=1. category = Straight Flush
No of type High Card: 1302540
No of type One Pair: 1098240
No of type Two Pair: 123552
No of type Three of a Kind: 54912
No of type Straight: 10200
No of type Flush: 5108
No of type Full House: 3744
No of type Four of a Kind: 624
No of type Straight Flush: 40
No of type Unknown: 0
Figure 5.2 A sample from an evaluator verification test.
These tests showed the evaluator to be 100% accurate for any valid 5 card hand.
38
5.5.2 The Shuffle
The purpose of this test is to prove that the server can deal truly random cards. Now that we know
the evaluator to be accurate, we can use it to test the shuffling/dealing mechanism, using the
following steps:
Create a standard 52 card deck.
Shuffle the deck.
Deal 5 cards each to 8 virtual ‘players’, one at a time.
Evaluate each player’s hand.
Repeat steps 1-4.
As the number of hands dealt goes toward infinity, the hand value distribution should approach the
following percentages:
High Card: 1,302,540/2,598,960 = 50.1177%
One Pair: 1,098,240/2,598,960 = 42.2569%
Two Pair 123,552/2,598,960 = 4.7539%
… … … … … …
After 100,000,000 hands dealt, all results were within a negligible percentage of the ‘correct’
probabilities.
5.6 Summary While far from perfect, these evaluations show that the product is fundamentally sound. The hand
evaluator’s performance shows that efficient poker applications can be written entirely in java. The
accuracy metrics tests outlined here provide a confidence which is a necessity if the server is to be
considered trustworthy by users. The user tests showed that while flawed, the interface is useable
and reasonably satisfactory. More information on this can be found in the ‘Further Work’ section of
chapter 6.
39
6 Conclusion
"Trust everyone, but always cut the cards." - Benny Binion, casino owner and
creator of the ‘World Series of Poker’.
6.1 Outline This chapter will outline the results of the project. It will also suggest future work which might be
undertaken to improve the application.
6.2 Conclusions The major goal of the project was to make a poker engine general enough to support almost any
conceivable variant of the game, but simple enough that variants could be coded in a reasonable
amount of time. I believe I have met this goal. The implementation of Holdem which I wrote is
logically perfect, and takes less than a hundred lines of code. I believe that I could implement
another ‘Community Card’ variant (e.g. Omaha) in a matter of hours.
A secondary goal of this project was to make it available as a resource to other developers, under a
GNU license. I believe this application will be of benefit to the open-source community – I have not
seen such a complete implementation of the game written in java.
My biggest concern at the beginning of this project was the performance of the evaluator. I was
concerned as to whether one could be written in java to run fast enough, without prohibitive
memory requirements. However, the solution which I came upon provides more than sufficient
performance – over 10,000 evaluations per second.
Having no experience in game UI design, I was not sure of my ability to make an acceptable
graphical interface, in terms of aesthetics and usability. However, most users have commented
favorably (if a little charitably) on the design.
This project turned out to be a major undertaking - much more time was required than originally
anticipated. The most significant cause was the overhead involved in learning java, as I had very
little previous experience of the language previously. While I took several weeks to familiarize
myself with the high-level concepts of the language before beginning design (I felt this would make
the design more accurate), I found that the design needed to evolve as I became more familiar with
the language. From this, I would conclude, that the best way to learn a language is by actually using
it, even if this means, as Brooks would put it, you need to “build it [the application] twice”.
40
6.3 Further Work One of the major goals of this project was to make the server application sufficiently flexible to
allow new variants of the game to be added later. As such, coding new variants would be the most
significant expansion I would envision in the future.
In terms of improving the game play, probably the most significant addition would be to impose
time limits on player’s decisions. Should the time limit expire, a player’s hand would be
automatically folded. This was originally included in the project’s requirements. Unfortunately, the
time constraints of the development schedule forced it to be omitted.
A number of improvements to the interface are possible:
• Add an ‘Automatically post blinds’ checkbox. If this box is checked, the player’s client will
automatically post the player’s blinds for him, making the gameplay that much faster.
• Add sounds, such as cards being dealt, chips being rattled etc… These sounds could be
switched on or off at the player’s preference.
• Players could be allowed to specify that game events should not be shown in the chat field.
This would mean the chat field only showed player’s imputs.
• Allow players to show losing hands.
• Allow players to show winning hands when all other players fold.
• When the game is waiting for a player’s decision, show who that player is (make his name
blink, or similar).
41
Appendices
Appendix A – Code
Note
The code featured here has been edited from its original form for brevity and readability. In order to
preserve a small forest, only a small amount of the source code has been selected for inclusion. The
‘live’ code has been provided to the university in a separate submission and contains ~7000 lines of
code.
The Evaluator //get a hand value based on the “longforms” of 5 cards
private static final char evalMain(int c1, int c2, int c3, int c4, int c5)
{
//store the ANDed rank bitfield.
//note: ‘char’ is the most efficient literal for storing a 2-byte field in Java.
char q = (char)((c1 | c2 | c3 | c4 | c5) >> 16);
//check if all cards are of the same suit by ANDing the suit fields.
//if so, we have a flush. find the result in the flush table
if ((c1 & c2 & c3 & c4 & c5 & 0xf000)!=0){
return EvalArrays.flushes(q);
}
//if we don't have a flush, check the unique5 table for straights and high-cards.
//note: q is 'recycled' to save memory
q = EvalArrays.unique5(q);
// if we have a straight or high-card answer, return it
if ((q !=0)) return q;
//as a last resort, lookup the hash table to find pairs, tree of a kind etc...
return (char) ( ((Short)hash_pairs.get(new Integer((c1 & 0xff)* (c2 &
0xff) * (c3 & 0xff) * (c4 & 0xff) * (c5 & 0xff)))).intValue());
}
42
Server.Card //Stores image location, value and suit of a card.
public class Card {
private char suit;
private String front, back, value, shortform;
/** longform is used by for card evaluator routines (see Chapter 4.3)
* |xxxbbbbb|bbbbbbbb|cdhsrrrr|xxpppppp|
* p = prime number of rank (deuce=2,trey=3,four=5,...,ace=41)
* r = rank of card (deuce=0,trey=1,four=2,five=3,...,ace=12)
* cdhs = suit of card (bit turned on based on suit of card)
* b = bit turned on depending on rank of card
*/
private int longForm;
//constructor
public Card (String card_value, char card_suit){
value = card_value;
suit=card_suit;
front=value + suit +".gif";
back="back.gif";
int intValue;
shortform = value + suit;
gen_Longform();
}
//generate the 'longform' for card evaluator routines
private void gen_Longform() {
int primes[] = { 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41 };
longForm=0; //set all bits to 0
//set the appropriate 'suit' bit
switch (this.suit){
case 'c': longForm += Math.pow(2,15);break;
case 'd': longForm += Math.pow(2,14);break;
case 'h': longForm += Math.pow(2,13);break;
case 's': longForm += Math.pow(2,12);break;
}
//set the prime number int
longForm +=primes[this.intValue()-2];
//set the appropriate ‘value’ bit
longForm +=Math.pow(2,(this.intValue()+14));
}
……………………
//returns the card's value in integer form (1=10, jack=11,king=13,ace=14)
private int intValue(){
43
int intValue=0;
switch (getValue().charAt(0)){
case '2': intValue=2; break;
……………………
case '9': intValue=9; break;
case '1': intValue=10; break;
case 'j': intValue=11; break;
case 'q': intValue=12; break;
case 'k': intValue=13; break;
case 'a': intValue=14; break;
default: Message.errorMessage("Card.Intvalue> Invalid Value");
}
return intValue;
}
……………………………
}
Server.Comms.Message.broadcastCardDealt() public static void broadcast_card_dealt(String card, int seat, Table t){
for (int i=0; i<t.allPlayers.length; i++){
if (t.allPlayers[i]!=null){
Player p = t.allPlayers[i];
try{
//isolate the player who is recieving the card…
if (p.seat_Get()==seat){
//…and send him the card which he has been dealt
p.remoteControl.card_Dealt(seat, card);
}else{
//send all other players a notice of the event (ie a face-down card)
p.remoteControl.card_Dealt(seat);
}
}catch(Exception e){
e.printStackTrace();
}
}
}
}
44
Server.Player public class Player {
private String playerName;
private int credit; //the player's 'wallet'
private int chips; //the players stack at a table
private ArrayList<Card> hand; //the player’s cards
public Table table; //the table at which the player is seated (if any)
private int amountBet;//the amount which the player has bet in the current game
public int handValue; //the integer value of the player's hand
public boolean isIn; //is the player eligible to win this hand?
public boolean isAllIn = false; //is the player all in?
public PlayerRemote remoteControl; //a reference to this player's client
//these are 'live' chips which have not physically entered the pot.
private int advance;
//constructor
public Player(String n, PlayerRemote remoteControl){
…………}
//set the player’s credit
public void setCredit(int credit) {
this.credit = credit;
//notify the player’s client
this.remoteControl.game_Set_Credit(credit);
}
…………………………
//add a card to the player’s hand
public void card_Add (Card c){
//add the card (server side)
this.hand.add(c);
//notify all clients at the table that this player has beed dealt a card
Message.broadcast_card_dealt(c.getShortForm(), this.seat_Get(), this.getTable());
}
…………………………
45
References Brookes, Frederik P. (1975) The Mythical Man-Month, Addison Wesley Longman, Inc.
Galin, D. (2004) Software Quality from Theory to Implementation, London: Pearson Education
Lewis, Clayton and Rieman, John (1993) Task-Centered User Interface Design: A Practical
Introduction [online], available: http://www.hcibib.org/tcuid/
Suffecool, Kevin L. (2006) Cactus Kev's Poker Hand Evaluator [online], available:
http://www.suffecool.net/poker/evaluator.html [accessed November 20, 2006]
The WikiMedia Foundation, (2007) Wikipedia: Poker [online], available:
http://en.wikipedia.org/wiki/Poker [accessed February 12, 2007]
All chapter head quotes: The Quote Garden [online] available:
http://www.quotegarden.com/poker.html
Tools used in creation of software, diagrams etc:
Eclipse SDK The Eclipse Foundation eclipse.org
Java SDK Sun Microsystems sun.com
Genadi’s RMI Plug-in for Eclipse Genadi Beryozkin genadi.net/rmi
Altova UModel Altova altova.com/umodel
Macromedia Fireworks Marcomedia Inc. macromedia.com
