4 Dominion Protocol v3

Due date: by March 25

Figure 3 shows a revised grammar for action, play, and notification, plus a new defense production. The extension adds two action cards, their associated plays, and new interactions to handle attack and defense.

action		=		.... ; all from version 2
		|		militia
		|		moat
play		=		.... ; all from version 2
		|		(act militia)
		|		(act moat)
notification		=		.... ; all from version 1
		|		(attacked (act militia) name state)
		|		(defended name defense)
defense		=		(moat)
		|		(discard card ...)

Figure 3: Dominion protocol, changes for version 3

While the new plays have no interesting constraints, the new action cards expand the overall comunication pattern between the server and players:

• (act militia) — This action triggers an (attacked (act militia) name state) notification to each other player (after the similar moved notification), where name indicates the attacking player. Each other player must respond with a defense. The state in an attacked notification has zero actions, buys, and coins, and it includes no cards in plays.

  A defense response has one of two forms:

  • (moat) — defends against the attack, but requires a moat card in the player’s hand.

  • (discard card ...) — Discards the cards to bring the player’s hand down to three cards. The cards must be a subset of the player’s hand, leaving three other cards in the player’s hand. (It turns out that the number of cards will be zero or two in the current game configuration.)

  Each defense is reflected back to other players as a (defended name defense) notification, where (discard card ...) as defense shows only the first card (if any), corresponding to the card that gets exposed by the discard. Players do not reply to a defended notification.

  When a player uses (act militia), the attacked notification is sent to each other player in order; after all players respond, defended notifications are sent to all players.

• (act moat) — No extra constraints; the player draws two cards.