Three-Card Game: Deal Hands, Rank Them, Then Add a Flush Category

Implement a small card game. Each player is dealt three cards from one shuffled standard 52-card deck (13 ranks in each of 4 suits). After the deal, the program must report which three cards each player received and which player wins, according to the hand-ranking rules below. The task has two parts. Part 1 uses three hand categories and ignores suits. Part 2 adds a fourth category that depends on suits, so write Part 1 in a way you can extend. ### Constraints and Clarifications - Cards are dealt without replacement from a single deck, so no card appears twice in a round. - Unless you agree otherwise, ranks from lowest to highest are 2, 3, 4, 5, 6, 7, 8, 9, 10, J, Q, K, A, and the ace is always high. - Only the categories listed in the current part exist. There are no straights. - Two hands in the same category are compared as follows: three of a kind by the rank of the three cards; a pair by the rank of the pair first, and only then by the remaining card; any other hand by its highest card, then its second-highest, then its lowest. ### Clarifying Questions - How many players are in a round, and is that number fixed or a parameter? (One deck supports at most 17 players with three cards each.) - If two or more players hold hands of exactly equal strength, is it a shared win, or is there a further tie-break such as suit order? - In what form should the result be reported: printed lines, a returned value, or both? - Is the ace always high, or can it also count as the lowest card? - Should the deal be reproducible, for example from a seed, so that the game can be tested? ### Part 1 — Three categories, suits ignored Hand categories from strongest to weakest: 1. **Three of a kind**: all three cards have the same rank. 2. **Pair**: exactly two of the cards share a rank. 3. **High card**: any other hand. Suits play no role in this part. Deal the hands, show each player's cards, and report the winner. ```hint Make hands comparable in one step Look for a single value you can compute for each hand so that deciding which of two hands is stronger takes one comparison, covering both the category and the order within the category. ``` ```hint Mind the pair comparison Two pair hands are decided by the paired rank before the leftover card. Check that the way you represent a pair hand puts its cards in the order in which they matter. ``` #### What This Part Should Cover - A card and deck representation with a numeric rank order and a deal without replacement - Detection of three of a kind, pair and high card - A within-category comparison that decides pairs by the pair before the leftover card - Reporting each player's hand and the winner, including what happens on an exact tie ### Part 2 — Add the flush Add a new category: - **Flush**: all three cards have the same suit. The ranking from strongest to weakest becomes three of a kind > flush > pair > high card. Two flushes are compared by their highest card, then their second-highest, then their lowest. Update the program so that it deals, shows the hands and picks the winner under the new rules. ```hint Check how the categories interact Before writing the flush check, work out whether a three-card hand from one deck can be both a flush and a pair, or both a flush and three of a kind, and what that means for the order of your checks. ``` ```hint Locate the ranking Look at where the category order lives in your Part 1 code. If inserting a category between two existing ones means editing several places, restructure it so that the order is defined once. ``` #### What This Part Should Cover - Flush detection and its placement between three of a kind and pair - Whether any hand can match two categories, and how the order of checks handles that - How much Part 1 code had to change, and whether the ranking is defined in one place - Tests showing a flush beating a pair under Part 2 but not under Part 1 ### What a Strong Answer Covers - Separate, individually testable pieces for dealing, hand evaluation, comparison and output - Numeric rank comparison rather than comparing card labels as strings - A tie policy agreed up front and applied consistently - A deal that can be made deterministic in tests, plus hand-built test hands for every category and every tie-break level - Running time and memory per round in terms of the number of players ### Follow-up Questions - Add a straight (three consecutive ranks). Where would it rank, and how do you treat the ace if both A-2-3 and Q-K-A should count? - The game now shuffles two decks together. Which of your assumptions break? For example, can a hand now be three of a kind and a flush at the same time? - How would you test the winner logic without depending on random deals? - Many rounds are played and each player's number of wins must be tracked. What changes in your design?