Draw Offer During Opponent Micro-Turn

This page documents non-trivial Dice Chess flows where draw offers and other game-altering actions are inferred heuristically from state transitions.

Real-world examples with documented sequences

Example 1: Draw Offer Accepted Mid-Micro-Turn

Game ID: 910b1a3f-2e19-11f1-aff2-c5662bc51b05

The sequence is based on a real gameMoveHistoryStateMap fragment from this game.

Why this matters

In Dice Chess, one turn contains:

1. Dice roll
2. Up to 3 micro-moves

A draw offer can appear between micro-moves, even while the same side is still moving. That means parsers and replay UIs must not assume every draw-offer decision happens only before a roll.

Observed sequence (steps 29-39)

Step	What happens	Key signals
29	White turn is complete	gameMoveHistoryMove: null, FEN active color b
30	Black rolls q,q,q	all 3 dice are allowed: true, used: false
31	Black first queen move (E7 -> B4)	first die becomes used: true
32	Black second queen move (B4 -> C3)	second die becomes used: true, third still unused
33	No board move, waiting state	gameMoveHistoryMove: null, same FEN as 32
37	Still waiting, then decline draw	index gap (33 -> 37) but same board/dice state
38	Black resumes and plays third queen move (C3 -> E1)	all three dice now used: true
39	Highlight reset state	same FEN as 38, gameMoveHistoryMove: null

Practical interpretation

• Steps 33 and 37 are consistent with an out-of-band interaction (draw dialog/decision window).
• The moving side (Black) keeps the unfinished micro-turn context:
  • same FEN active color (b),
  • same dice set,
  • exactly one die still available.
• After declining draw, Black can still consume the last die (38).
• Step 39 is the normal post-move highlight clear state, not a separate chess action.

---

Example 2: Draw Offer Declined Before First Move, Then Double Accepted, Then Draw Accepted

Game ID: 0f868c37-2167-11f1-80d9-43b685605ab2

This game illustrates three separate game-altering transitions:

Scenario A: Pre-Game Draw Offer (Rejected)

Step	What happens	Key signals
0	Game starts	bank: 600, initial position, no dice
1–2	Both clocks ticking	leftTime decreasing, no board change
3	White rolls Q,Q,K	dices array populated, but all allowed: false
4	FEN switches to b (Black’s turn)	No gameMoveHistoryMove, same board
5	Black’s clock continues ticking	leftTime[163]: 59282 -> 57717
6	Draw offer detected: bank jumps 600 -> 1200	✓ Draw was accepted? No — this is actually the double acceptance (see next).

Correction: The bank jump at step 6 is Black accepting the double, not a draw. The draw offer between steps 2–5 is implied by the dialogue interruption (clock states and no-op steps), but appears to be rejected because play continues.

Scenario B: Double Accepted (X2 Mode Activated)

Step	What happens	Key signals
3–5	Black’s clock decreases despite White having rolled	Black is deciding on something (e.g., double or draw)
6	bank: 600 -> 1200	✓ Black accepted the double — definitive signal
7–8	Turn transitions, FEN stays b then becomes w	Draw decision dialog likely closed; game resumed
9	White rolls fresh dice	Doubling round begins

Scenario C: Draw Offer Accepted During Black’s Micro-Turn (Incomplete)

Step	What happens	Key signals
21	Black completed their turn	FEN: b, all dice used: true, gameMoveHistoryMove: null
22	Black rolls k,r,k	New roll, FEN still b, rook is allowed: true
23–25	Black decides, no board move	FEN and dice unchanged, leftTime[303082] decreases
25	Game ends (draw agreed)	Step history stops; draw concluded.

Signal: The repeated no-op state (22 -> 23 -> 24 -> 25) with identical FEN, dices, and gameMoveHistoryMove: null indicates a decision dialog is active. The game ending without any final move or resignation suggests mutual draw agreement.

---

Parser and UI implications

Detection patterns

1. Pre-roll draw or double offer:

   • Opponent’s clock ticks while moving side is idle.
   • No gameMoveHistoryMove change, board frozen.

2. Mid-turn draw offer (while opponent still has unused dice):

   • FEN active color unchanged.
   • Dice set unchanged, but one or more dice still used: false.
   • Repeated no-op states (same FEN, dices, gameMoveHistoryMove: null).
   • Index gap possible (e.g., 33 -> 37).

3. Double acceptance:

   • bank instantly doubles: 600 -> 1200, 1200 -> 2400, etc.
   • Happens out-of-turn if responder is deciding.

4. Draw agreement:

   • Step history stops.
   • No checkmate, resignation flag, or timeout.
   • Last few steps are repeated no-op states.

Do NOT assume

• Contiguous step keys. Gaps like 33 -> 37 are normal.
• Draw detection only at turn boundaries. It can happen mid-micro-turn.
• FEN active color always changes on decision transitions. It may stay constant during decision dialog.

Action checklist for parsers

• Track dice usage (used flag) to know if a side still has micro-moves available.
• Monitor bank changes to detect double acceptance (it’s immediate and unambiguous).
• Detect repeated identical states (same FEN, dices, leftTime ticking) as decision dialogs.
• Record last non-identical state to determine where the game actually ended.
• Use opponent clock decrease while moving side is frozen as a signal of offered action.

---

Confidence and limitations

This behavior is reverse-engineered from observed state transitions. The API does not expose explicit drawOffered, drawDeclined, or doubleOffered flags in these snapshots, so detection remains heuristic.

Key limitations:

• Multiple repeated states can indicate network lag, UI stalls, or legitimate decision pauses.
• Bank changes are definitive for double acceptance but harder to distinguish from other actions in future modes.
• Step indices are not guaranteed to be contiguous.

For the base schema and other state-machine patterns, see Game Move History API.