The problem I needed to solve
For Joker, a deck filename was insufficient. Actual composition matters because each rank’s multiplicity directly affects pairing and the terminal state.
Implementation in this snapshot
JokerGame.ValidateDeck requires 33 cards: one Joker, four aces, queens and kings, and two of every other rank. Ordinary suit/rank identities must be distinct.
The design decision and its cost
The current scene uses Joker_Mixed_33_Deck. Validation permits different suit pairs for two-copy ranks, while the current asset uses hearts and spades.
Current boundaries
Legacy assets named 33 or 41 are not proof that they are scene-wired. Actual references and validation need inspecting together; a filename’s number is not an execution contract.
Review scenarios and contract meaning
In a pairing game, a deck-composition error reaches the ending directly. An incorrect rank count or duplicated Joker cannot be repaired by a perfectly functioning interface. Validating the deck before the main flow exposes the issue at the data boundary. Four aces, four queens and four kings, together with two copies of the other ranks and one Joker, make thirty-three cards. Requiring distinct suit-and-rank identities also prevents two references to the same ordinary card from being accepted as separate valid cards. These constraints belong to this version’s rules.
For an asset review, I read both its internal composition and the actual scene reference. An old file with another number in its name does not prove it is active. Conversely, a plausible filename does not validate its contents. Allowing different suit pairs for two-copy ranks shows that the rule depends on counts and identities rather than one asset’s colors. This can simplify visual-content changes, but any new composition still needs to pass the same checks. I do not generalize this structure to every local Joker variant or its different rules.
Sharing RuntimeDeck does not mean sharing every constraint. Hokm and Joker can use the same data container while requiring different validation. Healthy reuse here concerns representation and identity, with composition rules remaining close to the game. Another game likewise needs its own valid definition rather than a copied card count.
What this stage taught me
For me, this began demonstrating the core’s flexibility. Cards and hands retained shared structures, but the definition differed from Hokm’s standard deck and Joker defined its own valid composition.
