Games | Poker » Project Proposal, Poker Game Environment

Datasheet

Year, pagecount:2007, 4 page(s)
Language:English
Downloads:4
Uploaded:December 21, 2017
Size:528 KB
Institution:-

Attachment:-

Download in PDF:Please log in!


Comments

Nobody commented on this document yet. You can be the first one!


New comment

Content extract

Project Proposal: Poker Game Environment DRAFT Introduction This project proposal is for the design and development of a poker game environment. The environment should act as a bridge between an existing implementation of a poker game engine and several poker players, both human and software-based. The environment should be graphical, interactive, flexible and highly responsive. It should be able to work in several modes, including standard game mode and advisor mode. The system should be written in the Java programming language, or as an in-browser flash application. Background The GPOK project is intended to apply Genetic Programming techniques to evolve poker-playing robots. It uses standard poker factors (such as hand probabilities) as well as in-game opponent modeling, and attempts to combine evolution (for the basic behavior) as well as learning (for the opponent modeling). The variant of the game used is Texas Holdem1, which is a highly popular poker variant, played in most

online and offline poker rooms. This game is fast and responsive, and can be played by up to ten players. Required Skills Good programming and design skills in Java Good GUI design skills in Java OR Good programming and design skills in Flash Good GUI design skills in Flash Experience with Java Web Services In addition: Creative thinking Prerequisites: System Programming, Introduction to Evolutionary Algorithms and Artificial Life (recommended) The poker game environment General The proposed environment should be able to simulate Texas Holdem games, using an existing game engine. It should visualize the game table, let players (both human and robots) to play and follow the game course. It should be able to support both standard game more and advisor mode. 1 http://en.wikipediaorg/wiki/Texas hold em The Engine The Texas Holdem engine is written by the GPOK team, and its purpose is to simulate a series of Texas Holdem games. It supports up to ten players, both human and

computerized, using a generalized Java-based player interface. The engine controls the course of the game using two concepts: Game observer and Strategy. 1. A Game Observer is an abstract entity that can be informed whenever a game event occurs. There are numerous game events, with include (amongst others) new card withdrawal, a players game decision, arrival of a new player etc. The Engine holds a list of such observers and informs them whenever such event occurs. 2. A Strategy is an abstract entity which can be queried for a game decision, given a game status. A decision is one of the following: Fold: leave the current round, losing all the cash invested in the pot Check / Call: continue to play in the current round, without raising the current stake. If the player has invested less money than the current stake, he pays the required amount to match the current stake (Call); otherwise it can continue playing without any fee (Check). Bet / Raise: continue to play in the current round,

and increase the current stake, either from zero to a specific sum (Bet) or from a given sum to a higher one (Raise). There is usually a limited amount of allowed raises in a round. Usually, a player serves both as a Game Observer and a Strategy. This way is can both monitor the games progress using the incoming events, and when its turn arrives decide what to do next. The game engine can filter out some of the observers from time to time when specific events occur. For example, when dealing new private cards, only the dealt player receives an informing event about his card values. The other players may receive a similar event, without the card values of that player. The Poker Environment The proposed poker environment should be able to connect to an existing game engine, and register itself as a game observer, with permissions to see all the game events. Then it should start up the game, using this work flow: 1. Let players join or leave the table New players can be both human and

computerized, and they start with a given amount of money in their account. The engine should be informed about the new players identities. 2. Start a round of Texas Holdem, by calling the engines game-starting routines 3. Maintain a graphical representation of the game table as the game progresses Listen to any game events sent by the engine, and update the table status accordingly. 4. Back to 11 1 Note that step 1 waits for the users input, with information about the new players. This feature should be turned on and off by demand. When off, the game should continue with a new round without waiting for any user input. Handling Human Players As computerized players communicate directly with the game engine as both game observers and strategies, their interaction with the graphical poker environment is minimal. This is not the case with human players, since some kind of input mechanism is needed when they are queried about their decisions. The solution is to use the graphical game

environment to support such queries; this can be done by implementing the Human player in the graphical environment side. This player can safely ignore all incoming events (in fact, it doesnt need to serve as a game observer at all), since the graphical environment handles all these events. The decision routine, however, should pop up a dialog, letting the player decide about his next move from a given list of options. Advisor Mode This purpose of the graphical environment is to evaluate the skills of the evolved poker strategies against both human and computerized players. One special feature required by the GPOK team is the advisor mode. In this mode, one evolved strategy is used as an advisor for a human operator. This operator sits in a table, either physical or virtual, and plays against players, either human or computerized. He constantly feeds the game information to the graphical environment, which in turn sends it as inputs to the game engine. When the human player is about to

make a decision, he queries the graphical environment, which in turn queries the evolved strategy within the engine. The result is then displayed, and the operator takes action accordingly. Implementing this mode should be done in both engine and graphical environment sides. The engine should support manual entry of dealt cards for the board cards and the private cards (upon turns end). The graphical environment side should define a fast method to input this information. A proposed key set is defined in the next chapter, but a keyboard mapping feature should be available to the user, as different keyboard makes can sometimes differ in key layouts. When starting the game, the operator signs up to the game as a computerized player, running the desired strategy. All the other players sign up to the game as regular human players. On the beginning of each round, cards should be dealt. The (real) dealer deals the cards, and the operator feeds his card information to the graphical

environment. On the course of the game, each player is asked for his decision. Since the opponents are defined as Human, the graphical environment will pop up the decision dialog for each of them, letting the operator to enter the decision after it was made. When its the operators turn to play, the game engine automatically queries the evolved strategy for its decision, and plays accordingly. The operator sees the action and mimics it in the real table (in this mode, it is recommended that the strategy decision will be specially announced, so the operator will notice it easily). Implementation Details Computerized Players The computerized players implement both the Observer and the Strategy interfaces. The operator should be able to choose which player class to use from a given list of Java classes (which implement Observer and Strategy, of course). Java vs. Flash It is still to be decided whether the implementation should be Java-based or Flashbased. It will be determined, among

other factors, upon the skills of the programmer Heres a brief comparison of the technologies (advantages are highlighted): Java Communicates directly with the Poker Engine. This solution is fast, reliable and easy to implement. Flash Communicates with the Engine via HTTP; This means that the game engine should be wrapped in a web service, which will be deployed on a web server. This solution is somewhat slower, less reliable and cost extra time in design and implementation. A standalone application that requires An in-browser application, that requires installation on each machine running it only the flash plugin (a standard installation in most browsers) Probably only local games will be allowed Online game is allowed, since the game engine is wrapped by a web service and – all players must play on the same publicly available on the web. machine. If Flash implementation will be used, it is advised to use Flex, which is a flash-based programming language with built-in capabilities

to communicate with web services. Keyboard Mapping In order to make the game as responsive as possible, it is required that the operator will be able to use the keyboard as an input device (in addition to the standard mouse input). In advisor mode, the operator plays against real-life players, which make real-time decisions. Here in particular a fast input method is required, since delays caused by slow inputs will not be tolerated by the opponents. Here is a suggestion for a keyboard input mapping. Note that configurable keyboard mapping is still required. (todo: add keyboard layout image)