Three names for three phases
A state machine gives names to phases and makes allowed transitions explicit. Waiting for input, resolving a move and showing results have different permissions. A turn-based game becomes easier to reason about when input cannot accidentally commit another move during resolution.
A turn-based game can have choosing, executing and displaying-result phases. Each has an input policy: choosing accepts card input, executing rejects a second committed move, and the result may accept restart. Before writing a class, sketch these names and transitions. If you cannot describe when a transition completes, code will not resolve the ambiguity; it will distribute it across conditions. A readable phase plan is useful even before deciding how the implementation stores state.
A second click during resolution
Draw three named states for a small turn: awaiting selection, resolving selection and ready for the next turn. List the allowed input in each. Try confirming twice while resolution is underway. The expected behavior should come from the state contract, not from how quickly the animation finishes. Add one explicit exit route to see whether a pending choice is canceled or completed safely.
Try two rapid card taps. Once the first enters execution, the second must follow that phase’s policy rather than award points again. It could be ignored or preserve a visual selection, depending on the contract. Logical resolution and animation completion may occur at different moments; identify who advances the phase. Several booleans can create impossible combinations. An explicit phase name often communicates the intended situation more clearly than independently toggled flags.
State differs from appearance
On restart, prepare required data before returning to choosing. Renaming the phase does not clear previous cards. A shared data asset such as ScriptableObject can hold configuration, but does not automatically create transitions or a state machine. For review, record which controls work in each phase and what leaving the screen does. This short contract can be compared directly with gameplay, making it more useful than an elaborate diagram with undefined behavior.
Further reading: Unity: ScriptableObject
For a related example, read Dalo’s Shared Core: One Table, Several Games.
