How Magic Actually Works: Priority, the Stack, Combat, and the Decisions Arena Hides

A Magic turn moves through beginning, precombat main, combat, postcombat main and ending phases, with steps inside several phases. The active player receives priority at defined points after required actions and triggers are handled.

Untapping, drawing for the turn and declaring attackers are turn-based actions. They do not wait on the stack. Players do receive opportunities around them. The exact sequence matters when a spell can change combat, when a trigger appears or when an opponent wants the last moment before a phase ends.

Beginner shortcut: name the phase when the decision matters. “Before combat” and “at your end step” are both clearer than moving a card silently and hoping the table shares your timeline.

Use a physical phase marker for the first few paper games. Move it only after both players pass on an empty stack. The ritual feels deliberate for perhaps ten minutes, then becomes invisible structure. It also reveals where a player has been jumping from a main phase to damage without offering the response windows the rules actually provide.

Priority tells us which player may take an action. The active player normally receives it first at the relevant point. After that player passes, each other player receives the chance in turn. When everyone passes on an empty stack, the game advances. When everyone passes with objects waiting, the top object resolves.

Casting several spells yourself without allowing a response is not “holding priority” by default at every kitchen table. Holding priority is a deliberate communication choice with rules consequences.

In paper, ask “resolve?” or pause clearly. In Arena, stop settings may preserve a window. Neither interface changes the underlying order.

Priority is not an invitation to interrupt speech. It is a rules state. The active player normally receives priority at the relevant point, chooses an action or passes, and the opportunity proceeds in order. In multiplayer, that order matters even when everyone intends to do nothing. Clear pauses and named shortcuts keep the game moving without erasing anyone's legal choice.

A spell or most activated and triggered abilities becomes an object on the stack. New responses are added above older objects. After all players pass, the top object resolves. Players receive priority again before the next object resolves.

This creates familiar reversals. A pump spell targets a creature; removal can be added above it. The removal resolves first. The pump may then fail for lack of a legal target. That is not speed or interruption in the conversational sense. It is ordered resolution.

Do not physically pile cards over each other in a way that hides text. State the order, keep targets clear and resolve one object at a time.

The stack should be narrated from bottom to top before resolution when several objects are waiting. Name each spell or ability, its targets, and the order. Then resolve the newest object, check state-based actions, put new triggers where the rules require, and return priority. That short recap prevents the common paper error where three effects resolve as one improvised paragraph.

Triggered abilities usually begin with “when,” “whenever” or “at.” When their event occurs, they wait to be put on the stack under the rules. Once a trigger is on the stack, destroying the permanent that created it generally does not erase the ability.

That distinction changes removal timing. If a creature generates value when it enters, ordinary removal after resolution cannot undo the entry trigger. A counterspell may prevent the creature spell from resolving. A replacement effect or a card that specifically counters an ability may interact differently.

Read the exact Oracle text. Similar visual designs can hide different timing words, and one preposition can move the correct answer by an entire phase.

Triggered abilities and replacement effects are different tools. A trigger waits for an event and usually uses the stack. A replacement effect changes how an event happens and may use words such as “instead” or “as.” Removing the source after a replacement has already changed an event does not rewind the event. When the distinction matters, read the current Oracle text rather than solving it from memory.

Combat contains beginning of combat, declare attackers, declare blockers, combat damage and end of combat. Attackers are declared as a turn-based action. Afterward, players receive priority. Blockers are declared later, followed by another priority window.

This is why “before attacks” and “after blocks” are meaningfully different. Removing a potential attacker before declaration can prevent it from attacking. A trick after blocks cannot make the defender choose a new block unless an effect says so.

First strike and double strike can create an additional combat-damage step. Deathtouch changes lethal-damage assignment. Trample uses lethal assignment before excess can reach the defending player or planeswalker under the applicable rules.

Combat decisions lock in by step. Attackers are chosen together during declaration, then players receive priority. Blockers are chosen later, then players receive priority again. A creature removed before attackers cannot attack. A blocker removed after blocks leaves the attacker blocked unless an effect says otherwise. Naming the step often answers the question before anyone reaches for a forum.

Costs are paid as a spell or ability is activated or cast. Opponents do not respond in the middle of paying them. If sacrificing a creature is part of the cost, destroying that creature afterward is impossible because it has already moved.

Targets are chosen before responses. A target must remain legal when the object resolves; otherwise the object may fail entirely or affect only its remaining legal targets, depending on the text.

State-based actions are checked before a player receives priority. Creatures with lethal damage are put into graveyards, players at zero life lose and other game cleanup occurs without using the stack. “I respond to it dying from lethal damage” is usually describing a trigger after the state-based action, not preventing the check itself.

Costs reveal why some familiar responses fail. Tapping, discarding, paying life, or sacrificing may be part of the cost paid before opponents receive priority. The permanent used to pay is already tapped or gone. Respond to the ability on the stack if possible, or act before the opponent can activate it. You cannot interrupt payment halfway because the result has become inconvenient.

Arena can automatically pass priority when it believes no meaningful action is available, order some triggers and group repeated effects. Stops and full control preserve windows the default interface may glide through.

Use them surgically. Set a stop when you plan to act in upkeep, before combat or at an end step. Use full control for a specific bluff or timing drill, then return to normal operation. Leaving every stop enabled can turn learning into a study of orange buttons.

When the client surprises you, open the battlefield log, read the Oracle text and reproduce the smallest version of the interaction. The goal is to identify the rule, not to win an argument with an animation.

Arena stops are best used as teaching instruments. Set one before combat to practice acting before attackers. Set one on the opponent's end step to learn when to spend unused mana. Use full control for a specific sequence, then disable it. The interface should expose a rules window, not make every land drop wait for a committee meeting.

State the spell, modes, targets and relevant costs. Pause for responses. Keep the battlefield, graveyard, exile and command zone visibly distinct. Confirm life totals and counters before moving to the next decision.

Shortcuts are proposals. “Go to combat” offers to pass priority to a recognized point. The opponent can interrupt the shortcut at a legal earlier window. Clear speech prevents the common dispute where both players imagined a different step.

Call a judge when tournament rules or hidden information matter. A judge request is normal process. The most technically skilled table is often the one that makes uncertainty safe to say aloud.

At a store, state uncertainty early: “I think this trigger is still on the stack; can we confirm?” In casual play, consult the current Oracle text and agree on the ruling. In an event, call a judge without apology. Technical confidence is not performing certainty. It is protecting shared information, preserving the game state, and knowing when an independent ruling is the cleanest move.