Datasheet
Year, pagecount:2007, 4 page(s)
Language:English
Downloads:4
Uploaded:December 21, 2017
Size:528 KB
Institution:
-
Comments:
Attachment:-
Download in PDF:Please log in!
No comments yet. You can be the first!
Most popular documents in this category
Content extract
Source: http://www.doksinet 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 Source: http://www.doksinet 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. Source: http://www.doksinet 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). Source: http://www.doksinet 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)
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 Source: http://www.doksinet 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. Source: http://www.doksinet 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). Source: http://www.doksinet 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)
