# Design and Simulate a Four-Player Card Game Design a stateful card-game program using Card, Deck, and Player abstractions. The exercise grows in three stages and should keep the state transitions explicit enough to test. ### Constraints & Assumptions - There are four players and a standard deck dealt evenly after shuffling. - Cards in each hand are ordered consistently by suit and rank. - A player must follow the lead suit when able; the rule for choosing among legal cards must be stated because the source does not fix one. - Scoring cards are 5s, 10s, and Kings; state any point values before calculating totals. ### Clarifying Questions to Ask - Which rank is highest, and is there a trump suit? - How is a legal card selected when a player has several choices? - How many points are assigned to each scoring rank, and how are ties resolved? ### Part 1 — Model, Shuffle, Deal, and Sort Define the responsibilities of Card, Deck, and Player, then explain how a shuffled deck is distributed evenly and each hand is sorted. #### What This Part Should Cover - Card identity and comparison rules. - Deck ownership and shuffle injection for repeatable tests. - Dealing and hand-order invariants. ### Part 2 — Simulate Thirteen Tricks Run thirteen rounds. Every player follows the starter's suit when possible, the trick winner becomes the next starter, and all played cards leave their hands. #### What This Part Should Cover - Legal-move enforcement and winner calculation. - Explicit turn, trick, and next-starter transitions. - Tests for void suits and the final trick. ### Part 3 — Score and Report the Winner Add scoring for 5s, 10s, and Kings, report each player's total, and identify the winner under a stated tie rule. #### What This Part Should Cover - One authoritative scoring table. - Score attribution from captured tricks. - Stable output and tie behavior. ```hint Make transitions observable Represent the current leader, played cards, captured cards, and remaining hands explicitly so every round can be checked. ``` ### What a Strong Answer Covers - Cohesive object ownership rather than shared mutable state. - Deterministic seams around shuffle and card choice. - Complete game invariants, error handling, and stage-by-stage tests. - Honest clarification of source details that are not specified. ### Follow-up Questions 1. How would you replay a game exactly from an event log? 2. How would you support a different scoring variant without rewriting the game loop?