Next: References Up: Poker over DTkEden Previous: Abstract Contents
As described earlier poker fits well into a client-server model, with the dealer as the server and the players as the clients. The only area of the game where this become slightly less clear is when considering shared cards, they are most logically though of as being part of the dealers information, however unlike other information held by the dealer they will need to be considered by the players.
The most difficult part of the game to model is how to store information and how to model communication. There are essentially four different kinds of information which can be accessed by different agents: Information held only by the dealer - such as the pack Information held only by each player the players hand Information which needs to be privately communicated between the dealer and the player e.g. the cards being swapped Information which is communicated publicly between the dealer and the player such as betting information
Whilst the last two are actually communication they can also be considered as information which needs to be shared in a particular way. The issue of communication is complex as the game has both private, direct communication (such as swapping a card) and public, broadcast information such as betting. This is not ideally supported by the communication modes of DTkEden, at present the best solution seems to be to use private communication and communicate public information by multiple private communications.
The code can be split into four notional areas (ignoring the need to split more for intelligibility): Dealer interface, storage of pack/pot Rules dealing, betting, exchange, winning situation Code which is needed by both the dealer and players scoring of hands, betting/swapping actions Players interface
In the cases of games like Texas Hold um where some cards are placed on the table to share between players then these obviously also need to be stored somewhere accessible to both. Since this adds to the complexity of the overall problem the model will first be built without this facility but in a flexible manner which should make it easy to adapt if time allows. To make the initial development of the model as simple as possible it will be developed without betting but will be built in a way which makes this easy to add.
Having the rules as a completely separate area should make it as easy as possible to allow for variation between games, to change between different variations just these files need to be changed. It would also be possible to have several different sets of rules already programmed in, allowing the user to swap easily between different types of game.