Backlog - HackMD

# Backlog ## Use Case 1 - User wants to load in a pre-written XML file to play Texas Hold 'Em On the front end, there will be buttons for each of the most popular variations of poker. To play Texas Hold 'Em, the user can click on the Texas Hold 'Em button, and the XML file corresponding to the game will be sent to the XML parser. The XML parser will create objects and put them in the data interface to be sent to the engine. Then, the engine will orchestrate game play. The main elements of the XML files that differentiate Texas Hold 'Em from other types of poker are the blind type betting, the visibilty and number of cards dealt in each round, and the high hand winning condition. ## Use Case 2 - User wants to write an XML file to create the 5 Card Stud variation The front end will have an option to allow the user to create a custom XML file. There will be lots of different fields in the form to create the new file, but to create the stud variation there are a few specific fields that are especially important. ## Use Case 3 - User wants to write an XML file to create the 5 Card Omaha (shared) variation TThe front end will have an option to allow the user to create a custom XML file. There will be lots of different fields in the form to create the new file, but to create the Omaha variation there are a few specific fields that are especially important. ## Use Case 4 - User wants to write an XML file to create the 5 Card Draw variation The front end will have an option to allow the user to create a custom XML file. There will be lots of different fields in the form to create the new file, but to create the draw variation there are a few specific fields that are especially important. ## Use Case 5 - User wants to change the theme of the game by creating new suits for the cards There is an option on the frontend for the user to choose a theme for the new suits. The frontend would send this information to the backend and the backend would write a new xml file based on this design decision. ## Use Case 6 - User wants to load a pre-existing XML file to play 5 Card Draw On the front end, there will be buttons for each of the most popular variations of poker. To play 5 Card Draw, the user can click on the 5 Card Draw button, and the XML file corresponding to the game will be sent to the XML parser. The XML parser will create objects and put them in the data interface to be sent to the engine. Then, the engine will orchestrate game play. The main elements of the XML files that differentiate 5 Card Draw from other types of poker are the blind type betting, the visibilty and number of cards dealt in each round, and the high hand winning condition. ## Use Case 7 - User wants to load a pre-existing XML file to play 5 Card Stud On the front end, there will be buttons for each of the most popular variations of poker. To play 5 Card Stud, the user can click on the 5 Card Stud button, and the XML file corresponding to the game will be sent to the XML parser. The XML parser will create objects and put them in the data interface to be sent to the engine. Then, the engine will orchestrate game play. The main elements of the XML files that differentiate 5 Card Stud from other types of poker are the blind type betting, the visibilty and number of cards dealt in each round, and the high hand winning condition. ## Use Case 8 - User wants to load a pre-existing XML file to play 5 Card Omaha On the front end, there will be buttons for each of the most popular variations of poker. To play 5 Card Omaha, the user can click on the 5 Card Omaha button, and the XML file corresponding to the game will be sent to the XML parser. The XML parser will create objects and put them in the data interface to be sent to the engine. Then, the engine will orchestrate game play. The main elements of the XML files that differentiate 5 Card Omaha from other types of poker are the blind type betting, the visibilty and number of cards dealt in each round, and the high hand winning condition. ## Use Case 9 - User wants to add a rule to buy cards The frontend will have different options for the user to select which rule they want. The user will select the rule to buy cards, and then the backend will be sent this change. A custom xml file will be written to reflect this new rule, and the game will be restarted. ## Use Case 10 - User wants to change how many cards dealt each round The frontend would have the option for the user to choose how many cards go down on the flop. The frontend woudl send the relevant information to the backend, and an xml file would be written to reflect this change. ## Use Case 11 - User changes the value of the cards The user can write a custom xml file that would allow them to decide the value of all the cards. The user can changes these values in the xml file, and once the xml file is loaded, these changes will be reflected in the game. ## Use Case 12 - The deck is created properly and added to the Table When the deck is initialized, the deck starts out with all 52 cards (in a normal size deck) and then gives the deck to the table. ## Use Case 13 - The Table is initialized properly with the deck The table properly received all of the cards that the deck had when it was it was initialized. The table prepares to recieve information from the Rounds object that will let it know that it needs to deal out cards. ## Use Case 14 - The Round 0 is completed successfully For example in Texas Hold 'em, the big/small blind is run correctly and people have to bet certain amounts. In other games such as 5 card draw, an ante is required and everyone is forced to make an ante. This requires the front end to display the correct options for the bets to be made, and then the information needs to be sent to the backend and stored so that the game can run correctly. ## Use Case 15 ## ## Use Case 20 ## Use Case 21 - User starts a game of Texas Hold'em with four players and all default settings, and is dealt two starting cards. The big blind and small blind have initial bets A PokerGame object will be initialized and passed all relevant information from the View and Data. The engine will then implement the 0'th round, in which no cards are dealt but the big/small blind place bets. These players will be P1 and P2 in the default settings. The engine will then implement the 1st round, in which two cards are dealt to each player face-down. ## Use Case 22 - Betting starts, and a user wants to raise during a betting round After each player views their cards, the engine enters the betting phase. In this phase, the engine cycles through all active players (those who haven't folded) and presents them with options. These options are determined based on the rules of the poker variant and the engine's internal logic. In this case, since no one has raised yet, each player has the option to check or raise. These options are communicated to the front-end, and the user selection is communicated back to the engine. The current bet is incremented, and the next player has the options of call, raise, or fold. ## Use Case 23 - In the second round of a Texas Hold'em game, three cards are dealt to the table The engine moves onto the next round, and uses the info passed in from Data. This round, there are 0 cards dealt to players and 3 cards dealt to the table, so the engine transfers 3 cards from the dealer's deck to the table. ## Use Case 24 - A user discards 2 cards from their hand during a game of 5 Card Draw The engine is given information about each round from Data. In each round in this variant, all players are given the option of discarding 0-3 cards from their hand and replacing them with cards from the dealer. Each player is asked how many cards they would like to discard; the options 0-3 are communicated to the front-end, and the user selection is communicated back to the engine. If the user selects 2 cards from their hand, then those cards are transferred from that player's deck to the discard pile. Then, 2 cards are transferred from the dealer to that player. ## Use Case 25 - A user folds during a betting round The options of call, raise, or fold are communicated to the front-end and the user selection is communicated back to the engine. In this case, the user selected fold. The corresponding player is toggled to inactive, meaning they will no longer receive cards or participate in betting rounds. ## Use Case 26 - Three players survive all rounds of betting, the winner is determined, and the money in the pot goes to the winning player After all rounds have finished, the engine checks if there are more than one active players remaining. Since there are three remaining, their hands are compared. The engine has internal logic to compare hands by sorting hands into categories that are comparable. Using the rules passed in from Data, each player's hand is processed and the winning player is communicated to the front-end. The rules for splitting the pot were passed into the engine from the front-end, so the engine moves the points in the pot to the winning player. ## Use Case 27 - In the second round, all players but one fold, and that player is automatically declared the winner One player raises, changing the bet amount in the Bet class. Each successive player folds, removing them from the active player list. After each player action, the engine checks if there is only 1 active player remaining; once this check succeeds, that player is automatically communicated to the front-end as the winner. ## Use Case 28 - In the first round of 5 Card Stud, two cards are dealt to each player, one face-up and one face-down. The engine receives all rules for each round from Data. It starts the first round and reads from the first Round object, which states that 0 cards are dealt to the table, 1 face-up card is dealt to each player, and 1 face-down card is dealt to each player. For each player, two cards are transferred from the dealer to that player's hand, one of which has a face-up property. ## Use Case 29 - During a betting round, a player raises for the fourth time, hitting the raise limit and preventing all other players from raising that round The engine determines that a player has the options of call, raise, or fold. These options are communicated to the front-end, and the user selection is communicated back to the engine. The user selected raise, so the bet amount is raised and the number of raises is incremented. The number of raises is equal to the raise limit passed into the engine from Data, so for all subsequent players raising is no longer an option. ## Use Case 30 - A player calls during a betting round The player is given the betting options of call, raise, or fold. These options are communicated to the front-end, and the user selection is communicated back to the engine. The player's money is decreased by the amount needed to call the current bet, and that money is transferred to the pot. The player's active status remains, and betting continues to the next player. ## Use Case 41 - Change card design As part of the preferences panel, there are available card designs to choose from that change the appearance of the back of the cards. Once this preference is set by a viewer, the View class applies this card design to all of the cards in the game for the remainder of the game duration. ## Use Case 42 - User attempts to bet more money than they currently have and or exceed the raise limit A player selects the raise options, but enters a bet amount that is greater than the amount available in their individual pot. This triggers an error message that asks the user to change their bet, with a maximum value of "All In" or the "Raise Limit" ## Use Case 43 - User attempts to bet below the current raise amount The user selects the raise option during their turn. In the box to enter their bet amount, they enter an amount lower the current bet. This triggers an exception that prompts an error message, asking the user to increase their bet to at least $1 greater than the current bet ## Use Case 44 - User decides to save their record after winning the game The user presses the "save record" button after winning the game. Their score, along with their name and date of achievement, is stored in a data file that can be accessed when the user requests to see previous records. ## Use Case 45 - User wants to run multiple games at once In the game settings, a user can press a button that represents starting a new game in the different window. This action triggers the creation of a new central, Control object that creates a new game entirely separate from the one that is currently running in a different window. ## Use Case 46 - Computer generated player turn When the user selects a number of players that is greater than the number of human players, the other Players will be computer-generated using AI that becomes more advanced with each sprint. When it is a comuter generated playing turn, rather than sending available actions and receiving a selection from the view class, the Player or Action Manger in the engine will handle the AI player turn and automatically end its turn to pass to the next player. ## Use Case 47 - User requests in game help After being presented with the possible actions they can take during their turn, the user can opt to ask for in-game help. This in game help will generate values on the backend using the same AI technology used to generate the non-human players. This help advice will include win probability and recommended bet amounts. ## Use Case 48 - User wants to pause the game If the current player wants to take break from the game, they can press the gear button, which is the Settings button. This will essentially double as the pause button since players can't play while the settings menu is visible. When the player is ready to resume they can close the settings window. ## Use Case 49 - User sets the raise limit In the game preferences window that the user sets at the beginning of the game, the user can set a "raise limit." The Round class will get the raise limit from the View Class and set it in the backend. ## Use Case 50 - Active player changes Either an AI player or a human player ends its turn. The view notifies the backend if one of the human players has ended their turn. In the backend, the active player is set to the next player at the table, and the view is notified to change the view to the current active player.