Editorial illustration: Choosing trump with limited information

Choosing trump with limited information

The problem I needed to solve

Choosing trump is one tap in the interface, but not every seat is authorized to make it. I needed to verify Hakem authority and stage readiness independently of the button.

Implementation in this snapshot

HokmTrumpSelectionService.RequestTrumpSelection enters a waiting state for humans and invokes IHokmTrumpSelectionStrategy for bots. SelectTrump checks the requesting seat and one of four valid suits.

The design decision and its cost

Humans and bots use different inputs but reach the same final contract. CanStartCardPlay depends on selection state and completion of the remaining deal.

Current boundaries

The bot strategy must exist and the Hakem’s initial hand must contain exactly five cards. This service does not guarantee a strategically good suit; legality and quality are different questions.

Human input and bot choice on one path

RequestTrumpSelection first validates configuration and the Hakem seat, requiring exactly five initial cards. It resets state for the new hand. For a human, MarkWaitingForHumanSelection and HumanTrumpSelectionRequested request UI input; the service waits rather than recording a default suit on the player’s behalf. Waiting is part of the stage contract. An interface must distinguish WaitingForHuman from Selected so opening the selector is not mistaken for completing selection.

For a bot, HokmTrumpSelectionContext receives a copied list of those five cards, plus team, seat and allowed suits. The strategy chooses from that context, and its answer passes through SelectTrump. This shared path means machine-generated input still receives suit validation. A missing botStrategy produces Rejected. Assigning a bot controller is therefore insufficient; the decision dependency must also exist when constructing the service.

SelectTrump compares requestingSeatId with hakemSeatId, accepts only the four standard suits and calls state.SetTrump. The Hakem identity is supplied as a parameter; this is not network authentication, and correct parameter wiring remains the caller’s responsibility. CanStartCardPlay combines trump state with remainingCardsDealt. A successful trump choice therefore does not, by itself, prove the remaining deal is complete or the table is ready for its first move.

What this stage taught me

I wanted authority separate from the selection’s appearance. That lets the interface change and bots improve without permitting trump selection from the wrong seat.

Explore Dalo

Latest devlogs

Editorial illustration: Pasur launch and telemetry in the shared structure

Pasur launch and telemetry in the shared structure

Adding Pasur needs both a correct mode handoff and valid public telemetry.

Read article
Editorial illustration: Presenting selection and captures in Pasur

Presenting selection and captures in Pasur

Pasur motion should explain which hand card was played and which table cards were captured.

Read article
Editorial illustration: Pasur bot decisions from capture options

Pasur bot decisions from capture options

My teammate’s Pasur bot chooses among legal options without inspecting hidden opposing cards.

Read article
Dalo