The problem I needed to solve
Pasur motion should explain which hand card was played and which table cards were captured. While integrating my teammate’s work, presentation order mattered as much as capture logic.
Implementation in this snapshot
PasurCardMotionDirector.Play presents a card from the hand, and Collect moves table cards identified by ID toward a destination. DealTable separately presents opening table cards.
The design decision and its cost
Sequences are tracked with the component ID and unscaled timing. ownedViews and hidden cards are retained so Cancel can stop motion and clean presentation.
Current boundaries
Motion depends on a valid motionLayer and views. Having Cancel does not prove every mid-animation restart or aspect-ratio change works; those remain separate acceptance scenarios.
Review scenarios and contract meaning
Pasur motion needs a readable cause-and-effect relationship: a card leaves the hand, reaches the table, and a specified set is collected with it. If collection appears before the played card is clear, or the wrong card is shown, correct rules will still be hard to understand. Separate Play, Collect and DealTable operations give these stages explicit vocabulary. Identifying table cards by identifier lets presentation follow the accepted set rather than temporary table positions. The collection destination must also correspond to the right player so the result remains visible.
Cancellation is another important concern. ownedViews and hidden-card state support cleanup, but seeing a method named Cancel does not establish every interruption is correct. Leaving the screen, restarting a round and losing the motion layer are distinct scenarios. Unscaled timing gives presentation defined behavior when gameplay time scale stops, but the product’s pause policy must still be clear. I describe this within my teammate’s work: animation is a visual account of a result, and a more appealing path should not transfer rule acceptance into presentation.
Cards temporarily hidden for motion need a defined state after completion or cancellation. An invisible leftover is a presentation problem even with correct logical sets. I review that boundary separately from capture calculation. Cancelling during collection matters because quality includes recovery from partial presentation rather than only a completed card flight.
What this stage taught me
For me, good animation explains an accepted result. An attractive flight is not helpful if table selection becomes ambiguous; players should see the connection between their card, the chosen set and collection destination.
