Netrunner Comprehensive Rules
Null Signal Games
This rules document is to be used as reference material. It is not intended to be read straight through. If you still have questions after consulting this document, please ask us online via email. This version of the Comprehensive Rules document is effective 30 March 2024.
Summary of Changes (v24.03)
- (October 2024 Update) Increase usability of table of contents in web version of the Comprehensive Rules.
- Update list of subtypes section 2.16.7 to add assassination and mandate, and expand academic and deep net to new card types.
- Add rule 3.4.4a to allow modifications to ice strength "for the remainder of this run" to work the same as modifications to icebreaker strength. Namely, if an encounter takes place outside of a run, these effects last for the remainder of the encounter.
- Add rule 5.2.3a clarifying when conditions and costs related to the basic action apply.
- Updated wording for the met conditions in step 8.6.6.
- Add rule 9.6.6a to clarify how conditional abilities check requirements that refer to past game states.
- Add section 9.12.6 to clarify how modal abilities (bulleted lists) are resolved.
Acknowledgements
- Netrunner Original Game Design: Richard Garfield
- Android: Netrunner
- Game Development: Lukas Litzsinger
- Expansion Development: Lukas Litzsinger, Damon Stone, and Michael Boggs
- Rules by: Adam Baker, Michael Boggs, and Erik Dahlman
- Android Universe created by: Kevin Wilson with Daniel Lovat Clark
- Null Signal Games
- Rules Manager: Jamie Perconti
- Rules Associates: Ruben P. Pieters and Justin Prentice
- Rules Editors: Kayli Ammen and Jonny Foster
- Additional Contributions: Noah Bogart, Pat Chapman, Tim Vaduva, and Olive Wesley
Netrunner is a ™ of R. Talsorian Games, Inc. Android is ™ & © Fantasy Flight Games. Although these rules are made to be compatible with cards from Android: Netrunner, they are not in any way associated with or endorsed by Fantasy Flight Games, R. Talsorian Games, or Wizards of the Coast.
These rules are compatible with cards from the game android: netrunner by Fantasy Flight Games. android: netrunner is a game about the cyber-struggle between massive Corporations and subversive hackers known as Runners.
- 1.1.1.linkThe game is played between two players. One player takes the role of the Corp (Corporation) and the other takes the role of the Runner. This rules document will frequently refer to a player interchangeably with their game role.
- 1.1.2.linkEach player needs a legal deck, an identity card for their role, and any extra cards used from outside their deck. They also need a supply of tokens as described in section 1.9. The constraints that define the legality of a deck are defined in section 1.4, and the cases where cards outside the deck and identity can be used are defined in section 1.5.
- 1.1.3.linkAll numbers used in the game are integers. Unless otherwise stated, a given value can be positive, negative, or zero.
- 1.2.1.linkIf the text of a card directly contradicts these rules, the text of the card takes precedence.
- 1.2.2.linkIf a rule or ability directs something to happen, but another effect states that it cannot happen, the "cannot" ability takes precedence.
- a.linkIf a "cannot" effect prohibits all of the effects of another ability, that ability cannot be triggered.
- b.linkIf a "cannot" effect prohibits only part of another ability, that ability can be triggered, but the prohibited steps of resolving that ability are not carried out.
- Example: During a run, Lockdown's subroutine resolves, preventing the Runner from drawing cards for the remainder of the turn. The Runner has a Diesel and a Process Automation in their grip. For the remainder of this turn, they cannot play Diesel as its entire ability is prohibited, but they can play Process Automation. Even though cards cannot be drawn through Process Automation, the Runner can play it to gain 2[c].
- 1.2.3.linkIf an instruction includes the words "if able," it can only be carried out fully or not at all. If any part of the instruction is not possible to carry out, the entire instruction is ignored.
- 1.2.4.linkIf an instruction does not include the words "if able," as much of that instruction as possible is carried out. Any parts of the instruction that are not possible to carry out are ignored.
- 1.2.5.linkA player can only take an action or use an ability if its effect has the potential to change the game state. This potential is assessed strictly by what the action or ability can be expected to accomplish, without regard to the consequences of paying any costs to initiate that action or ability and without regard to any other abilities that may meet their conditions in the process of initiating or resolving that action or ability.
- Example: The Runner is playing Armand "Geist" Walker and has Forger installed. The Runner can only trash Forger and trigger Geist's ability when they are about to take a tag (which Forger could avoid) or while they have a tag (which Forger could remove). Using Forger at any other time has no potential to change the game state.
- 1.3.1.linkSeveral non-English symbols appear on cards and in this rules document. This section serves as a basic guide to those symbols.
- 1.3.2.linkWhen this document is presented in a format without images, plaintext replacements are used. These replacements are listed along with the symbols themselves for reference.
- 1.3.3.linkThe symbol [c] (plaintext: [c]) stands for "credit". It always appears with a numeral, such as 1[c], which means "one credit," or 3[c], which means "three credits." See section 1.10 for rules about credits.
- 1.3.4.linkThe symbol [click] (plaintext: [click]) stands for "click". Multiple clicks can be represented either by multiple symbols, such as [click][click], or by a numeral and symbol, such as 2[click], both meaning "two clicks." See section 1.11 for rules about clicks.
- 1.3.5.linkThe symbol [recurring] (plaintext: [recurring]) stands for recurring credit. It always appears with a numeral, such as 1[recurring], which means "one recurring credit," or 3[recurring], which means "three recurring credits." See section 1.10.5 for rules about recurring credits.
- 1.3.6.linkThe symbol [link] (plaintext: [link]) stands for "link". It is always used with a quantity, such as 1[link], which means "1 link." See section 10.7 for rules about link.
- 1.3.7.linkThe symbol [MU] (plaintext: [MU]) stands for "memory unit". It always appears with a quantity, such as 2[MU], which means "2 memory units." See section 1.20 for rules about memory.
- 1.3.8.linkThe symbol [sub] (plaintext: [sub]) stands for "subroutine". Each symbol marks a single subroutine on a piece of ice. See section 9.8 for information about subroutines.
- 1.3.9.linkThe symbol [trash] (plaintext: [trash]) stands for "trash this card". It is used as a self-referential cost in card text, such as "[trash]: Draw 2 cards," which means "Trash this card to draw 2 cards." See section 1.16 for rules about costs, and section 1.19 for rules about trashing cards.
- 1.3.10.linkThe symbol [interrupt] (plaintext: [interrupt]) stands for "interrupt timing". It is used to designate abilities that resolve immediately before other abilities. See section 9.9 for rules about interrupt abilities.
- 1.4.1.linkEach player's deck is associated with a single identity card that determines the faction, minimum deck size, and influence limit of that deck. The identity card may also stipulate other variances from the standard deckbuilding rules.
- a.linkThe identities The Catalyst and The Syndicate from the System Gateway Starter Pack are intended for use only with the decks included in that pack. They are not legal for play under the full deck construction rules.
- 1.4.2.linkEach deck must meet all requirements in this section to be legal for play.
- 1.4.3.linkThe deck must contain at least as many cards as the minimum deck size indicated on the corresponding identity.
- a.linkIdentity cards, extra cards that begin the game outside the deck, and player aid cards are not part of the deck and are not counted towards the size of the deck.
- b.linkThere is no maximum deck size.
- 1.4.4.linkDecks cannot contain identity cards, player aid cards, cards from the wrong side (Corp cards in a Runner deck or vice-versa), or out-of-faction cards that lack influence costs.
- 1.4.5.linkNeutral cards and cards that belong to a faction other than the corresponding identity's faction are all considered out-of-faction. The total influence cost of out-of-faction cards in the deck must not exceed the influence limit of that identity.
- a.linkThe total influence cost of out-of-faction cards is counted by copy and not by name.
- Example: Including a single copy of Diesel in a non-Shaper deck adds 2 to the total influence in that deck, while including two copies of Diesel in a non-Shaper deck adds 4 to the total influence in that deck.
- 1.4.6.linkA Corp deck must contain agendas totalling a certain number of agenda points, as determined by the total number of cards in the deck.
- a.linkA deck with 40 to 44 cards must contain 18 or 19 agenda points.
- b.linkA deck with 45 to 49 cards must contain 20 or 21 agenda points.
- c.linkA deck with 50 to 54 cards must contain 22 or 23 agenda points.
- d.linkA deck with more than 54 cards must contain 22 or 23 agenda points, plus an additional 2 agenda points for every full 5 cards in the deck over 50.
- Example: A 66 card deck requires 6 additional agenda points, since it includes 3 sets of 5 cards beyond 50. This gives a final requirement of either 28 or 29 agenda points.
- 1.4.7.linkThe deck cannot contain more than 3 copies of any single card, by name. Some cards stipulate alternative copy limits in their card text.
- 1.4.8.linkTournament play may impose other restrictions or requirements on the legal configurations of identities and decks.
- 1.5.1.linkSome abilities allow for the use of additional cards from outside the deck.
- 1.5.2.linkOne Corp identity, Jinteki Biotech: Life Imagined, has the ability, "Before taking your first turn, you may switch this card with any copy of Jinteki Biotech." There are 3 versions of this identity, which have different abilities on their reverse side.
- a.linkA player playing Jinteki Biotech as their identity may bring any number of copies of that identity along with their deck. After completing game setup, that player may choose any copy they own to be their active identity for the duration of the game. All other copies are placed outside the game.
- 1.5.3.linkOne Runner identity, Adam: Compulsive Hacker, has the ability, "You start the game with 3 different directive cards installed (these cards are not considered part of your deck)."
- a.linkA player playing Adam as their identity must bring at least 3 differently named cards with the directive subtype along with their deck. The player may bring any number of directive cards over the required 3.
- b.linkAfter players reveal their identities, the player playing Adam selects exactly 3 of their provided directive cards. Those cards begin the game installed in the play area. All other directives the player brought this way remain outside the game.
- c.linkA player playing Adam can also include directive cards in their deck. The cards chosen to be installed at the beginning of the game do not impact the deck's influence requirements or the maximum allowed number of copies of those cards.
- d.linkOnce the game has begun, the cards installed this way are treated exactly as any other installed cards. Abilities that move these cards to other zones function normally, including shuffling them into the stack.
- 1.5.4.linkTwo cards, Rebirth and DJ Fenris, make use of identity cards other than the one selected by the player during deck construction.
- a.linkA player may bring any number of additional Runner identity cards along with their deck. These cards are kept in a pile outside the game. The Runner may look at these cards at any time.
- b.linkWhen an ability refers to an identity other than the Runner's current identity, it refers to the cards provided this way. If an identity card leaves the play area, it must be returned to the pile outside the game.
- c.linkIn a tournament, all identities brought to the game this way must be legal for players to use as their actual identity in that tournament.
- d.linkOne Runner identity, Hoshiko Shiro, is double-sided (see section 3.1). If the Runner switches their identity with Hoshiko, it enters play with the front side faceup. If the Runner switches Hoshiko with another identity, the new identity enters play faceup regardless of Hoshiko's current status.
- 1.6.1.linkThe players decide who will play as the Corp and who will play as the Runner. Each player places an appropriate identity card for the side they are to play faceup in the play area, then supplies a corresponding deck, placing it facedown in the play area, and any appropriate extra cards.
- a.linkSome identity cards have abilities that affect setup. Even though cards are not active until the game begins, these identities still alter setup at the appropriate step as indicated by their text.
- b.linkSome identities are double-sided (see section 3.1). If a player is playing a double-sided identity, it begins the game with the front side faceup.
- 1.6.2.linkIf a player's identity has an ability that affects setup or the start of the game, and that ability does not directly correspond to a setup step outlined in this section of the rules, that player makes any necessary decisions and changes for their identity's special setup or start of game abilities at this time. If both players have setup or start of game abilities at this time, the Corp resolves theirs first.
- 1.6.3.linkThe players create the bank by gathering all types of tokens described in section 1.9.
- 1.6.4.linkEach player takes five credits from the bank, placing the credits in their credit pool.
- 1.6.5.linkEach player shuffles their deck.
- 1.6.6.linkEach player draws 5 cards from the top of their deck to form their starting hand.
- a.linkAfter drawing starting hands, the Corp may choose to take a mulligan; then, the Runner may choose to take a mulligan. To take a mulligan, the player shuffles their starting hand back into their deck, then draws a new starting hand. They must keep the second hand as their starting hand.
- 1.6.7.linkThe game begins and the Corp takes their first turn.
- a.linkIf the Corp's identity has an ability with instructions for "before taking your first turn," the Corp resolves that ability immediately before taking their first turn, and thus before the game starts.
- 1.7.1.linkThe game ends when a player meets one of their win conditions.
- a.linkIf both players would simultaneously satisfy their win conditions, the game ends in a draw.
- 1.7.2.linkEach player has two possible win conditions available.
- a.linkEither player can win by collecting agenda points in their score area (usually done by scoring or stealing agendas; see section 1.17). A player with a score of 7 or more wins the game.
- b.linkThe Corp wins if the Runner is flatlined. The Runner is flatlined immediately if they suffer more damage than they have cards in their grip. The Runner is also flatlined if, at the beginning of their discard phase, their maximum hand size is less than 0. See section 10.4 for more information about damage.
- c.linkThe Runner wins if the Corp is required to draw a card from R&D but cannot because R&D is empty.
- 1.8.1.linkThere are six types of Corp cards: agendas, assets, ice, identities, operations, and upgrades. All cards except the identity card are shuffled into the Corp's deck at the beginning of the game.
- 1.8.2.linkThere are five types of Runner cards: events, hardware, identities, programs, and resources. All cards except the identity card are shuffled into the Runner's deck at the beginning of the game.
- 1.8.3.linkCards that are active are able to affect the game through their abilities.
- a.linkRunner cards that are installed and faceup in the play area, Corp cards that are installed and rezzed, events and operations in the play area, agendas in the Corp's score area, and both players' identities are active.
- b.linkUnless otherwise stated, Runner cards become active as part of the process of playing or installing them.
- c.linkUnless otherwise stated, Corp cards other than operations are installed unrezzed, and thus inactive, into the play area. Assets, ice, and upgrades become active when they are rezzed; agendas become active when they are scored. Operations become active as part of the process of playing them.
- d.linkIdentity cards become active when the game begins.
- 1.8.4.linkCards that are inactive are unable to affect the game or have most of their abilities used.
- a.linkCards are inactive in R&D, HQ, Archives, the heap, the grip, the stack, the Runner's score area, while set aside, and while removed from the game. Facedown cards in the play area are also inactive.
- b.linkInactive cards in most zones retain their printed characteristics (name, card type, faction, cost, subtypes, influence, etc). Facedown installed Runner cards have no characteristics.
- 1.8.5.linkFor a player to draw 1 or more cards is to take that many cards from the top of their deck and put them into their hand. Section 8.4 provides more details about drawing cards.
- 1.8.6.linkMost abilities are active if and only if the card they appear on is active. Section 9.1.8 details the cases where abilities on inactive cards are still active.
- 1.8.7.linkAbilities can convert cards from one type into another type, or even from a card into a counter. Rules 10.1.3 and 10.1.4 explain the details of card conversion.
- 1.9.1.linkCounters and tokens are game pieces (or equivalent) that track various resources, effects, and statuses of players and their cards.
- a.linkThe terms "counter" and "token" are interchangeable.
- 1.9.2.linkThe bank is the supply of counters not yet in play. Counters in the bank are available to both players to take and use as dictated by the game rules and card abilities. Players do not control counters in the bank and cannot spend them. The bank is an unlimited supply; running out of game pieces to track a type of counter does not prohibit a player from gaining counters of that type or placing them on cards.
- a.linkIf an instruction directs players to place counters on a card without designating where those counters come from, take those counters from the bank.
- b.linkA condition or restriction that looks for counters being placed on a card can be met by either counters from the bank or counters moved from another location.
- 1.9.3.linkSome abilities can convert a card into a counter. A counter put into play in this way is tracked with the card acting as a game piece. See rule 10.1.4.
- 1.9.4.linkSome abilities can cause a player or card to have or be "considered to have" 1 or more counters or additional counters without placing or giving those counters. A counter considered to exist in this way conveys all the same information and effects as a counter of the specified type would, except that it cannot be moved or removed from the card or player it belongs to, nor can it be spent to pay a cost.
- 1.9.5.linkThere are ten types of counters: credit counters, click counters, tag counters, bad publicity counters, core damage counters, advancement counters, virus counters, power counters, agenda counters, and condition counters.
- a.linkCredit counters are used to track the number of credits each player has in their credit pool; they can also be placed on cards. Rules for credits, the credit pool, and other related concepts are in section 1.10.
- b.linkClick counters are a gameplay aid used to track the clicks the active player has spent or has left to spend during their turn. Rules for clicks are in section 1.11.
- c.linkTag counters are used to represent tags on the Runner. Rules for tags are given in section 10.5.
- d.linkBad publicity counters represent bad publicity the Corp has earned. Rules for bad publicity are in section 10.6.
- e.linkCore damage counters are a gameplay aid used to track core damage the Runner has suffered. Each point of core damage the Runner suffers forces them to take a core damage counter. See section 10.4.
- f.linkAdvancement counters are a counter used primarily on installed agendas to track the Corp's progress toward being able to score them.
- g.linkVirus counters are a generic counter, used primarily by virus programs, that can be removed by the Corp purging them. See section 10.1.2.
- h.linkPower counters are a generic counter used by a variety of cards. They have no special rules.
- i.linkAgenda counters are a generic counter used primarily on scored agendas. They have no special rules.
- j.linkCondition counters are counters that have rules text. Their abilities are active as long as they are hosted on a card.
Each of the Runner's credits represents enough money to upgrade some basic parts for their console, have a meal at a decent restaurant, or buy a ticket and some concessions for a night at the sensies.
Each of the Corp's credits represents enough money to manufacture a run of computer parts, buy out a decent restaurant, or film a low-budget sensie.
- 1.10.1.linkA credit ([c]) is the basic unit of currency. Players spend their credits to pay for various costs, card abilities, traces, etc. Credit counters most commonly represent 1[c] each, but can represent larger denominations if clearly marked.
- 1.10.2.linkEach player has a credit pool where they keep a supply of credit counters matching the credits they have available to spend. The number of credits in a player's credit pool is open information.
- 1.10.3.linkCredits enter and leave a player's credit pool as that player gains, loses, or spends credits.
- a.linkA player gains credits whenever credits enter their credit pool from any location.
- b.linkIf a player is required to lose credits, that player is forced to move the specified number of credits from their credit pool to the bank. Players cannot lose credits from cards.
- Example: If a subroutine on DNA Tracker resolves, the Runner must lose 2[c] from their credit pool, or 1[c] if that is all they have. If the Runner's credit pool is empty, the effect does nothing.
- c.linkTo spend or pay credits, a player puts the specified number of credits back into the bank. By default, the credits must come from the player's credit pool. Abilities can also allow players to spend credits hosted on their cards under certain conditions. If any such abilities apply, the player chooses how to divide the credits they are spending from among the allowed locations. The terms "spend" and "pay" are synonymous.
- Example: The Runner may use the credit from Cyberfeeder to pay for Atman's first ability.
- Example: The Runner may use credits from Ghost Runner when secretly spending credits to resolve a Psi ability (such as The Future Perfect).
- Example: The Runner must use credits from Ghost Runner if this is the only way for them to pay 3[c] when resolving the "when encountered" ability on Tollbooth.
- 1.10.4.linkAbilities can place credits on cards, as discussed in section 1.13. Credits on a player's card are not in that player's credit pool; the player can only interact with those credits as instructed by card abilities.
- a.linkIf a player is instructed to take credits from a card, they remove that many credits from that card and gain those credits.
- b.linkIf an ability specifies how a player is allowed to spend credits from a card, they can be spent from that card as if they were in the player's credit pool for the specified actions or abilities.
- c.linkIf an ability specifies a time period during which a player is allowed to spend credits from a card, they can be spent from that card as if they were in the player's credit pool for any purpose (other than losing credits) as long as the specified time period is active or the specified duration has not expired.
- d.linkSpending credits from a card is considered "using" the card that allowed those credits to be spent. See section 9.1.6.
- 1.10.5.linkRecurring Credits
- a.linkRecurring Credits ([recurring]) place credits on a card repeatedly. The text "N[recurring]" means "When this card becomes active, place N credits on it. Before abilities meet their trigger conditions for your turn beginning, if there are fewer than N credits on this card, place credits on it until there are N credits on it."
- b.linkRecurring credits are first placed on a card as soon as it becomes active. This occurs at step 8.5.15e of installing the card if it is installed active, step 8.6.6c of playing an event or operation, or as soon as the card is turned faceup or scored, as applicable.
- c.linkRecurring credits are refilled during step 5.6.1c of the Corp's turn and step 5.7.1c of the Runner's turn, before other abilities that apply at the start of the turn resolve.
- d.linkRecurring credits do not accumulate. They are refilled only up to the indicated number.
- Example: The Runner installs Spinal Modem, which has 2[recurring]. 2 credits are placed on Spinal Modem now. The Runner spends 1 of those credits later in their turn. At the beginning of the Runner's next turn, the credits on Spinal Modem should be replenished up to 2[c], so 1 more credit is placed on it.
Working a job, making connections, and especially jacking in—everything you do takes time, and it always goes by faster than you think. A click represents an abstract amount of time spent on a particular activity, either several hours all at once or scattered across the day.
- 1.11.1.linkA click ([click]) is the basic unit of activity. Players spend their clicks to perform actions and trigger abilities. Each click counter represents 1 click.
- 1.11.2.linkAs the first step of a player's turn, they gain an allotted number of clicks to spend during the action phase of that turn. See section 5 for details about the procedures of player turns.
- a.linkThe Corp receives 3[click] on each of their turns.
- b.linkThe Runner receives 4[click] on each of their turns.
- 1.11.3.linkPlayers can gain, lose, or spend clicks.
- a.linkA player gains clicks whenever the number of clicks they have is increased.
- b.linkIf a player loses or spends clicks, the number of clicks they have is reduced by that amount. The terms "lose" and "spend" are not synonymous for the purposes of meeting conditions and restrictions of card abilities.
- c.linkPaid abilities that begin with [click] are actions and have special timing rules (see section 5.2). Aside from taking actions, there are no special restrictions to how or when a player can spend their clicks during their turn.
- 1.11.4.linkSome cards have the subtype priority and the text, "Play only as your first [click]." A player can only play a priority card using the basic action to play an event or operation, and only if they have not spent any other clicks that turn. Losing clicks does not affect a player's ability to play a priority card.
- 1.12.1.linkAn object is an occurrence of a card or counter existing in a particular zone. When a card or counter moves from one zone to another, it becomes a new object.
- 1.12.2.linkRestrictions and effects on a card or counter only apply for as long as that card or counter remains the same object. Cards and counters have no memory of the objects they were in the past.
- Example: The Corp uses the first ability on Vaporframe Fabricator, which specifies that it can only be used once per turn, and trashes Vaporframe Fabricator during the installation process. Then the Corp plays Restore, reinstalling the same copy of Vaporframe Fabricator from Archives. Even though it is the same physical card, the reinstalled Vaporframe Fabricator is a new object, and its "once per turn" ability is available to be used this turn.
- a.linkAn ability that moves cards can identify the new objects that those cards become and continue to act on them.
- Example: The Corp plays Priority Construction, installing a piece of ice from HQ. That ice is now a new object in the play area, but Priority Construction's second instruction can still find it and place advancement counters on it.
- 1.12.3.linkA card that moves from its location to a hidden or secret location becomes a new object, even if the new location is in the same zone.
- Example: The Corp scores Accelerated Beta Test, looks at the top 3 cards of R&D, and installs and rezzes a piece of ice from among them. As a chain reaction, the Corp then uses The Foundry: Refining the Process to search R&D, with the result that the other cards currently being looked at by Accelerated Beta Test are shuffled along with the rest of R&D. Since the cards were moved to an unknown location in R&D, Accelerated Beta Test can no longer act on them, so those cards can no longer be looked at and will not be installed or trashed.
- Example: The top card of R&D in the current game state is an object. So is the 2nd card from the top of R&D, the 3rd card, and so on. If the Corp plays Precognition and rearranges the top 5 cards of R&D, the Runner will not know which cards correspond to which objects in the previous order, so the cards become new objects under their new order.
- 1.12.4.linkA card or counter that moves to a known location in the same zone is still the same object.
- Example: The Runner has chosen a piece of ice with Femme Fatale, and the Corp uses Thimblerig's ability to move that ice to another location. But the ice has not left the play area, so it is still the same object and the Runner can still use Femme Fatale's ability to bypass it.
- 1.12.5.linkA card that is turned faceup or facedown is still the same object.
- Example: The Corp uses Vaporframe Fabricator, installing a piece of ice at no cost, and then plays Divert Power to derez Vaporframe Fabricator and rez their newly-installed ice at a discount. The Corp can rez Vaporframe Fabricator again, but since it is still the same object, its "once per turn" ability cannot be used again this turn.
- 1.12.6.linkWhen a card or counter becomes a new object, its previous object ceases to exist, but can still be remembered by rules or abilities that refer to past game states.
- Example: The Runner plays Bravado. During the run, a piece of ice that the Runner has already passed is trashed. When the run ends, Bravado's ability must determine how many pieces of ice the Runner passed during that run. It does this by reviewing the game history and counting each distinct ice object that the Runner passed. Even though the object corresponding to the trashed ice no longer exists in the present game state, Bravado can still count it.
- Example: The Runner trashes the top card of R&D while accessing it. The object corresponding to that card in its location on top of R&D ceases to exist, but still counts against the number of cards the Runner can access from R&D during this breach.
- 1.13.1.linkWhenever an object is "placed" or "loaded" onto a card, a host relationship is created between those two objects. The object placed on top of a card is hosted on that card. The card onto which the other object is placed is the host.
- a.linkOnly cards in score areas and the play area can host objects.
- 1.13.2.linkThe state of being hosted is distinct, but not exclusive from, the state of being installed. If an ability instructs a player to host a card from an inactive state without reference to installing it, the hosted card remains inactive.
- 1.13.3.linkAn object can only be hosted on a single card at any given time.
- 1.13.4.linkA card can host any number of other objects, except where explicitly restricted by a card ability.
- 1.13.5.linkAny card in an eligible location can act as a host, but a host relationship can only be created or permitted by a card ability.
- a.linkIf a card has an ability describing the types and/or numbers of cards it can host, but it does not have an ability that directly hosts cards onto itself, then the card is permitted as an eligible installation destination for the types of cards listed, up to the number specified. A host card is chosen as an installation destination during step 8.5.15b of the installation process.
- Example: Off-Campus Apartment has the ability, "Off-Campus Apartment can host any number of connections." This means that whenever the Runner installs a connection card, they can choose to install that card into the play area hosted on Off-Campus Apartment or as normal directly into the play area.
- b.linkIf a card has an ability describing cards it can host, but also one or more abilities that can create host relationships onto itself, then it only allows cards to become hosted on it through those abilities. A card cannot be installed directly onto the card through an unrelated install effect.
- Example: Glenn Station reads, "Glenn Station can host a single card", but also has a paid ability that hosts a card on itself. Therefore, Glenn Station only lets the Corp host cards through that paid ability, not through an install action.
- c.linkIf a card has an ability stipulating that it can only be installed hosted onto another card, then during the installation process a player that wishes to install that card must choose a valid destination matching the description provided. If no such destination exists before the installation process begins, the card cannot be installed.
- Example: Egret states, "Install only on a rezzed piece of ice." The Runner can only install Egret if there is an installed, rezzed piece of ice available before the installation process begins; otherwise, it is illegal for the Runner to install Egret.
- d.linkSome operations and events convert themselves into condition counters and install themselves hosted onto other cards. An operation or event can never be installed through an install effect; it can only become an installed counter through its conversion ability. See rule 10.1.4.
- 1.13.6.linkCards can be hosted faceup or facedown.
- a.linkUnless otherwise specified, a card that is hosted while it is being installed is hosted onto the destination card in the same faceup or facedown status it would normally be installed in.
- b.linkUnless otherwise specified, a card that is hosted without being installed is hosted faceup.
- c.linkLike other facedown installed cards, installed cards hosted facedown are distinct. The order in which they were installed (or turned facedown) is open information.
- d.linkCards hosted facedown without being installed must be kept in distinct groups according to their host. Cards within such a group are not ordered and can be freely arranged by their controller.
- 1.13.7.linkOnce a card is installed, hosted or not, a player cannot change that card's hosted status unless a card ability explicitly directs it to be hosted onto a new card.
- 1.13.8.linkHost relationships are not transitive. If card A is hosted on card B, and card B is hosted on card C, card A is not considered to be hosted on card C.
- Example: If the Runner installs a Leprechaun hosted on a Dhegdheer, programs hosted on Leprechaun do not have their install costs reduced because they are hosted on Leprechaun and not on Dhegdheer.
- 1.13.9.linkIf an ability on a card refers to a "hosted" card or counter, that ability only references objects hosted on that card.
- 1.13.10.linkHosted objects can be removed or spent from their host without affecting the host.
- 1.13.11.linkIf a host card changes zones, all objects hosted on that card (and all objects hosted on those objects, and so on) are trashed during the next checkpoint. This cannot be prevented. See section 10.3 for details on checkpoints.
- 1.13.12.linkCondition counters are the only type of counter that can host other objects. Hosting on condition counters follows the same rules as hosting on cards.
- 1.14.1.linkThe owner of a card is the player who provided that card at the start of the game as their identity, part of their deck, or an extra card along with their deck.
- a.linkA card that is converted into a counter retains its owner.
- b.linkNo player owns counters that are not converted cards.
- 1.14.2.linkThe controller of an object is the player responsible for that object.
- a.linkThe controller of a card in the play area is the player who installed or placed it there.
- b.linkThe Corp controls each agenda in the Corp's score area. The Runner controls each agenda in the Runner's score area.
- c.linkCards in other zones are controlled by their owner.
- d.linkEach player controls the credits in their credit pool.
- e.linkThe Corp controls each bad publicity counter. The Runner controls each tag counter. However, see rule 10.5.5 and rule 10.6.3 regarding paying costs that involve tags and bad publicity, respectively.
- f.linkThe controller of a counter hosted on a card is the player who controls the host card.
- g.linkClick counters and core damage counters are gameplay aids only and have no controller.
- 1.14.3.linkA player can only pay costs using objects they control.
- 1.14.4.linkThe controller of an ability is the player responsible for that ability. By default, this is the player who controls the ability's source. See also section 9.1.3. A player can only use abilities they control.
- a.linkUnless specifically stated otherwise, abilities on agendas are controlled by the Corp, even for agendas in the Runner's score area.
- b.linkSome abilities state that they can only be used by a specific player. The specified player controls each such ability, even if they do not control its source.
- 1.14.5.linkUnless otherwise noted, the controller of an ability carries out its effects and makes any choices required. If a player is specified to perform all or part of an effect, the specified player carries out that part of the effect and makes any choices required instead.
- Example: Rototurret's first subroutine reads, "Trash 1 installed program." Since Rototurret is a Corp card, the Corp chooses which installed program to trash. Conversely, Bulwark's first subroutine reads, "The Runner trashes 1 installed program." Since the Runner is specified to be carrying out this effect, they choose which of their installed programs to trash.
- a.linkSome trigger conditions care about effects performed by a particular player. These conditions are only met when that player is the one to carry out the relevant effect.
- Example: The Corp has a rezzed Hostile Infrastructure. Apocalypse does not specify who trashes the cards, so the Runner is responsible for the trashing and Hostile Infrastructure meets its trigger condition.
- Example: Alice Merchant states that "the Corp must trash 1 card from HQ", so the Corp carries out this effect even though Alice Merchant is a Runner card, and therefore Hostile Infrastructure does not meet its trigger condition.
- 1.15.1.linkMany abilities require players to choose 1 or more objects or subroutines to affect. Each object and subroutine chosen for an ability is a target of that ability.
- Example: Top Hat reads in part, "you may choose 1 of the top 5 cards of R&D and access it." The target of this instruction is the card in R&D the Runner chooses.
- Example: One of the subroutines on Colossus reads in part, "Trash 1 installed program and 1 installed resource." The targets of this subroutine are the two cards that will be trashed.
- Example: Trick of Light reads, "Choose 1 installed card you can advance. Move up to 2 advancement counters from 1 other card to the chosen card." The targets of this operation are the advancement counters to be moved and the destination card. If 2 tokens are chosen, they must be hosted on the same card.
- Example: The Runner is encountering a barrier and uses Cleaver to break subroutines. The targets of Cleaver's' interface ability are the 1 or 2 subroutines that it will break.
- a.linkCards found during a search are not considered targets of the instruction that performs the search. Players do not need to announce what card(s) they expect to find before the search actually takes place. See section 8.7 for rules about searching.
- b.linkOnly objects and subroutines are announced as targets. If an instruction directs a player to choose (or "name") a number, a card type, a subtype, a card name, a server, or one of a specified set of effects, that choice is not made until the instruction resolves.
- 1.15.2.linkImmediately before an instruction becomes imminent, the player resolving that instruction must first choose the targets required by that instruction. For each time the instruction requires a player to choose 1 or more objects and/or subroutines, that player announces appropriate targets. Once players are finished announcing targets for an instruction, the instruction becomes imminent, and players have the opportunity to modify the effects of that instruction with interrupt abilities before it resolves. See section 9.9.
- a.linkWhen a player announces a card as a target, they indicate clearly which card is being chosen without changing its facedown/faceup status or location.
- b.linkThe player resolving the instruction can only choose targets that are valid for that instruction. A target is valid for an instruction if it meets any specified requirements of that instruction or can otherwise be acted upon by that instruction.
- c.linkUnless an instruction explicitly specifies the zone from which an object must be selected as a target, only counters in the play area and installed cards are valid targets for that instruction.
- Example: The Corp resolves a subroutine that says "[sub] The Runner trashes 1 program." The Runner must trash 1 of their installed programs and may not trash a program from their grip or stack.
- d.linkSome effects allow a player to choose multiple cards as targets for a single announcement. Section 9.12.2 contains rules about resolving effects involving sets of cards.
- e.linkA player may announce the targets for an instruction in any order, but each object or subroutine can only be chosen as a target once for each announcement. If there are not enough valid targets available, then that player chooses as many distinct targets as possible and the remaining targets are not announced.
- Example: The Runner accesses an Aggressive Secretary with three advancement counters on it. The Runner only has two installed programs, so the Corp chooses both of those programs for Aggressive Secretary. After the programs have been chosen, they are both trashed simultaneously.
- f.linkTargets cannot be chosen for an instruction at any other time. Even if the game state changes due to interrupt abilities while the instruction is imminent, unannounced targets remain unchosen.
- 1.15.3.linkAt the time an instruction resolves, if any of its targets either have become invalid or were not announced, as much of that ability resolves as possible without acting on the unannounced or invalid targets, following rules 1.2.3 and 1.2.4 of the Golden Rules. A target can be invalid because the chosen object or subroutine no longer exists or because the target no longer meets other requirements specified by the targeting ability.
- 1.15.4.linkAfter the resolution of an instruction that chose a particular target, subsequent instructions of the same ability can continue to act on that target without needing to select it again, even if the ability moves the target or changes its properties. See also section 1.12.2.
- Example: Howler's ability targets a card in HQ. Its first instruction installs that card, and its second instruction creates a delayed conditional ability that refers to that card in the play area. The latter ability can find and act on the card as long as it is still installed.
- 1.16.1.linkIn order to use an ability or apply an effect, a player may be required to pay a cost. A cost can take the form of any card, counter, or other item a player must spend; an effect a player must resolve; or other type of requirement a player must meet. If a player cannot pay the full cost of an action or ability all at once with cards and counters they control, they cannot use the effect associated with that cost.
- a.linkThe act of paying a cost cannot be modified or cancelled by optional interrupt abilities.
- Example: The Runner can trash Clone Chip to trigger its paid ability, but cannot use LLDS Energy Regulator to prevent Clone Chip from being trashed this way.
- b.linkIf a static ability or a mandatory conditional ability interrupt would prevent the steps of paying a cost from being carried out if they were performed as an effect, that cost cannot be paid.
- Example: The Runner cannot pay the additional cost to steal Obokata Protocol while Guru Davinder is installed, because the Runner could not currently take 4 damage if instructed to: Guru Davinder's first ability would prevent the damage.
- Example: The Runner is playing as Jesminder Sareen and encounters Funhouse, without any other tag-related effects resolving earlier in the run. Since Jesminder's ability would prevent taking 1 tag, the Runner cannot take 1 tag to pay the nested cost in Funhouse's ability. Funhouse will end the run.
- c.linkIf triggering an ability or resolving an effect is subject to both costs and other restrictions, the cost cannot be paid unless all such restrictions are met, and cannot be paid in a way that would result in any restriction no longer being met.
- Example: The Runner controls Zer0 and Clan Vengeance, and wants to accumulate more power counters on Clan Vengeance. Zer0's ability has the restriction "Use this ability only once per turn." If the Runner has already used the ability this turn, they cannot suffer additional net damage by attempting (even unsuccessfully) to use the ability again.
- Example: The Corp installs Azef Protocol in the root of a server with a rezzed SanSan City Grid and advances Azef Protocol twice. Since SanSan City Grid reduces Azef Protocol's advancement requirement to 2, the Corp now meets the restriction necessary to score Azef Protocol, but must also pay its additional cost to score. The Corp cannot trash the SanSan City Grid to pay this cost, because paying the cost this way would return Azef Protocol's advancement requirement to 3, and the restriction to score it would no longer be met.
- d.linkA cost of 0 can still be paid by a player, even though no items are paid. Costs of 0 are not paid automatically. A player pays a cost of 0 by explicitly announcing they are paying it.
- Example: The Runner accesses a Beanstalk Royalties from R&D and announces that they are using the ability of Freedom Khumalo: Crypto-Anarchist to trash the Beanstalk Royalties. Even though the Runner does not remove any virus counters from any cards, they have still paid the cost.
- 1.16.2.linkThe actual contents of a cost can be dependent on the game state. Abilities can modify their own costs, modify costs of a certain type or that meet certain criteria, or include costs that need to be calculated.
- a.linkIf a quantity in a cost is subject to effects modifying its value, determine the final value of that quantity by taking its default value, applying each effect that increases the cost, and then applying each effect that lowers the cost. Finally, if the value determined by this process is less than 0, set the value to 0.
- b.linkSome abilities calculate a quantity using phrases like "for each", "for every", or "plus". Any time such a calculation appears in a cost, the result of that calculation is determined at the time the cost is to be paid. The result is taken as an aggregate, so that paying the cost is a single instance of whatever was paid. Note that additional costs (section 1.16.11) are not aggregated with other costs. See also Section 9.12.2 for rules about calculated quantities that appear in other contexts.
- Example: The Runner approaches a server protected by 3 advanced pieces of ice and with a rezzed Cayambe Grid in its root. They pay the nested cost in Cayambe Grid's ability. This cost is 1 payment of 6[c], not 3 payments of 2[c], so this only meets the trigger condition for 1 instance of GameNET's ability.
- c.linkSome costs contain the variable X. Before a player pays such a cost, they choose and announce a positive integer or 0 to be the value for X. The chosen value must follow any applicable restrictions.
- Example: Psychographics is an operation with a play cost of X. It also has the ability, "X must be equal to or less than the number of tags the Runner has." If the Runner has 3 tags, the Corp can choose 0, 1, 2, or 3 as the value for X when they play Psychographics.
- d.linkIf an ability needs to know the value of a cost in a context where that cost is not being paid, treat any X that appears in that cost as 0.
- 1.16.3.linkAfter a player pays a cost, a checkpoint occurs. See section 10.3.
- 1.16.4.linkThere are six main types of costs: install costs (found mainly on hardware, programs, and resources, and incurred when installing ice), play costs (found on operations and events), rez costs (found on assets, upgrades, and ice), paid ability trigger costs, additional costs, and nested costs.
- a.linkInstall costs, rez costs, and play costs are all costs that are inherent properties of cards. These costs are automatically applied to any ability that performs the corresponding effects (installing, rezzing, or playing) unless that ability stipulates otherwise. See also section 2.3 (for more about these costs as they appear on cards) and section 8.5.11, rule 8.1.2d and section 8.6.2 (for more about paying costs to install, rez, and play cards).
- b.linkThe presence of an install cost, rez cost, or play cost does not change the optional or mandatory status of an ability. If an effect directs a player to install, rez, or play a card, they must pay the associated cost if able. If they cannot, the card is not installed, rezzed, or played.
- c.linkIf an effect directs a player to install, rez, or play a card, but doing so has an additional cost, the player is not forced to pay the additional cost. If they decline to do so, they do not pay the install, rez, or play cost either, and the card is not installed, rezzed, or played.
- d.linkWhen a player takes an action that plays or installs one or more cards and has no other effects, the play cost or install cost of each of those cards is considered to have been spent to take that action, even though other steps take place between initiating the action and paying that cost.
- Example: The Corp has Jeeves Model Bioroids rezzed, and uses the basic action "[Click]: Play an operation." to play Blue Level Clearance. Both the click spent for the cost of the basic action and the click spent for Blue Level Clearance's additional cost count as clicks spent to take the "[Click]: Play an operation." action.
- 1.16.5.linkSome abilities direct a player to ignore certain costs when performing particular effects.
- a.linkIf a player is directed to ignore 1 or more of the 6 main types of costs, the specified costs are removed from the total cost that must be paid. Any other costs (usually additional costs) that are not specified to be ignored still apply normally.
- b.linkIf a player is directed to ignore "credit costs", any credits to be paid from any type of cost are removed from the total cost. Any costs that do not consist of credits still apply normally.
- c.linkIf a player is directed to ignore "all costs", all elements of the relevant cost are removed, including additional costs, so that the total cost becomes 0.
- 1.16.6.linkThe install cost of a card must be paid to install that card.
- a.linkThe install cost of a program, resource, or piece of hardware is listed on the card itself.
- b.linkThe install cost of a piece of ice is a number of credits equal to the number of pieces of ice already protecting the server that ice will be installed protecting.
- c.linkThere is no cost to install an asset, upgrade, or agenda.
- 1.16.7.linkThe play cost of an operation or event must be paid to play that card. It is listed on the card itself.
- 1.16.8.linkThe rez cost of an asset, upgrade, or piece of ice must be paid in order to rez that card. It is listed on the card itself.
- 1.16.9.linkThe trigger cost of each paid ability is the first part of that ability's text. It is followed by a colon (:) and then the ability's effect. See section 9.5 for more details on paid abilities.
- 1.16.10.linkAn additional cost adds something to the regular cost of initiating a particular game effect. A player must pay all additional costs along with any regular costs in order to initiate an effect.
- a.linkIf a player would be forced to carry out a game effect, but doing so has an additional cost, that player may decline to pay the additional cost, even if they are able to pay it, thus preventing that effect from occurring.
- Example: The Runner accesses Obokata Protocol. Normally the Runner must steal agendas that they access, but because Obokata Protocol has an additional cost to steal, the Runner can decline to suffer the net damage and not steal the agenda.
- b.linkA player must pay all additional costs simultaneously with the cost that is being added to, even if multiple cards or abilities are adding separate additional costs. A player cannot pay the original cost or any of the additional costs individually. If they cannot pay for all of the costs at once, then they do not pay any of the costs and the corresponding effects cannot occur.
- Example: The Runner accesses Obokata Protocol while Ben Musashi and Predictive Algorithm are both active. The Runner must be able to pay 2 credits and suffer 6 net damage all at once in order to steal the Obokata Protocol, even though each of the three costs are from different card abilities. After all costs have been paid, abilities that meet their trigger conditions from the paying of any of those costs, such as I've Had Worse or Order of Sol, can then resolve as applicable.
- c.linkIf an additional cost is required for an effect that does not normally require paying any cost, the additional cost is paid and a checkpoint is resolved before performing the usual procedure to carry out that effect. See also rule 10.3.4.
- Example: The Corp is playing Ob Superheavy Logistics and initiates scoring Azef Protocol, which has an additional cost to score of "trash one of your other installed cards." If the Corp trashes a rezzed card, meeting the trigger condition for Ob's ability, this ability will resolve following the checkpoint associated with paying the cost. This happens before Azef Protocol is added to the Corp's score area or any trigger conditions related to scoring an agenda are met.
- 1.16.11.linkA nested cost is a cost appearing within an ability's instructions that must be paid while the ability is resolving in order for some or all of the rest of the effects of that ability to resolve.
- a.linkNested costs are usually written in the format "[player] may [cost] to [instructions]" or "[player] may [cost]. If [you/they] do, [instructions]." If the indicated player pays the indicated cost, the indicated instructions are resolved. Otherwise, that part of the ability is not resolved.
- b.linkNested costs can also be written in the format "[instructions] unless [player] [cost]" or "[player] may [cost]. If [you/they] do not, [instructions]." If the indicated player pays the indicated cost, the indicated instructions are not resolved. Otherwise, that instruction is resolved.
- Example: A subroutine reading "End the run unless the Runner pays 1[c]." contains a nested cost. If the Runner chooses to pay 1[c], the subroutine will not end the run.
- c.linkAn ability that reads "If [you/they] do" or "If [you/they] do not" without a preceding "may" does not indicate a nested cost.
- d.linkSome abilities use the word "otherwise" to indicate that different instructions should be resolved depending on whether a nested cost was paid or not. In an ability with a nested cost of a form described in rule 1.16.11a, treat "otherwise" as an "if [you/they] do not" clause attached to the same cost. Conversely, in an ability with a nested cost of a form described in rule 1.16.11b, treat "otherwise" as an "if [you/they] do" clause attached to the same cost. Note that "otherwise" can also appear in the context of other types of conditions, and does not by itself indicate a nested cost.
- 1.17.1.linkThe sum of all agenda points on agendas in a player's score area is that player's score.
- a.linkThe threat level is equal to the greatest score of any player. The "Threat N" ability flag makes use of the threat level (rule 9.3.6f).
- Example: If the Runner's score is 4 agenda points, and the Corp's score is 3 agenda points, the threat level is 4.
- 1.17.2.linkIf at any time a player's score is greater than or equal to 7, they win the game at the next checkpoint. See section 1.7 regarding winning the game, and section 10.3 for details about checkpoints.
- 1.17.3.linkPlayers add agendas to their score areas by scoring or stealing them. The Corp can score an agenda to their score area as an option during certain paid ability windows on their turn. The Runner can steal an agenda to their score area while accessing it.
- a.linkThe advancement requirement of an agenda restricts when the Corp can score it. The Corp can only score an agenda that has advancement counters on it greater than or equal to its advancement requirement. See section 1.18.
- b.linkThe Corp is not required to score an agenda immediately upon satisfying its advancement requirement.
- c.linkScoring an agenda does not cost [click] and is not an action.
- d.linkThe Runner cannot decline to steal an agenda they access, unless there is an additional cost to steal that agenda and the Runner cannot or does not wish to pay it. Section 7 details accessing, and section 1.16.10 details additional costs.
- e.linkIf an effect directly adds an agenda to a score area or otherwise moves an agenda from any zone to a score area, that agenda is not considered scored or stolen.
- f.linkIf an effect causes another card to be added to a score area "as an agenda", the newly converted agenda is not considered scored or stolen. See rule 10.1.3.
- 1.17.4.linkAgendas are always added to the score area faceup, regardless of their previous faceup/facedown status.
- 1.17.5.linkIf an installed agenda is scored or stolen, it becomes uninstalled. Any advancement counters on the scored or stolen agenda are returned to the bank. See rule 1.13.11.
- 1.17.6.linkSome agendas and other cards have abilities with a trigger condition related to an agenda being scored. These abilities become pending after the Corp moves the agenda from its current zone to their score area.
- 1.17.7.linkSome agendas and other cards have abilities with a trigger condition related to an agenda being stolen. These abilities become pending after the Runner moves the agenda from its current zone to their score area.
- 1.17.8.linkIf an ability meets its trigger condition from an agenda being scored or stolen, the agenda's last known number of advancement counters before being scored or stolen is used for any references to the number of advancement counters in the effects of that ability.
- 1.18.1.linkTo advance a card is to place an advancement counter from the bank on it. The Corp typically advances cards with a basic action during their action phase, but card abilities can also advance cards.
- 1.18.2.linkResolving an instruction that directly places an advancement counter onto a card is not the same as advancing a card. Likewise, resolving an instruction that moves an advancement counter from one card to another is not the same as advancing a card.
- Example: The Corp plays Mushin-no-Shin, choosing to install an Oaktown Renovation. Because the three advancement counters were placed on the card directly, the Corp does not gain any credits from the ability on Oaktown Renovation.
- 1.18.3.linkThe Corp can only advance certain installed cards. Agendas can always be advanced. If a card other than an agenda says that it "can be advanced" or that "you can advance" that card, the card can be advanced even while it is unrezzed. There is no limit to the number of times a card can be advanced.
- 1.18.4.linkAn "advanced card" is a card with 1 or more advancement counters hosted on it.
- 1.19.1.linkTrashing is the act of moving an object to its owner's discard pile.
- 1.19.2.linkDuring access, the Runner has the opportunity to pay the trash cost of the accessed card to trash it. See section 7.1.5.
- 1.19.3.linkA trashed card is not considered to have been discarded, and vice versa. Cards that prevent a card from being trashed cannot prevent a card from being discarded.
- 1.19.4.linkThe symbol [trash] represents trashing the object it appears on. It is used as a cost for certain abilities.
- Example: Fall Guy's last ability reads "[trash]: Gain 2[c]." The cost to trigger this ability is to trash Fall Guy.
- a.link"A [trash] ability" refers to a paid ability that includes [trash] in its trigger cost.
- b.linkSome paid abilities have multiple options for their trigger cost, separated by "or". A player triggering such an ability only "used a [trash] ability" if the actual cost that was paid includes [trash].
- 1.20.1.linkA memory unit (MU) is a space available to the Runner to install programs. Memory units always appear with a quantity, such as 2[MU], which means "2 memory units."
- 1.20.2.linkThe Runner's memory limit is the total number of memory units the Runner has. If the Runner's identity card does not specify a starting memory limit, their starting memory limit is 4[MU]. Card abilities that indicate +[MU] apply that increase to the Runner's memory limit.
- Example: The Runner has Astrolabe installed, which has the ability "+1[MU]". The Runner can therefore have up to 5[MU] worth of programs installed.
- 1.20.3.linkPrograms have a memory cost that is continually applied against the memory limit. section 3.9.3 details how the Runner's installed programs are constrained by the memory limit.
- 1.21.1.linkCards in the play area and other public zones are either faceup or facedown. Faceup cards are freely visible to all players. Facedown cards are oriented so that the face containing the card's information is not visible.
- a.linkCards in hidden or secret zones (see section 4.1) are neither faceup nor facedown.
- b.linkSome effects host multiple cards on an object at the same time or set aside multiple cards at the same time. Facedown cards that enter a zone at the same time by the same effect are treated as a group. See section 1.13.6 and rule 4.8.7, respectively.
- 1.21.2.linkWhen a player looks at a card, they are allowed to see the front face of the card even if the front face would not normally be visible to them. A player should look at that card without showing it to the other player if it is not normally visible to that player.
- a.linkA player may look at facedown cards they control at any time.
- 1.21.3.linkTo reveal a card is to show its front face to all players, then return it to its previous state.
- 1.21.4.linkSome abilities instruct the Runner to expose one or more cards. To expose a card is to reveal it, except that only installed, unrezzed cards can be exposed.
- 1.21.5.linkEffects that instruct a player to look at, reveal, expose, or access a card are not the same, even if they would be performed similarly at times. See section 7 for more information on accessing.
- 1.21.6.linkIf a resolving ability directs one or both players to look at or reveal a card or set of cards, each such card remains visible to the relevant player(s) until the entire ability is finished resolving or the card moves to a different location.
- 1.21.7.linkThe ability "While the Runner is accessing this [type] in R&D, they must reveal it." is a static ability that applies for the entire duration of the access. This is also the case for cards with the older wording, "If [this card] is accessed from R&D, the Runner must reveal it."
- 2.1.1.linkThe identifier of a card is its name, alternatively referred to as its title. It is written along the top of the card for identities, agendas, ice, operations, events, and resources, or immediately below the art box in the case of assets, upgrades, hardware, and programs.
- 2.1.2.linkIdentities have a subtitle written immediately below the main title line. Their full name is the combination of their main title and subtitle.
- 2.1.3.linkWhen a card refers to its own name, it is a self-reference. See rule 10.1.5.
- 2.1.4.linkWhen a card refers to "copies of" cards with a particular name, it refers to any card with that name.
- 2.1.5.linkIf a player is directed to choose or search for cards "with different names", each card chosen or found by the search must have a different English name from every other card chosen or found. See also section 8.7.
- 2.2.1.linkSome cards are unique, and have a unique symbol (◆) before their name to designate this. See rule 10.1.1.
- 2.3.1.linkThe play, install, or rez cost of a card is a number that appears in the top-left corner of most card types. Play and install costs appear within a large circular icon, while rez costs appear within a small octagonal icon.
- 2.3.2.linkPlay, install, and rez costs on cards are all paid in credits. section 8 details how cards are played, installed, and rezzed.
- 2.3.3.linkEvents and operations have a play cost.
- 2.3.4.linkHardware, programs, and resources have an install cost.
- a.linkIce also has an install cost, but it does not appear on the card. The install cost of ice is determined by the configuration of other installed ice rather than being intrinsic to the card. See section 1.16.6.
- 2.3.5.linkAssets, ice, and upgrades have a rez cost.
- 2.4.1.linkThe advancement requirement appears only on agendas. It is a number in the top-right corner of the card, within a small circle.
- 2.4.2.linkSection 1.17 details how agendas are scored and the purpose of the advancement requirement.
- 2.5.1.linkThe agenda point value appears only on agendas. It is the number in the center-left of the card, on top of a graphic depicting three pillars.
- 2.5.2.linkThe agenda points in a player's score area contribute toward that player winning the game. See section 1.7.
- 2.6.1.linkAssets, upgrades, and some ice and operations have trash costs. A trash cost is a number appearing in the lower-right corner of the card within a [trash] symbol.
- 2.6.2.linkSection 7.1.5 details how the Runner can trash a card they access by paying its trash cost.
- 2.7.1.linkStrength is a number appearing on ice and on icebreaker programs. It appears on the bottom-left corner of the card within a large semicircle.
- 2.7.2.linkNon-icebreaker programs have a dash ([dash]) in the bottom-left corner instead of a strength value.
- 2.7.3.linkSection 3.9.5 discusses the interaction between ice strength and icebreaker strength.
- 2.8.1.linkMemory Cost is a number appearing only on programs. It appears to the right of the install cost, within an [MU] symbol.
- 2.8.2.linkSection 1.20 discusses the topic of memory, and section 3.9.3 details how programs interact with the Runner's memory limit based on their memory cost.
- 2.9.1.linkBase link is a number appearing in the top-left of Runner identity cards.
- 2.9.2.linkThe Runner's base link contributes to their link value. section 10.7 defines how the Runner's link value is calculated, and section 10.8 explains how it contributes to contesting trace attempts.
- 2.10.1.linkStarting memory limit is a number appearing near the top-left of Runner identity cards, within the [MU] symbol.
- 2.10.2.linkThe Runner's memory limit is checked against the total memory cost of programs they have installed. This value is calculated by applying any active modifiers to the Runner's starting memory limit. See section 1.20.
- 2.11.1.linkMinimum deck size is a number shown as the uppermost of two small boxes in the lower-left of Corp identities and the lower-right of Runner identities.
- 2.11.2.linkSection 1.4 details the rules for building a deck, including the requirement to adhere to the minimum deck size of the deck's associated identity.
- 2.12.1.linkThe influence limit is a number shown as the lowermost of two small boxes in the lower-left of Corp identities and the lower-right of Runner identities.
- 2.12.2.linkSection 1.4 details the rules for building a deck, including the requirement that out-of-faction cards in the deck adhere to the influence limit of the associated identity.
- 2.13.1.linkCards are divided into ten factions: four Corp factions, three Runner factions, and three Runner mini-factions. Factions and influence restrict deckbuilding options, allowing each faction to have distinct play differences from one another.
- a.linkThe Corp factions are Haas-Bioroid, Jinteki, NBN, and the Weyland Consortium.
- b.linkThe major Runner factions are Anarch, Criminal, and Shaper.
- c.linkThe Runner mini-factions are Adam, Apex, and Sunny Lebeau.
- 2.13.2.linkA card's faction can be identified by the color of its background, as well as a faction logo in one of its four corners. This logo also appears as a watermark behind the text box. If a card has a white background and no logo, it is neutral.
- 2.13.3.linkEach identity is associated with one faction. section 1.4 details how factions affect deckbuilding.
- 2.14.1.linkA card's influence cost, or influence value, is represented in a bar with 5 circular slots near the bottom of most cards. The influence cost is the number of slots that are filled with a blue circle, and can range from 0 to 5.
- 2.14.2.linkSome cards cannot be played out of faction, and therefore do not have an influence value, which is different from an influence cost of "0". These cards do not have the influence bar at all.
- 2.14.3.linkSome Corp cards have the subtype alliance and text defining adjustments to their influence costs. The ability adjusting the influence cost of an alliance card applies only when determining the legality of an already constructed deck and does not have any effect during gameplay. The ability references other cards included in the deck to determine whether the card should apply its printed influence cost or 0 against the deck's influence limit.
- 2.14.4.linkSection 1.4 details how a card's influence cost (or lack thereof) affects deckbuilding.
- 2.15.1.linkA card's types appear as a line of text across the center of non-ice cards above the text box. For ice, they run along the left side of the text box, rotated 90° from the rest of the text.
- 2.15.2.linkEach card has one card type, which can be identity, agenda, asset, ice, operation, upgrade, event, hardware, program, or resource. It is written in bold at the beginning of the type line.
- 2.15.3.linkWhile inactive, a card is still considered a card of the type printed on it, with the exception of facedown installed Runner cards. See section 8.1.4.
- 2.15.4.linkAbilities can change a card from its printed type to an agenda. See rule 10.1.3.
- 2.15.5.linkCounters never have card types.
- 2.16.1.linkCards may have one or more subtypes, which are written following the primary type. Subtypes are card descriptors that can be referenced by card abilities. Cards that share a subtype often share a distinct characteristic or ability.
- a.linkThe subtypes region, console, and icebreaker have special rules, discussed in sections 3.6.5, 3.8.5 and 3.9.5 respectively. Other subtypes have no intrinsic rules meaning.
- 2.16.2.linkIn card text, subtypes are always referenced in bold text. If a word or phrase that is also a subtype appears in a card's text but is not in bold text, that word or phrase does not reference the subtype.
- 2.16.3.linkSome abilities reference cards by a lack of subtype, such as "non-virus". These abilities can only affect cards that do not have the specified subtype, regardless of any other subtypes the cards do have.
- 2.16.4.linkA card has all of its subtypes at all times, even while inactive, with the exception of facedown installed Runner cards. See section 8.1.4.
- 2.16.5.linkAbilities can add or remove subtypes. The number of times a card has, gains, and loses each subtype is tracked as a running total, but the result is binary: if the total number of instances of the subtype exceeds the number of times it is removed, the card has that subtype. Otherwise, it does not.
- Example: The Runner plays Tinkering on a Lycan hosting 1 advancement counter. Lycan has two instances of sentry, one printed and one from Tinkering, and has lost one instance of sentry from its own ability. Thus it is still a sentry.
- 2.16.6.linkIf an effect requires a player to choose a subtype, that player must choose a single subtype that has been printed on at least one card. If a player is required to choose a subtype belonging to a specific card type, they must choose a subtype that has been printed on at least one card with that type.
- 2.16.7.linkBelow is a list of all subtypes.
- a.linkThe identity subtypes are Bioroid, Clone, Corp, Cyborg, Digital, Division, G-mod, Megacorp, Natural, Police Department, Stealth, and Subsidiary.
- b.linkThe agenda subtypes are Ambush, Assassination, Expansion, Expendable, Initiative, NEXT, Psi, Public, Research, Security, Sensie, and Source.
- c.linkThe asset subtypes are Academic, Advertisement, Alliance, Ambush, Beanstalk, Bioroid, Cast, Character, Clone, Corporation, Enforcer, Executive, Facility, Government, Hostile, Illicit, Industrial, Political, Psi, Region, Research, Ritzy, Seedy, and Transaction.
- d.linkThe ice subtypes are AP, Advertisement, Ambush, Barrier, Bioroid, Code Gate, Deep Net, Deflector, Destroyer, Expendable, Grail, Harmonic, Illicit, Morph, Mythic, NEXT, Observer, Psi, Sentry, Tracer, and Trap.
- e.linkThe operation subtypes are Alliance, Black Ops, Condition, Current, Double, Gray Ops, Illicit, Lockdown, Mandate, Psi, Reprisal, Terminal, Transaction, and Triple.
- f.linkThe upgrade subtypes are Academic, Advertisement, Alliance, Ambush, Beanstalk, Bioroid, Character, Clone, Enforcer, Executive, Expendable, Facility, Hostile, Off-site, Orgcrime, Psi, Region, Ritzy, Seedy, Security Protocol, Sysop, and Unorthodox.
- g.linkThe event subtypes are Condition, Current, Double, Job, Mod, Orgcrime, Priority, Run, Sabotage, Stealth, and Terminal.
- h.linkThe hardware subtypes are Chip, Companion, Console, Consumer-grade, Cybernetic, Gear, Link, Mod, Stealth, Vehicle, and Weapon.
- i.linkThe program subtypes are AI, Caïssa, Cloud, Daemon, Decoder, Deep Net, Deva, Fracter, Icebreaker, Killer, Stealth, Trojan, Virus, and Weapon.
- j.linkThe resource subtypes are Clan, Clone, Companion, Connection, Directive, Genetics, Government, Job, Link, Location, Remote, Ritzy, Sabotage, Seedy, Source, Stealth, and Virtual.
- 2.17.1.linkThe text box is the central area on a card containing any abilities the card has. Abilities usually only apply when the card they appear on is active. Section 9.1.8 details exceptions.
- 2.17.2.linkMany cards have italicised text written after their game text. This is flavor text, and has no effect on the game or the function of the card, nor can other abilities reference or interact with it.
- 2.17.3.linkSome cards have italicised text in parentheses. This is reminder text, and has no effect on the game or the function of the card, nor can other abilities reference or interact with it directly. Reminder text simply summarizes a rule that may apply to that card text.
- 3.1.1.linkEach player starts the game with a single identity active in the play area. See section 1.6.
- a.linkSome identities are double-sided. Only the front side of a double-sided identity will have values for its minimum deck size and influence limit. Only the side of a double-sided identity that is currently faceup is active at any given time.
- b.linkIdentities are not installed.
- 3.1.2.linkOnly identity cards have minimum deck sizes and influence limits. These values do not apply during the game; instead, they determine deckbuilding constraints for decks associated with that identity. See section 1.4.
- 3.1.3.linkOnly Runner identities have a base link. This value is used in calculating the Runner's link value. See section 10.7.
- 3.1.4.linkThe Corp's identity card is used to mark the location of HQ. See section 4.3.8.
Agendas represent valuable pieces of Corporate data. When the Corp advances and scores agendas, it represents completion of critical Corporate projects. When the Runner steals agendas, it represents their acquisition of secret Corporate data.
- 3.2.1.linkThe Corp may install agendas only in the roots of remote servers. There can be only one agenda or one asset installed in the root of any given remote server at a time. See section 4.6.8.
- 3.2.2.linkOnly agendas have advancement requirements and agenda points. See section 1.17.
- a.linkAn agenda's advancement requirement is the minimum number of advancement counters that must be on that agenda for the Corp to score it.
- b.linkThe agenda points on an agenda contribute to a player's score while the agenda is in their score area.
- 3.2.3.linkAgendas cannot be rezzed and are inactive while installed. Agendas are active in the Corp's score area. Agendas are inactive in the Runner's score area unless the agenda's card text specifies otherwise. See section 4.5.
- a.linkSome agendas may be installed faceup or turned faceup through card abilities. Faceup agendas are neither rezzed nor unrezzed. If an agenda's printed text directs the Corp to install it faceup, that agenda's abilities are active while it is installed.
- b.linkSome agendas modify the requirements for stealing or scoring them. These abilities are always active, according to any restrictions or requirements specified. See section 9.1.8.
- 3.2.4.linkAgendas can always be advanced. See section 1.18.
Assets represent various resources and connections at the Corp's disposal.
- 3.3.1.linkThe Corp may install assets only in the roots of remote servers. There can be only one agenda or one asset installed in the root of any given remote server at a time. See section 4.6.8.
- 3.3.2.linkAssets are among the card types that have rez costs. They are installed unrezzed and remain inactive until the Corp rezzes them by paying their rez costs during a paid ability window. See section 8.1.
- 3.3.3.linkAssets are among the card types that have trash costs. If the Runner accesses an asset, they may pay the trash cost to trash that asset. See section 7.1.5.
- 3.3.4.linkOne asset, Lady Liberty, has the subtype region and the text "Limit 1 region per server." See section 3.6.5 for rules governing region cards.
Ice are sophisticated security systems that protect Corporate servers through a variety of means. "Ice" has been suggested to stand for a variety of expressions, but is most commonly expanded as "Intrusion Countermeasures Electronics".
- 3.4.1.link"Ice" and "piece of ice" are synonymous.
- 3.4.2.linkIce are the only type of card installed protecting servers. Ice are not installed in the roots of servers. See section 4.6.9.
- a.linkIce protecting a server are laid out horizontally in front of that server, with the outermost piece of ice furthest from the server.
- b.linkWhen the Corp installs a piece of ice, they must install it in the outermost position protecting a server. See section 8.5.
- 3.4.3.linkIce are among the card types that have rez costs. They are installed unrezzed and remain inactive until the Corp rezzes them by paying their rez costs. See section 8.1.
- a.linkUnlike assets and upgrades, ice can normally only be rezzed while being approached during a run. See section 6.4.
- 3.4.4.linkIce are among the card types that have strength. An ice's strength determines which icebreakers are allowed to interface with it. See section 3.9.5.
- a.linkIf an ability modifies the strength of a piece of ice for the remainder of a run, and that ability resolves during an encounter outside of a run, the modification instead lasts for the remainder of that encounter.
- Example: The Runner accesses and encounters an Archangel in HQ with Gang Sign. The Runner uses Devil Charm to lower the strength of Archangel. That strength reduction would normally last for the remainder of the current run, but since no run is in progress, it instead lasts for the remainder of the encounter.
- 3.4.5.linkSome ice have trash costs. If the Runner accesses an ice with a trash cost, they may pay the trash cost to trash that ice. See section 7.1.5.
- a.linkUnlike assets, upgrades, and agendas, ice are not normally accessed while installed. Encountering a piece of ice does not entail accessing that ice and does not give the Runner an opportunity to pay its trash cost.
- 3.4.6.linkIce are the only Corp cards with install costs. The install cost of a piece of ice is not a printed value but instead a calculated value based on the number of other ice already protecting the relevant server. See section 1.16.6.
- 3.4.7.linkIce are the only cards with subroutines. See section 9.8.
- 3.5.1.linkOperations are the only Corp cards that are played. Operations are never installed. Playing an operation causes its abilities to become active, and once those abilities are fully resolved the operation is trashed. See section 8.6.
- a.linkSome operations have the subtype condition. As part of their abilities, condition operations convert themselves into condition counters and install themselves. A condition operation cannot be installed by an install effect; it can only be installed through its own conversion ability. See rule 10.1.4.
- b.linkSome operations have the subtype current. As part of their abilities, current operations prevent themselves from being trashed until another current operation or event is played or the Runner steals an agenda. When one of these occurs, the active current is trashed during the next checkpoint. See section 10.3.
- c.linkSome operations have the subtype lockdown. As part of their abilities, lockdown operations prevent themselves from being trashed until the start of the Corp's next turn after the operation is played. Once the Corp's turn begins, this effect expires and the operation is trashed during the next checkpoint, before any conditional abilities marked pending at that time can be triggered. See section 10.3.
- 3.5.2.linkOperations are the only Corp cards with play costs. An operation's play cost is the number of credits the Corp must spend to play the operation. See section 8.6.
- 3.5.3.linkSome operations have trash costs. If the Runner accesses an operation with a trash cost, they may pay the trash cost to trash that operation. See section 7.1.5.
- 3.6.1.linkThe Corp may install upgrades in the root of any server. Upgrades are the only card type that can be installed in the root of a central server.
- 3.6.2.linkThere is no limit to the number of upgrades that can be installed in the root of a single server.
- 3.6.3.linkUpgrades are among the card types that have rez costs. They are installed unrezzed and remain inactive until the Corp rezzes them by paying their rez costs during a paid ability window. See section 8.1.
- 3.6.4.linkUpgrades are among the card types that have trash costs. If the Runner accesses an upgrade, they may pay the trash cost to trash that upgrade. See section 7.1.5.
- 3.6.5.linkRegions
- a.linkSome upgrades have the subtype region. All regions have the text "Limit 1 region per server."
- b.linkThe region limitation applies only to cards with the subtype region that are installed or in the process of being installed in the root of a server. It does not apply to cards in central servers, and it does not apply to ice.
- c.linkThe region limitation applies to all cards as specified in rule 3.6.5b, regardless of the active or inactive state of those cards.
- d.linkWhen the Corp installs a card with the subtype region into the root of a server that already has a region, they must trash the already-installed region. See section 8.5.
- e.linkThe Corp cannot swap a region card with a non-region card in another location if there is another region card already installed in the destination location.
- 3.7.1.linkEvents are the only Runner cards that are played. Events are never installed. Playing an event causes its abilities to become active, and once those abilities are fully resolved the event is trashed. See section 8.6.
- a.linkOne event, On the Lam, has the subtype condition. As part of its abilities, it converts itself into a condition counter and installs itself. This event cannot be installed by an install effect; it can only be installed through its own conversion ability. See rule 10.1.4.
- b.linkSome events have the subtype current. As part of their abilities, current events prevent themselves from being trashed until another current operation or event is played or the Corp scores an agenda. When one of these occurs, the active current is trashed during the next checkpoint. See section 10.3.
- 3.7.2.linkEvents are the only Runner cards with play costs. An event's play cost is the number of credits the Runner must spend to play the event. See section 8.6.
The Runner's hardware are the physical tools at their disposal: the computers, chips, and other machinery that make up their rig.
- 3.8.1.link"Hardware" and "piece of hardware" are synonymous.
- 3.8.2.linkThe Runner installs hardware into the play area.
- 3.8.3.linkHardware are among the types of cards with install costs. The Runner installs a hardware faceup and active by paying its install cost. See section 8.5.
- 3.8.4.linkThere is no limit to the number of hardware the Runner can have installed.
- 3.8.5.linkConsoles
- a.linkSome hardware have the subtype console. All consoles have the text "Limit 1 console per player."
- b.linkIf a player ever controls more than one installed console, all but the most recently active console are trashed. Trashing cards this way cannot be prevented.
- c.linkThis limitation applies only to hardware with the subtype console.
- d.linkThis limitation applies only to active console. A player can have multiple copies of a console, and even different consoles, in their deck.
Programs are digital tools at the Runner's disposal, primarily used as a means of intrusion.
- 3.9.1.linkThe Runner installs programs into the play area.
- 3.9.2.linkPrograms are among the types of cards with install costs. The Runner installs a program faceup and active by paying its install cost. See section 8.5.
- 3.9.3.linkPrograms are the only card type that have a memory cost. A program's memory cost is the number of memory units that program requires while it is installed.
- a.linkInstalling a program does not permanently consume memory. The program claims its designated quantity of memory units until it becomes uninstalled, at which point those memory units become available for use by other programs.
- b.linkWhen the Runner installs a program that would increase the total memory cost of installed programs over their memory limit, they must trash one or more installed programs such that the total memory cost of installed programs including the new program will not exceed their memory limit. See section 8.5.
- c.linkIf the Runner's memory limit decreases below the total memory cost of installed programs, or if the total memory cost of installed programs increases above the memory limit for any reason other than installing another program, the Runner must trash one or more installed programs such that the total memory cost of the remaining programs does not exceed their memory limit. This occurs during the next checkpoint after the memory limit is exceeded. See section 10.3.
- d.linkA program's memory cost is not a cost. It cannot be increased, lowered, ignored, or otherwise modified by abilities that affect costs to install programs.
- 3.9.4.linkPrograms are among the card types that have strength.
- a.linkPrograms with the subtype icebreaker have a printed numerical strength value. An icebreaker's strength determines which ice it is allowed to interface with. See section 3.9.5.
- b.linkPrograms without the subtype icebreaker do not have a strength value. A dash (–) is printed on non-icebreaker program cards in the place where strength is printed on icebreaker program cards.
- 3.9.5.linkIcebreakers
- a.linkSome programs have the subtype icebreaker. Icebreaker programs have strength and abilities that interface with ice.
- b.linkPaid abilities on an icebreaker that modify that icebreaker's strength implicitly have a duration of "for the remainder of the current encounter".
- Example: Corroder has the ability "1[c]: +1 strength."" Since no duration is specified, this strength increase applies until the end of the current encounter.
- c.linkIf an icebreaker's paid ability specifies another duration for modifying its strength, that modification lasts until both the stated duration and the implicit encounter duration have expired.
- Example: Gordian Blade has the ability "1[c]: +1 strength for the remainder of this run." This ability applies until the end of the current run, whether it is triggered during an encounter or another step of the run. If the ability is triggered during an encounter that takes place outside of a run, the strength increase applies for the duration of that encounter.
- d.linkIf an icebreaker's paid ability modifies its strength outside of an encounter and does not specify another applicable duration, the modification expires during the next checkpoint.
- Example: If the Runner uses Corroder's ability to increase its strength outside of an encounter, it applies only until the next checkpoint.
- e.linkAll icebreakers have abilities that interface with ice, sometimes referred to as "interface abilities". These abilities are indicated by the "interface" flag preceding the ability's text.
- f.linkThe Runner can only use an interface ability during step 6.9.3b of an encounter, and can only choose the encountered piece of ice and its subroutines as targets for the ability's effects. See section 1.15 for more information about targeting.
- g.linkThe Runner can only use an interface ability on an icebreaker if the icebreaker has strength greater than or equal to the strength of the encountered ice.
- h.linkIf an interface ability specifies that it affects a particular subtype of ice, then that ability can only be used on a piece of ice that has the specified subtype. If an ability on an icebreaker does not specify a subtype of ice that it affects, that ability can be used on any piece of ice.
Resources are a wide variety of connections and skills that aid the Runner.
- 3.10.1.linkThe Runner installs resources into the play area.
- 3.10.2.linkResources are among the types of cards with install costs. The Runner installs a resource faceup and active by paying its install cost. See section 8.5.
- 3.10.3.linkThere is no limit to the number of resources the Runner can have installed.
- 3.10.4.linkWhile the Runner is tagged, the Corp may spend [click] and 2[c] to trash an installed resource as a basic action. See section 10.5.
- 4.1.1.linkA zone is a place in which cards and counters can exist during the game.
- a.linkThere are 8 zone types: deck, hand, discard pile, score area, play area, bank, set aside, and removed from the game.
- b.linkEach player has their own deck, hand, discard pile, and score area. All players share the play area, the bank, the set-aside zone, and the removed-from-game zone.
- c.linkEach card in the game exists in exactly 1 zone at a time.
- 4.1.2.linkGame rules and card effects can move cards and counters between zones. See section 8.2 for rules on card movements.
- a.linkIf a facedown card or a card in a hidden zone would ever move to another zone as part of an effect that requires that card to have a specific attribute, that card must be revealed before being moved to the new zone. If the card is being installed, this rule only applies as indicated by section 8.5.13.
- Example: When resolving Clone Suffrage Movement, the Corp chooses a facedown Fast Break in Archives. The Corp must reveal the Fast Break before adding it to HQ, to demonstrate that it is indeed an operation, meeting Clone Suffrage Movement's requirement.
- b.linkWhen a card is moved from one zone to another, the move is instantaneous. The card is never in both zones at once, and it is never not in any zone at all.
- 4.1.3.linkA card that is not in any zone is outside the game. Cards outside of the game are distinct from cards in the removed-from-game zone, and cannot affect the game. They can only be affected by abilities that explicitly bring in extra cards from outside the game. See section 1.5.
- 4.1.4.linkA public zone is one where cards are freely visible to both players unless they are facedown. The play area, the bank, the set-aside zone, the removed-from-game zone, and both players' score areas and discard piles are public zones. See section 1.21 for rules on card visibility and section 8.1 for rules on the faceup and facedown status of a card.
- 4.1.5.linkA hidden zone is one where cards are not visible to either player. Each player's deck is a hidden zone.
- 4.1.6.linkA secret zone is one where cards are visible only to their controller. Each player's hand is a secret zone.
- 4.1.7.linkA location is a specific position within a zone that an object can occupy. A destination is a location to which an object is to be moved.
- a.linkA card in a player's deck has a location identified by how many cards it is from the top of that deck.
- b.linkSome objects in the play area are in specific locations. See section 4.6.5.
- c.linkThe location of a hosted object is its host card.
- d.linkAll other objects are simply located in their zone and do not have a more specific location.
- 4.2.1.linkWhen the game begins, each player's deck presented during setup becomes their in-game draw deck.
- 4.2.2.linkDecks must be kept facedown with their cards hidden from both players. Neither player may look at the cards in any deck without being explicitly directed to do so by a rule or card ability.
- 4.2.3.linkDecks are ordered. The location of each card in a deck must be maintained except when a player is explicitly directed to manipulate the cards in a deck by a rule or card ability. See rule 4.1.7a.
- a.linkWhile searching a deck, a player is not required to maintain the order of the searched cards or indicate the previous location of any card found by the search. Note that the deck is always shuffled upon completion of the search, as required by rule 8.7.3.
- 4.2.4.linkThe number of cards in a deck is open information. Any player may count the number of cards in a deck at any time.
- 4.2.5.linkCards in a deck are inactive.
- 4.2.6.linkEach player's deck has its own name as a means of differentiating between the two.
- 4.2.7.linkR&D
R&D stands for Research and Development. It represents upcoming projects and acquisitions the Corp will soon have at their disposal.
- a.linkR&D is the name for the Corp's deck. It is also one of the Corp's central servers. See section 4.6.7.
- b.linkIf the Corp must ever draw from R&D while it is empty, the Runner wins the game. See section 1.7.
- 4.2.8.linkStack
The stack represents the Runner's untapped potential: future plans, connections, and opportunities they have yet to discover.
- a.linkThe stack is the name for the Runner's deck.
- 4.3.1.linkA player's hand is the zone in which they hold the cards they have drawn from their deck. Cards can be added to a player's hand by other rules and card abilities as well. During setup, each player draws a starting hand. See section 1.6.
- 4.3.2.linkA player's hand is kept secret from their opponent. A player may look at the cards in their own hand, but not at any of the cards in their opponent's hands.
- 4.3.3.linkHands are not ordered. A player may freely arrange the cards in their hand in any order at any time.
- 4.3.4.linkThe number of cards in a hand is open information to all players. Any player may count the number of cards in a hand at any time.
- 4.3.5.linkCards in a hand are inactive.
- 4.3.6.linkEach player has a maximum hand size, usually five. A player may have any number of cards in their hand at any given time, but during the discard phase of a player's turn they must discard cards from their hand until there are no more cards in their hand than their maximum hand size allows. See section 5.5.
- 4.3.7.linkEach player's hand has its own name as a means of differentiating between the two.
- 4.3.8.linkHQ
HQ stands for Headquarters. It represents the projects, staff, technology, and other assets the Corp is authorized to deploy.
- a.linkHQ is the name for the Corp's hand. It is also one of the Corp's central servers. See section 4.6.7.
- b.linkThe Corp's identity card represents their HQ server for the purposes of gameplay. Ice protecting HQ is installed in front of the Corp's identity card and upgrades installed in the root of HQ are installed behind the Corp's identity card.
- 4.3.9.linkGrip
The grip represents the Runner's currently accessible thoughts, plans, knowledge, potential social connections, and other intangible information that can be leveraged.
- a.linkThe grip is the name for the Runner's hand.
- b.linkSuffering damage forces the Runner to discard cards from their grip at random, and suffering core damage also reduces the Runner's maximum hand size. The Runner flatlines and loses the game if they suffer more damage than they have cards in grip or must discard down to a hand size lower than zero. See section 10.4.
- 4.4.1.linkA player's discard pile is the zone in which they place cards that have been trashed or discarded. Discard piles start the game empty.
- 4.4.2.linkDiscard piles are not ordered. A player may freely arrange the cards in their discard pile in any order at any time.
- 4.4.3.linkThe number of cards in a discard pile is open information. Any player may count the number of cards in a discard pile at any time.
- 4.4.4.linkCards in a discard pile are inactive.
- 4.4.5.linkEach player's discard pile has its own name as a means of differentiating between the two.
- 4.4.6.linkArchives
Archives represents the Corp's internal record database of all scrapped, abandoned, or discontinued projects, contracts, assignments, and other endeavors.
- a.linkArchives is the name for the Corp's discard pile. It is also one of the Corp's central servers. See section 4.6.7.
- b.linkCards in Archives can be either faceup or facedown. If a Corp card is visible to the Runner when it is trashed or discarded, it is put in Archives faceup. If a Corp card is not visible to the Runner when it is trashed or discarded, then it is put in Archives facedown. Facedown cards in Archives should be oriented horizontally so that the Runner can easily see they are present.
- c.linkThe faceup cards in Archives are open information. Any player may look through the faceup cards in Archives at any time. The facedown cards in Archives are visible only to the Corp. The Corp may look through the facedown cards in Archives at any time, but the Runner cannot look at them.
- 4.4.7.linkHeap
The heap represents what the Runner has lost: their old jobs, favours burned, friends long gone, gear wrecked, and code erased.
- a.linkThe heap is the name for the Runner's discard pile.
- b.linkThe cards in the heap are open information. Any player may look through the cards in the heap at any time.
The score areas represent major accomplishments for each player in service of their long-term ambitions. The Corp's score area contains all large-scale projects they have seen to completion. The Runner's score area is a memorial to all such initiatives they have successfully disrupted, exposed, or sold details of to the highest bidder.
- 4.5.1.linkA player's score area is the zone in which they place agendas they have scored or stolen. Section 1.17 details scoring and stealing agendas. Score areas start the game empty.
- 4.5.2.linkThe agendas in a score area are open information. A player may look through or count the agendas in a score area at any time.
- 4.5.3.linkScore areas are not ordered. A player may freely arrange the agendas in their score area in any order at any time.
- 4.5.4.linkAgendas in the Corp's score area are active. Agendas in the Runner's score area are inactive unless stated otherwise.
- 4.6.1.linkThe play area is the shared active zone into which cards are played or installed. The play area normally starts the game empty except for each of the player's identities.
- a.linksection 1.5 details cases where an ability may cause cards to start the game in the play area.
- 4.6.2.linkThe number of cards in the play area and the location of each card in the play area is always open information.
- 4.6.3.linkWhether or not a card itself and its attributes are open information while in the play area is determined by the card's status. Cards that are faceup are open information and can be examined by any player at any time. Cards that are facedown are secret information and can only be examined by the player who controls the card. See section 10.2.
- 4.6.4.linkWhether or not a card is active while in the play area is determined by the card's status.
- a.linkIdentities start the game in the play area and are always active.
- b.linkGenerally, Corp agendas, assets, ice, and upgrades are installed into the play area unrezzed and thus inactive. They are active while rezzed. See section 8.5.
- c.linkGenerally, Runner hardware, programs, and resources are installed into the play area faceup and active. See section 8.5.
- d.linkSome Runner cards are installed facedown or turned facedown through card abilities. This is distinct from the status of rezzed/unrezzed that Corp cards can have. Facedown Runner cards are not active. See section 8.1.4.
- e.linkOperations and events are played into the play area faceup and are active for the duration of their resolution before being trashed. See section 8.6.
- 4.6.5.linkSome objects in the play area are organized into specific orientations and/or locations.
- a.linkCorp cards are arranged into distinct servers. Agendas and assets are installed in the roots of remote servers, upgrades are installed in the roots of any servers, and pieces of ice are installed horizontally protecting servers. See section 4.6.6 and section 4.6.9.
- b.linkThe Corp's identity is used to indicate where in the play area HQ exists for the purposes of installing upgrades in the root of HQ and ice protecting HQ. See section 4.6.7.
- c.linkThe Runner's identity, hardware, programs, and resources do not have specific locations in the play area.
- d.linkThere is no specific location in the play area for operations or events. They are simply played into the play area, where they resolve before being trashed. See section 8.6.
- e.linkEach player has a credit pool, which is a location in the play area where credits they control are kept.
- f.linkCounters other than credits have no specific location in the play area. Tag counters are always controlled by the Runner, and bad publicity counters are always controlled by the Corp. Other types of counters are either nonfunctional gameplay aids or appear only in host relationships. See also section 1.9.
- g.linkSome cards can act as install locations for other cards while in the play area, such that cards of a specific type can be hosted directly onto them during the installation process. In this type of host relationship, both the host card and the hosted card are in the play area, but the host relationship can affect certain aspects of either the card or the installation process. See section 1.13.
- h.linkSome cards can host other cards without installing them. In this type of host relationship, both the host card and the hosted card are in the play area, but the hosted card is not installed and thus not active. See section 1.13.
- 4.6.6.linkServers
- a.linkA server is a set of locations where the Corp installs their cards into the play area and against which the Runner can initiate runs. Whenever a Corp installs an agenda, asset, ice, or upgrade, they must choose a destination server for that card. See section 8.5.
- b.linkOnce a Corp card is installed, it cannot be moved from its server without explicit direction from a game rule or card effect.
- c.linkThe two types of servers are central servers and remote servers. See sections 4.6.7 and 4.6.8, respectively.
- d.linkAll servers can have ice installed protecting them. See section 4.6.9.
- e.linkAll servers have a root where cards can be installed. A central server's root can contain any number of upgrades, while a remote server's root can contain 1 asset or agenda and any number of upgrades. Assets and agendas cannot be installed in the root of a central server.
- f.linkAll cards installed in the root of a server are kept in the same orientation and location together. The order in which the cards are installed is open information, but the type of cards installed in the root of a remote server should not be derivable from their orientation or location.
- g.linkOnly 1 region upgrade can be installed in the root of a server at a time. See section 3.6.5.
- h.linkSome upgrades have restrictions limiting them to specific servers. See rule 8.5.12.
- i.linkSome cards refer to the server where they are located (or the central server corresponding to the zone where they are located) using the phrase "this server". If an ability is initiated by a trigger condition or cost involving the ability's source card moving from a server, its root, or protecting it to another server or to a location not associated with any server, treat "this server" as referring to the server associated with the previous location of the card throughout resolution of that ability. If an ability moves its source card while it is resolving, continue to interpret "this server" based on the card's previous location.
- Example: The Runner trashes a rezzed Warroid Tracker. This meets the trigger condition of Warroid Tracker's ability, but by the time a checkpoint is resolved and an instance of the ability would become pending, Warroid Tracker itself is no longer installed. The use of "this server" in the trigger condition still refers to the server from which Warroid Tracker was trashed, not to the server of Warroid Tracker's new location in Archives.
- Example: The Corp uses the ability granted by ZATO City Grid to trash Border Control and resolve its first subroutine. The phrase "this server" in that subroutine refers to the server from which the Border Control was trashed. However, Border Control is no longer protecting that server, so it is not included in the number of ice counted.
- Example: The Corp uses Nanisivik Grid to turn a facedown Border Control in Archives faceup and resolve its first subroutine. Border Control was not moved between servers, so "this server" in that subroutine refers to Archives.
- j.linkIf an ability on a card currently or previously located in a server, its root, or protecting it refers to "another server", this means any server except "this server" as interpreted by rule 4.6.6i. If a card's abilities involve choosing a server, "another server" in a linked ability means any server except the chosen server. If neither of the previous cases apply and a run is in progress, "another server" means any server except the attacked server.
- k.linkIf an ability on an object uses the phrase "this server", and that object is hosted on another object (see section 1.13), the server referred to is the server of the host object.
- 4.6.7.linkCentral Servers
- a.linkThe Corp has three central servers at all times. Each central server corresponds to one of the Corp's zones: HQ corresponds to the Corp's hand, R&D corresponds to the Corp's deck, and Archives corresponds to the Corp's discard pile.
- b.linkThe Corp's identity is in the play area to indicate the location of HQ relative to other servers, but it is not in HQ, in the root of HQ, or protecting HQ. The cards in HQ are held in the Corp's hand. The upgrades installed in the root of HQ are placed in a vertical orientation near the Corp's identity. The ice installed protecting HQ are placed in a horizontal orientation in front of the Corp's identity outwards towards the Runner.
- c.linkThe Corp's deck is placed in the play area to indicate the location of R&D relative to other servers, but the cards in the deck are not installed. The cards in R&D are the cards in the deck. The upgrades installed in the root of R&D are placed in a vertical orientation near the deck. The ice installed protecting R&D are placed in a horizontal orientation in front of the deck outwards towards the Runner.
- d.linkThe Corp's discard pile is placed in the play area to indicate the location of Archives relative to other servers, but the cards in the discard pile are not installed. The cards in Archives are the cards in the discard pile. The upgrades installed in the root of Archives are placed in a vertical orientation near the discard pile. The ice installed protecting Archives are placed in a horizontal orientation in front of the discard pile outwards towards the Runner.
- 4.6.8.linkRemote Servers
- a.linkA remote server is the only type of server that can contain an asset or agenda in its root.
- b.linkThe Corp starts the game with no remote servers. The Corp creates a new remote server by declaring it as the destination server for a card they are about to install. There is usually no limit to the number of remote servers the Corp can have at any given time.
- c.linkCards installed in the roots of separate remote servers are placed in a vertical orientation in a row extending away from the central servers to indicate the locations of the remote servers relative to other servers. The ice installed protecting each remote server are placed in a horizontal orientation in front of any cards in the root of that server, outwards towards the Runner.
- d.linkA remote server exists as long as there is at least one card in the root of or protecting it. A remote server can be made up of only ice protecting it, only cards installed in it, or a combination of both.
- e.linkDuring checkpoints, a remote server ceases to exist if there are no cards installed in its root and no cards installed protecting it. If a server ceases to exist during a run against it, then the run ends after any currently open paid ability window closes. Unless the run has already been declared either successful or unsuccessful, it is neither. See rule 8.5.8.
- f.linkSome abilities limit the number of remote servers. While such an ability is active, the Corp cannot create a new remote server if this would raise the total number of remote servers above the specified limit. During step 10.3.1e of each checkpoint, if there are more remote servers than an active limit allows, the Corp player chooses a number of servers equal to the limit. The checkpoint then trashes all cards in the root of and protecting each remote server that was not chosen.
- Example: The Corp's identity is Earth Station: SEA Headquarters, which has the ability "Limit 1 remote server." If any remote servers exist, the Corp cannot create a new remote server.
- 4.6.9.linkProtecting a Server
- a.linkAn installed piece of ice is arranged in a horizontal position in front of the server it is protecting. Ice are ordered within the play area. The location of a piece of ice is defined by the server it is protecting and the number of other pieces of ice between it and the server.
- b.linkIf there is no other ice between the server and a piece of ice, that ice is the innermost piece of ice. If there is no ice farther from the server than a piece of ice, that ice is the outermost piece of ice. If there is only one piece of ice protecting a server, that ice is both the innermost and the outermost piece of ice.
- c.linkIf two pieces of ice protecting two different servers share the same number of ice between them and their respective servers, those pieces of ice are considered to be in the same position.
- d.linkWhen the Corp installs a piece of ice protecting a server, they must place it in the outermost position protecting that server. See section 8.5.
- e.linkIf the number of other ice between a piece of ice and the server changes, its position will change accordingly, moving either closer or farther from the server. If this occurs while that ice is being approached, encountered, or passed during a run, the Runner's position attacking the server changes in the same way.
- 4.7.1.linkThe bank is an inactive zone shared by both players. It holds an unlimited supply of counters for use during gameplay.
- 4.7.2.linkCounters placed or loaded onto a card are taken from the bank unless otherwise specified. Counters gained by players are taken from the bank unless otherwise specified.
- 4.7.3.linkCredits and other counters that are spent to pay costs return to the bank.
- 4.7.4.linkCounters that are not in a legal location return to the bank during checkpoints. See section 10.3.
- 4.7.5.linkCards are never located in the bank.
- 4.8.1.linkThe set-aside zone is an inactive zone shared by both players. It is used as a temporary holding space for objects being affected by abilities.
- 4.8.2.linkIf an object is "set aside", it is moved from its current zone to the set-aside zone.
- 4.8.3.linkAn ability cannot see the set-aside zone unless it specifically sets objects aside or refers to set-aside objects. Outside of these cases, cards moved into another zone from the set-aside zone are treated as though they entered that zone directly from their location prior to being set aside.
- Example: The Runner is playing as Exile and plays Test Run, searching their heap for a program. Although the program is set aside before being installed, Exile's ability treats it as though it were installed directly from the heap, and so Exile will draw a card.
- 4.8.4.linkCards found during a search are set aside facedown while the search completes (in particular, while any deck that was searched is shuffled). See section 8.7.
- 4.8.5.linkSome paid abilities with a trigger cost that uninstalls or forfeits the ability's source card need to refer to or act on that card's hosted cards or counters. These abilities set aside the hosted cards or counters as the trigger cost is paid. See rule 9.5.5.
- 4.8.6.linkCards set aside by a card ability are faceup unless the ability specifically instructs that they be set aside facedown.
- 4.8.7.linkFacedown cards in the set-aside zone must be kept in distinct groups according to the effect that sets them aside. Cards within such a group are not ordered and can be freely arranged by their controller.
- Example: The Runner accesses the top card of R&D and does not steal or trash it. On the next turn, the Corp uses Daily Business Show to draw that card and 1 other card simultaneously, but must put 1 of the drawn cards on the bottom of R&D. While resolving the draw, the cards are set aside facedown, so the Corp can shuffle them. They do not have to tell the Runner whether the previously-accessed card ends up in HQ or on the bottom of R&D.
- 4.9.1.linkThe removed-from-game zone is an inactive zone shared by both players. It is used to take cards out of any player's control until the end of the game.
- 4.9.2.linkIf a card is removed from the game, it is moved from its current zone to the removed-from-game zone.
- 4.9.3.linkForfeiting an agenda removes it from the game. See rule 8.2.5.
- 4.9.4.linkCards that have been removed from the game are inactive.
- 4.9.5.linkA card that has been removed from the game cannot move out of the removed-from-game zone or otherwise be interacted with.
- 4.9.6.linkCards that have been removed from the game are open information. Any player may look through or count the cards that have been removed from the game at any time.
- 5.1.1.linkA turn is a duration of time during which a player may take actions and is the first to receive priority to act during priority windows.
- 5.1.2.linkThe Corp's turn consists of three phases. During the draw phase, the Corp draws the top card of R&D into HQ; during the action phase, the Corp spends [click]s to perform actions; during the discard phase, the Corp discards until the number of cards in HQ does not exceed their maximum hand size. Once the Corp's turn ends, the Runner's turn begins.
- 5.1.3.linkThe Runner's turn consists of two phases. During the action phase, the Runner spends [click]s to perform actions; during the discard phase, the Runner discards until the number of cards in their grip does not exceed their maximum hand size. Once the Runner's turn ends, the Corp's turn begins.
- 5.1.4.linkThe beginning and end of each player's turn are formalized as particular steps of the turn timing structures.
- a.linkTrigger conditions related to a turn beginning are not met as the turn timing structure opens. They are met at the timing step that indicates the formal beginning of the turn.
- b.linkTrigger conditions related to a turn or discard phase ending are met at the timing step that indicates the formal end of the turn. They are not met when the turn timing structure later closes. The end of the turn and the end of the discard phase are the same.
- c.linkSome effects can occur before the "turn begins" step or after the "turn ends" step of a turn. The player whose turn timing structure is in progress is still the active player, and effects that apply during their turn are still applicable, even though their turn has not yet formally begun or has already formally ended.
- d.linkOnce the game begins, it is always one or the other player's turn. There is no time "between turns".
- 5.2.1.linkAn action is any paid ability where the cost begins with a [click] symbol.
- a.linkOther costs can contain [click] symbols without denoting an action.
- Example: The ability "[click]: Gain 1[c] and draw 1 card." on Professional Contacts is an action. The ability "Lose [click]: Break 1 subroutine on this ice. Only the Runner can use this ability." on Eli 1.0 is not an action and is used during a paid ability window.
- 5.2.2.linkA player initiates an action by paying its cost in [click], as well as any other costs associated with that action, during their action window.
- a.linkOnce an action is initiated, it must be completed before the game can advance to the next step or open another action window. If the effects of an action initiate a timing structure, such as a run, players may use paid abilities, rez cards, and score agendas as dictated by the priority windows of that nested timing structure, but otherwise players cannot perform any of those voluntary effects while the action is resolving. See section 9.2 for more details about priority.
- b.linkIf a timing structure is initiated during the resolution of an action, that action is not complete until the new timing structure is complete and any further effects of the initiated action following the completion of the new timing structure are resolved.
- Example: The Runner takes the action "play an event", playing Stimhack. The action is not complete until the run initiated by Stimhack ends, the Runner suffers core damage, and Stimhack is trashed following its resolution.
- c.linkA conditional ability that meets its trigger condition due to a player taking an action resolves after the action's trigger cost is paid, before the effects of the action itself. See rule 9.1.2a.
- d.linkSome conditional abilities meet their trigger conditions due to an action "ending", "finishing", or "completing". These abilities resolve in the reaction window following step 5.6.2b or step 5.7.1f, for actions taken by the Corp and Runner, respectively.
- 5.2.3.linkEach player has several basic actions they can always perform. The Corp's basic actions are listed in section 5.2.7, and the Runner's basic actions are listed in section 5.2.8.
- a.linkIf an ability has a trigger condition related to an effect being performed “with the basic action”, that trigger condition is met by any basic action that performs the indicated effect. If an ability imposes a cost on performing an effect “with the basic action”, that cost applies to any instance of the indicated effect that would occur as part of resolving a basic action.
- 5.2.4.linkA player can only take an action if its effect has the potential to change the game state. See rule 1.2.5.
- 5.2.5.linkA player can only take actions during the action phase of their turn. If an effect directs a player to take an action outside of that player's action phase, instead that player does nothing.
- 5.2.6.linkSome cards refer to players taking "the same action" or "different actions".
- a.linkActions a player performs are the same if they are all the same basic action or if all of those actions were initiated by the same ability from the same card.
- b.linkActions a player performs are different if each of them is initiated from a different basic action or card ability. Instances of equivalent abilities on different cards are still different actions.
- Example: The Corp, playing MirrorMorph: Endless Iteration, plays Hedge Fund as the first action of their turn, then plays Lateral Growth. Even though two different cards were played, both times the Corp used the basic action to "Play 1 operation from HQ". Since their first two actions were the same, the Corp will not be able to trigger the ability on MirrorMorph this turn.
- 5.2.7.linkCorp Actions
- a.linkThe following basic actions are always available to the Corp during their action phase, in addition to any actions provided by card abilities.
- b.link"[click]: Gain 1[c]."
- c.link"[click]: Draw 1 card."
- d.link"[click]: Install 1 agenda, asset, upgrade, or piece of ice from HQ." See section 8.5.
- e.link"[click]: Play 1 operation from HQ." See section 8.6.
- f.link"[click], 1[c]: Advance 1 installed card." See section 1.18.
- g.link"[click], 2[c]: Trash 1 resource. Take this action only if the Runner is tagged." See section 10.5.
- h.link"[click][click][click]: Purge virus counters." See section 10.1.2.
- 5.2.8.linkRunner Actions
- a.linkThe following basic actions are always available to the Runner during their action phase, in addition to any actions provided by card abilities.
- b.link"[click]: Gain 1[c]."
- c.link"[click]: Draw 1 card."
- d.link"[click]: Install 1 program, resource, or piece of hardware from the grip." See section 8.5.
- e.link"[click]: Play 1 event from the grip." See section 8.6.
- f.link"[click]: Run any server." See section 6.
- g.link"[click], 2[c]: Remove 1 tag." See section 10.5.
- 5.3.1.linkThe draw phase is the first phase of the Corp's turn. It includes the formal beginning of the Corp's turn and the Corp's mandatory draw.
- 5.3.2.linkThe mandatory draw is a card draw performed by the Corp. It is not an action and does not cost [click].
- 5.3.3.linkThe Runner's turn does not have a draw phase.
- 5.4.1.linkThe action phase is the first phase of the Runner's turn and the second phase of the Corp's turn. It is the only timing structure in which players can take actions, as discussed in section 5.2.
- 5.4.2.linkDuring a player's action phase, they must continue to take actions until they have no more clicks or the phase is ended directly by a card ability. The player may take actions in any combination and order as long as they pay the appropriate costs. Once they have no remaining clicks, the action phase ends.
- 5.4.3.linkA player's action phase can be forced to end by certain card abilities (e.g. via the ability on a terminal operation or event). When a player's action phase is forced to end, the following occurs:
- a.linkThe current step of the action phase ends, and all remaining steps are skipped.
- b.linkAny currently open priority windows close, their associated abilities lose their pending status, and the player with priority loses priority.
- c.linkAny currently resolving actions or abilities cease resolving and are considered complete.
- d.linkA checkpoint occurs, following which the game proceeds to the active player's discard phase.
- 5.5.1.linkThe discard phase is the last phase of each player's turn. It requires the active player to discard cards until their maximum hand size is satisfied and includes the formal end of that player's turn.
- 5.5.2.link discarding is the act by which a player moves a card to their discard pile during their discard phase if they have exceeded their maximum hand size.
- a.linkCards discarded from HQ are always sent to Archives facedown, regardless of whether they have been previously accessed by the Runner.
- b.linkA discarded card is not considered to have been trashed, and vice versa.
- 5.5.3.linkA player's maximum hand size is the maximum number of cards that player can keep in their hand during their discard phase.
- a.linkPlayers begin the game with a maximum hand size of five cards.
- b.linkEach point of core damage the Runner suffers permanently reduces their maximum hand size by 1 card. See section 10.4. Other abilities can modify a player's maximum hand size directly.
- 5.5.4.linkIf an effect instructs a player to "skip your discard step", that player does not resolve the appropriate step of their turn (step 5.6.3a for the Corp, and step 5.7.2a for the Runner). They will not check their hand size or discard cards.
- 5.6.1.linkDuring the draw phase, the following steps occur in order:
- a.linkThe Corp gains their allotted clicks (default [click][click][click]).
- b.linkA paid ability window occurs, in which players may use paid abilities, the Corp may rez non-ice cards, and the Corp may score agendas. (P) (R) (S)
- c.linkThe Corp's recurring credits ([recurring]) refill.
- d.linkThe Corp's turn formally begins. Conditions related to the turn beginning are met.
- e.linkThe Corp performs their mandatory draw.
- f.linkThe Corp's draw phase is complete. Play proceeds to the Corp's action phase.
- 5.6.2.linkDuring the Corp's action phase, the following steps occur in order:
- a.linkA paid ability window occurs, in which players may use paid abilities, the Corp may rez non-ice cards, and the Corp may score agendas. (P) (R) (S)
- b.linkIf the Corp has any unspent [click], the Corp takes an action. Otherwise, skip to (d).
- c.linkReturn to (a).
- d.linkThe Corp's action phase is complete. Play proceeds to the Corp's discard phase.
- 5.6.3.linkDuring the Corp's discard phase, the following steps occur in order:
- a.linkThe Corp discards one card at a time from HQ until the number of cards in HQ is less than or equal to the Corp's maximum hand size.
- b.linkA paid ability window occurs, in which players may use paid abilities and the Corp may rez non-ice cards. (P) (R)
- c.linkIf the Corp has any unspent [click], the Corp loses those [click].
- d.linkThe Corp's turn formally ends. Conditions related to the turn or discard phase ending are met.
- e.linkThe Corp's discard phase and turn are complete. Play proceeds to the Runner's turn.
- 5.7.1.linkDuring the Runner's action phase, the following steps occur in order:
- a.linkThe Runner gains allotted clicks (default [click][click][click][click]).
- b.linkA paid ability window occurs, in which players may use paid abilities and the Corp may rez non-ice cards. (P) (R)
- c.linkThe Runner's recurring credits ([recurring]) refill.
- d.linkThe Runner's turn formally begins. Conditions related to the turn beginning are met.
- e.linkA paid ability window occurs, in which players may use paid abilities and the Corp may rez non-ice cards. (P) (R)
- f.linkIf the Runner has any unspent [click], the Runner takes an action. Otherwise, skip to (h).
- g.linkReturn to (e).
- h.linkThe Runner's action phase is complete. Play proceeds to the Runner's discard phase.
- 5.7.2.linkDuring the Runner's discard phase, the following steps occur in order:
- a.linkThe Runner discards one card at a time from the grip until the number of cards in the grip is less than or equal to the Runner's maximum hand size.
- b.linkA paid ability window occurs, in which players may use paid abilities and the Corp may rez non-ice cards. (P) (R)
- c.linkIf the Runner has any unspent [click], the Runner loses those [click].
- d.linkThe Runner's turn formally ends. Conditions related to the turn or discard phase ending are met.
- e.linkThe Runner's discard phase and turn are complete. Play proceeds to the Corp's turn.
- 6.1.1.linkA run is a Runner's attack on a server. There are 6 phases used in the procedure of carrying out a run, described in sections 6.3 through 6.8. A run always begins with the Initiation Phase. Section 6.9 contains the full set of steps carried out during each phase, and should be referred to in conjunction with the sections discussing the phases.
- 6.1.2.linkThe attacked server is the server the Runner is attempting to reach, usually to breach that server.
- a.linkThe Runner announces the attacked server in the initiation phase of the run.
- b.linkCard abilities can sometimes change the attacked server during the run. This does not end the run, but it can affect whether or not certain card abilities or effects apply.
- c.linkIf an ability changes the Runner's position, the attacked server and the current timing step of the run could also change. See section 6.2.5.
- d.linkA few abilities change the attacked server directly, without referring to the Runner's position. These abilities do not change the current timing step of the run.
- Example: Sneakdoor Beta's ability changes the attacked server from Archives to HQ. The Runner does not need to encounter ice protecting HQ after resolving this ability.
- 6.1.3.linkMany abilities modify the sequence of steps taken to resolve a run. Such abilities can direct players to skip steps or phases, replace steps with other effects, move directly from the current timing point to a new phase, or make other changes to the procedures explained in this section. Heed the Golden Rules in section 1.2.
- a.linkSome abilities direct the Runner to approach or encounter a piece of ice as part of moving them to that ice's position. See section 6.2.5.
- b.linkOne card, Code Replicator, directs the Runner to approach the piece of ice in their position without first moving them to a new position. This effect changes the current timing step of the run to step 6.9.2, the Approach Ice Phase.
- c.linkAn ability that directs the Runner to encounter a piece of ice without first moving the Runner's position does not change the current timing point of the run, the attacked server, or the Runner's position. The effect of such an ability is to resolve an Encounter Ice Phase independent of the current state of the run. See section 6.5.9.
- d.linkAny time the current timing step of the run is moved to a different phase of the run, except for an instruction to end the run (See rule 6.1.4, below), no more steps in the previously-active phase are carried out. If a paid ability window is open, players complete that window normally. Then the active phase is complete and a checkpoint occurs. Finally, the game proceeds to the new phase.
- e.linkIf a condition refers to encountering a piece of ice "after" an approach or passing a piece of ice "after" an encounter, then that condition is only met by the indicated phases or steps occurring in direct sequence according to the standard progression of the run.
- Example: The Runner uses Inversificator to break the subroutine on a Miraju that is protecting Archives. When the encounter ends, Miraju's ability creates a replacement effect so that the Runner moves to the outermost position of Archives instead of passing Miraju. Because the ice is not passed, Inversificator's ability does not meet its trigger condition. Later, the Runner encounters the same Miraju again and does not break its subroutine. When this encounter ends, the Runner passes Miraju. Even though the Runner has used Inversificator to fully break Miraju during an encounter earlier in the run, Inversificator's trigger condition is not met when the Runner passes Miraju because the Runner is not passing it after the relevant encounter.
- 6.1.4.linkTo end the run is to halt the Runner's progress toward the server. When an effect ends the run, the current phase of the run ends without following any of its remaining steps, and before completing open priority windows. The game immediately moves from the current timing point to step 6.9.6, the Run Ends Phase.
- 6.1.5.linkJacking out is the process by which a Runner voluntarily ends a run. Jacking out follows the usual process for ending the run as described in rule 6.1.4, but some card abilities function differently depending on whether or not the Runner chose to end the run by jacking out.
- a.linkThe Runner has the opportunity to jack out after passing a piece of ice.
- b.linkIf there is no ice protecting the server, the Runner has the opportunity to jack out before approaching the server.
- 6.2.1.linkThe Runner's position during a run is a measure of their distance from the server. The Runner's possible positions correspond to the positions of ice protecting the attacked server.
- a.linkThe Runner does not have a position while they are not engaged in a run, nor do they maintain their position from one run to the next. After a run initiates, the Runner moves to the outermost position of the attacked server, if it has any.
- 6.2.2.linkThe Runner progresses through the positions protecting a server (and corresponding ice) in order. They approach, encounter (if the ice is rezzed), and pass each piece of ice, then proceed to the next piece of ice moving inward, until they pass the innermost piece of ice or the run is ended.
- a.linkOnce the Runner leaves the position of the innermost piece of ice protecting a server, they no longer have a position. This occurs at step 6.9.4d of the Movement Phase. However, abilities can still move the Runner to a position later in that phase.
- b.linkDuring the Success Phase and the Run Ends Phase, the Runner has no position and can no longer move to a position.
- Example: The Corp uses Ganked! to force the Runner to encounter Cell Portal in the middle of breaching a server. Since the run is already successful, resolving Cell Portal's subroutine will have no meaningful effect except to derez Cell Portal.
- 6.2.3.linkIce entering or leaving a position protecting the attacked server can affect the Runner's position.
- a.linkIf a piece of ice is added to or removed from the attacked server in a position outward from the Runner's current position, nothing happens. The Runner will normally not need to approach or encounter the new piece of ice to reach the server.
- Example: During a run on R&D, Architect's subroutines resolve and the Corp installs a new piece of ice in the outermost position protecting this server. The Runner does not approach that new piece of ice during this run because they have already passed that position.
- b.linkIf a piece of ice is added to the attacked server in a position inward from the Runner's current position, the Runner and each piece of ice outside of the new ice's position shift one space outward.
- Example: During a run on a remote server, Howler's subroutine resolves, and the Corp installs a new piece of ice in the next inward position protecting the server. The Runner will have to approach that new piece of ice later in this run because they have not passed that position.
- c.linkIf a piece of ice inward from the Runner's position is uninstalled or moved to another server, the Runner and each piece of ice outside of the departed ice's position shift one space inward. The Runner does not re-approach ice they have already passed.
- 6.2.4.linkChanges to the piece of ice in the Runner's current position can affect the progression of the run, but they do so differently during the Approach Ice Phase than during the Encounter Ice Phase.
- a.linkIf a piece of ice is uninstalled or moved to another position (protecting this or another server) while it is being approached, the run moves to the Movement Phase, all outward ice moves one position inward, and the run continues. The Runner does not re-approach ice they have already passed.
- Example: The Runner has passed 1 piece of ice and is approaching the innermost piece of ice, which is a rezzed Himitsu-Bako. During the paid ability window of the approach, the Corp uses the ability on Himitsu-Bako to add it to HQ. The Runner passes this position and will approach the server next, while the other piece of ice protecting the server moves to the innermost position.
- b.linkIf a piece of ice is uninstalled or derezzed while it is being encountered, the run moves to the Movement Phase. All outward ice moves one position inward if the ice was uninstalled, and the run continues. The Runner does not re-approach ice they have already passed.
- c.linkIf a piece of ice currently being encountered moves to another position or is swapped with installed ice in another position, the Runner remains with the encountered ice and continues the run from that ice's new position.
- Example: The Runner encounters Bullfrog as the innermost piece of ice protecting a remote server. Bullfrog's subroutine resolves and it is moved to be the outermost piece of ice protecting Archives. The Runner is now running on Archives and continues the run from Bullfrog's new position.
- d.linkIf a piece of ice currently being approached is swapped with ice in another position, the Runner remains in their current position and is now approaching the new piece of ice occupying that position.
- e.linkIf a piece of ice is uninstalled, derezzed, moved, or swapped after it is passed, the Runner is not moved.
- 6.2.5.linkDuring a run, abilities can move the Runner directly to a position.
- a.linkIf an ability instructs the Runner to move to a piece of ice in a different position, the Runner's position becomes the position corresponding to that ice, and the server that ice protects becomes the attacked server. The current timing step becomes step 6.9.2, the Approach Ice Phase, or step 6.9.3, the Encounter Ice Phase, according to whether the Runner was directed to approach or encounter the ice.
- b.linkIf an ability instructs the Runner to move to "the outermost position" of a server, that server becomes the attacked server. If there is any ice protecting that server, the Runner's position becomes the position of the outermost such piece of ice, and the current timing step becomes step 6.9.2, the Approach Ice Phase. If there is no ice, the Runner ceases to have a position, and the current timing step becomes step 6.9.4, the Movement Phase.
- c.linkIf an ability instructs the Runner to move to a position during the Success Phase, during the Run Ends Phase, or while there is no run in progress, instead the Runner does nothing. See rule 6.2.2b.
- d.linkIf an ability instructs the Runner to move to and approach a position they are already approaching, instead the Runner does nothing.
- 6.3.1.linkThe initiation phase sets the parameters for the run and begins the run.
- 6.3.2.linkAt the start of the Initiation Phase, the Runner announces a server to be the attacked server.
- a.linkSome abilities state that the Runner "cannot run on" or "cannot initiate a run on" certain servers under certain conditions. These effects refer to the announcement of the attacked server in the Initiation Phase.
- Example: Off the Grid states in part, "The Runner cannot initiate a run on this server." This only prohibits the Runner from announcing this particular remote server as the attacked server at the beginning of the run. If an ability changes the attacked server while a run is in progress, Off the Grid does not interfere with that ability.
- b.linkSome abilities impose an additional cost to run, either generally or on a particular server. Any costs to run a server must be paid at the time that server is announced as the attacked server.
- 6.3.3.linkAfter the attacked server is announced, the Runner receives credits equal to the number of bad publicity the Corp has. See section 10.6 for an explanation of bad publicity.
- a.linkCredits from bad publicity cannot be spent to pay costs to make the run, as they are received after the attacked server is announced.
- b.linkOnce they are received, credits from bad publicity are in the Runner's credit pool and behave just as any other credits. They can be spent, lost, placed on cards, and so on as normally allowed.
- c.linkDuring the Run Ends Phase, any credits from bad publicity remaining in the Runner's credit pool are lost.
- 6.3.4.linkSome abilities look for particular conditions occurring "during a run" or are restricted to being used "during a run." For purposes of abilities, the run formally begins only after the attacked server is announced and any costs are paid.
- Example: The Runner initiates a run against a server with a rezzed Heinlein Grid while the Corp has Enhanced Login Protocol in play. They do not lose any credits to Heinlein Grid's ability, as the additional click Enhanced Login Protocol requires them to spend is spent to initiate the run, and is not spent during the run.
- 6.3.5.linkWhen the Initiation Phase completes, the run moves either to the Approach Ice Phase (section 6.4) or the Movement Phase (section 6.6). If there is ice protecting the attacked server, the Runner's position becomes the outermost piece of ice, and the run proceeds to the Approach Ice Phase. If there is no ice protecting the server, then the run moves directly to the Movement Phase.
- 6.4.1.linkThe approach ice phase gives the Corp the opportunity to rez the ice in the Runner's current position.
- 6.4.2.linkFor purposes of meeting trigger conditions, the Runner approaching a piece of ice is equivalent to the Approach Ice Phase beginning at that ice's position. Abilities with this trigger condition are subject to rule 9.2.8f.
- 6.4.3.linkThe paid ability window in step 6.9.2b of the Approach Ice Phase is the only time the Corp can normally rez ice. In this window, the Corp only gains the ability to rez the piece of ice being approached, not any other ice.
- 6.4.4.linkWhen the Approach Ice Phase completes, the run moves either to the Encounter Ice Phase (section 6.5) or the Movement Phase (section 6.6). If the approached piece of ice is rezzed, the Runner encounters it next. If the approached piece of ice is unrezzed or if there is no longer ice installed in that position, then the run moves directly to the Movement Phase.
- 6.5.1.linkThe encounter ice phase gives the Runner the opportunity to interact with the ice in their current position, then requires the Corp to resolve unbroken subroutines on that ice.
- 6.5.2.linkFor purposes of meeting trigger conditions, the Runner encountering a piece of ice is equivalent to the Encounter Ice Phase beginning at that ice's position. Abilities with this trigger condition are subject to rule 9.2.8f.
- 6.5.3.linkAs each encounter begins, each subroutine on the encountered ice gains an "unbroken" status associated with that encounter. See section 9.8 for details.
- 6.5.4.linkDuring the paid ability window in the Encounter Ice Phase (step 6.9.3b), the Runner can break subroutines on the ice. See rule 9.8.6.
- 6.5.5.linkAfter the paid ability window in the Encounter Ice Phase closes, unbroken subroutines on the encountered ice resolve. See section 9.8.8.
- 6.5.6.linkAt the end of the Encounter Ice Phase, the run continues to the Movement Phase, section 6.6.
- 6.5.7.linkFully Break
- a.linkDuring each encounter, the Runner fully breaks the encountered ice the first time all subroutines on that ice are broken.
- b.linkWhenever the Runner fully breaks a piece of ice, if all its subroutines were broken using abilities on a single object, that object also fully breaks the ice.
- c.linkIf an encountered piece of ice has no subroutines, the Runner fully breaks it when step 6.9.3b of the encounter begins. No objects fully break the ice in this case.
- d.linkIf the encountered piece of ice gains subroutines after the Runner fully breaks it, the Runner's status of having fully broken the ice remains in place. Conditions that check whether the Runner fully broke the ice will still be met as normal. Breaking the new subroutines will not fully break the ice or meet related conditions again.
- 6.5.8.linkBypass
- a.linkWhen an effect allows the Runner to bypass a piece of ice, the Encounter Ice Phase is aborted and the Runner immediately proceeds to pass that ice.
- b.linkMost bypass effects occur at the beginning of an encounter and result in steps 6.9.3b and 6.9.3c never occurring, meaning that subroutines on the encountered ice are neither broken nor resolved.
- c.linkA few bypass effects can be triggered later. If ice is bypassed in step 6.9.3b, subroutines may or may not have been broken, but step 6.9.3c never occurs so no subroutines resolve. Note that for ice with zero subroutines, the Runner has "broken all subroutines" if and only if step 6.9.3b was reached. See rule 9.12.2d.
- Example: The Runner plays Forked and encounters a Troll that they can bypass with Femme Fatale. The Runner pays 0[c] to bypass the Troll with Femme Fatale. Forked does not meet its trigger condition, and Troll is not trashed, because the opportunity to break subroutines was never reached.
- 6.5.9.linkForced Encounters
- a.linkIf an ability directs the Runner to encounter a piece of ice without first changing their position, resolve an Encounter Ice Phase but do not change the Runner's position, if any. After the encounter, return to the effect that caused the encounter and proceed from there. This type of encounter outside the normal progression of a run is referred to as a forced encounter.
- Example: If Shiro causes Chrysalis to be accessed, resolve the encounter with Chrysalis and then return to resolving subroutines on Shiro.
- b.linkIf a forced encounter occurs during a run, an instruction to end the run during that encounter is applied to both the Encounter Ice Phase being resolved and the phase from which the additional encounter was initiated. If a forced encounter occurs outside of a run, an instruction to end the run simply closes the Encounter Ice Phase and returns the game to the effect that called for the encounter.
- Example: The Corp uses The Twins to force the Runner to encounter a piece of ice again when they pass it. If a subroutine directs the Corp to end the run during the extra encounter, both that encounter and the original Movement Phase are aborted, and the game proceeds to the Run Ends phase.
- c.linkAn instruction that creates a forced encounter is not finished resolving until the encounter is complete.
- d.linkDuring a forced encounter, if an ability moves the Runner or directs the Runner to approach a piece of ice, that movement resolves and changes the parameters of the underlying run normally, but does not end or interfere with the forced encounter.
- 6.6.1.linkThe movement phase handles the progression of the run between pieces of ice and after the innermost piece of ice, up to the point when the Runner approaches the attacked server.
- 6.6.2.linkIf the Movement Phase was reached from the Approach Ice Phase or the Encounter Ice Phase, the Runner passes the ice in their position.
- 6.6.3.linkDuring each Movement Phase, the Runner has the opportunity to jack out. See section 6.1.5.
- 6.6.4.linkIf the Runner declines to jack out, their position moves to the next inward position if there is one.
- 6.6.5.linkIf the Runner moves to a new position, the run continues from the Movement Phase to the Approach Ice Phase, section 6.4. The Runner will approach the piece of ice in their new position.
- 6.6.6.linkIf the Runner does not jack out or return to the Approach Ice Phase, they approach the server. This has no inherent effects, but is referred to by some card abilities. After the Runner approaches the server, the run continues to the Success Phase, section 6.7.
- 6.7.1.linkThe success phase declares the run successful and allows the Runner to breach the attacked server.
- 6.7.2.linkA run during which the runner breaks through the Corp's defenses and reaches the server itself is declared a successful run. This label is frequently referred to by card abilities.
- 6.7.3.linkDeclaring a run to be successful is not the same as the Success Phase beginning. Accordingly, abilities that have trigger conditions related to a successful run are not subject to rule 9.2.8f.
- 6.7.4.linkMany abilities that initiate a run contain a conditional ability with the trigger condition "If successful". This means, "After the run created this way becomes successful".
- a.linkIf an effect that initiates a run specifies that that run must be made against a specific server or servers, any "If successful" abilities associated with that effect are tied to that server or servers. If the attacked server has changed since the run was initiated, and no longer is a server that could have been chosen for this run, the "If successful" abilities do not meet their trigger conditions.
- Example: The Runner plays Because I Can, which directs them to make a run on a remote server. If an effect moves the run to a central server, the "If successful" effect on Because I Can will not apply. However, if the run is moved instead to another remote server, the "If successful" effect is still applied, since Because I Can would have allowed a run on the second remote server to begin with.
- b.link"If successful" abilities frequently create lingering effects (see section 9.10) that modify the procedure for accessing cards or replace breaching the attacked server with another effect entirely. These effects apply to the breach permitted by the rules for this run (see rule 6.7.5), and they expire when the run is complete.
- c.linkIf an "If successful" effect gives the Runner an effect they can optionally carry out instead of breaching, that decision is made at the time the breach would begin, in step 6.9.5b.
- Example: The Runner plays Account Siphon while Ash 2X3ZB9CY is installed in the root of HQ, and the run is successful. The Runner can wait until after the trace from Ash 2X3ZB9CY completes before deciding to access cards normally or force the Corp to lose credits.
- 6.7.5.linkWhen the Runner breaches the server, they follow the procedures detailed in section 7.
- 6.8.1.linkThe run ends phase formalizes the end of the run and prepares the game to return to the timing structure from which the run was initiated.
- 6.8.2.linkAt the beginning of the Run Ends Phase, the game processes each priority window that was open when the run was ended. This is done according to the following procedure:
- a.linkIf a paid ability window was open when the run was ended, the window closes. No player can trigger further paid abilities or resolve other options the window would normally allow (such as rezzing cards).
- Example: The Corp spends a counter from a scored Nisei Mk II to end the run. Once this happens, the Runner does not have an opportunity to use their bad publicity credits from this run to pay for using Self-Modifying Code.
- b.linkIf the run was ended during a reaction window opened due to a phase beginning, the reaction window closes, as per rule 9.2.8f. No other pending abilities are resolved.
- Example: The Runner uses the ability on Security Nexus during a reaction window at the beginning of the Encounter Ice Phase. The trace is successful, so the ability ends the run. If Tollbooth's ability is also pending in this reaction window, it will not be resolved, since the encounter has ended.
- c.linkAny other open priority window is completed normally. If more than one priority window needs to be completed this way, they are resolved in the usual order described in section 9.1.2.
- 6.8.3.linkDuring the Run Ends Phase, if the Runner has any credits from bad publicity remaining in their credit pool, the Runner loses those credits.
- 6.8.4.linkAs part of the Run Ends Phase, the game determines whether the run should be declared an unsuccessful run. This is a label applied to runs in which the Runner failed to reach the server they attacked, and is referred to by card abilities. The run is declared unsuccessful if neither of the following conditions have been met:
- a.linkIf the run reached step 6.9.5, the Success Phase, it is not declared unsuccessful. This is the case regardless of whether the run was actually declared successful.
- Example: The Runner reaches a server with Crisium Grid rezzed. Crisium Grid's ability stops the run from being declared successful, but the run is not declared unsuccessful either.
- b.linkIf the attacked server has ceased to exist, the run is not declared unsuccessful. See rule 8.5.8.
- 6.8.5.linkConditions related to a run ending are not met as soon as an "end the run" effect resolves or at the beginning of the Run Ends Phase. Instead, these conditions are met at step 6.9.6d, when the entire run timing structure is complete. Similarly, static abilities that apply during a run and durations that apply until the end of a run expire at step 6.9.6d.
- Example: The Runner plays The Noble Path to make a run in which they prevent all damage. During the run, the subroutine on Chum resolves, and then the Runner encounters Wall of Static and does not break its subroutine. When the "end the run" ability resolves, the encounter also ends, so the trigger condition on Chum's delayed conditional ability is met. The ability will resolve and fail to damage the Runner during the Run Ends Phase, because The Noble Path's effect still applies. Similarly, Georgia Emelyov's first ability meets its trigger condition at step 6.9.6c, which is still before the run is over, so the damage will be prevented.
- Example: The Runner plays The Noble Path to make a run in which they prevent all damage. The run is successful but the Runner takes a tag during the run. When the run ends, Dedicated Response Team's ability meets its trigger condition at the same time that The Noble Path's effect expires, so the Runner will suffer 2 meat damage.
- 6.9.1.linkInitiation Phase
- a.linkThe Runner announces the attacked server.
- b.linkThe Runner gains 1[c] to spend during the run for each bad publicity the Corp has.
- c.linkThe run formally begins. Conditions related to the run beginning or initiating are met.
- d.linkThe Initiation Phase is complete. If the attacked server has at least one piece of ice protecting it, proceed to step 6.9.2, Approach Ice Phase, approaching the outermost piece of ice protecting the attacked server. If the attacked server is not protected by ice, proceed to step 6.9.4, Movement Phase.
- 6.9.2.linkApproach Ice Phase
- a.linkThe approach begins. Conditions related to the Runner approaching this ice are met.
- b.linkA paid ability window occurs, in which players may use paid abilities and the Corp may rez non-ice cards. Additionally, the Corp can rez the approached piece of ice. (P) (R)
- c.linkThe Approach Ice Phase is complete. If the approached piece of ice is rezzed, continue to step 6.9.3, Encounter Ice Phase. Otherwise, proceed to step 6.9.4, Movement Phase.
- 6.9.3.linkEncounter Ice Phase
- a.linkThe encounter begins. Conditions related to the Runner encountering this ice are met.
- b.linkA paid ability window occurs, in which players may only use paid abilities. Subroutines on the encountered ice can be broken during this window. (P)
- c.linkIf there are unbroken subroutines that have not yet resolved this encounter, the Corp resolves the next such subroutine in order. Otherwise, skip to (e).
- d.linkReturn to (c).
- e.linkThe Encounter Ice Phase is complete. Continue to step 6.9.4, Movement Phase.
- 6.9.4.linkMovement Phase
- a.linkIf the Runner's position corresponds to a piece of ice, the Runner passes that ice. Conditions related to passing ice are met. If there are no positions more inward than the ice just passed, conditions related to passing all of the ice protecting a server are also met.
- b.linkA paid ability window occurs, in which players may only use paid abilities. (P)
- c.linkThe Runner may choose to jack out, proceeding to step 6.9.6, Run Ends Phase. If the Runner does not, continue to (d).
- d.linkThe Runner's position moves to the next position inward, if any.
- e.linkA paid ability window occurs, in which players may use paid abilities and the Corp may rez non-ice cards. (P) (R)
- f.linkIf the Runner moved to a new position, return to step 6.9.2, Approach Ice Phase, approaching the piece of ice in their new position. If not, continue to (g).
- g.linkThe Runner approaches the attacked server. Conditions related to the Runner approaching a server are met.
- h.linkThe Movement Phase is complete. Continue to step 6.9.5, Success Phase.
- 6.9.5.linkSuccess Phase
- a.linkThe run is declared successful. Conditions related to a successful run are met.
- b.linkThe Runner breaches the attacked server.
- c.linkThe Success Phase is complete. Continue to step 6.9.6, Run Ends Phase.
- 6.9.6.linkRun Ends Phase
- a.linkAny priority windows that were open when the run moved to this phase are completed or closed as described in section 6.8.2.
- b.linkThe Runner loses any unspent bad publicity credits.
- c.linkIf the Success Phase was not reached during this run and the attacked server still exists, the run becomes unsuccessful.
- d.linkThe Run Ends Phase and the run as a whole are both complete.
- 7.1.1.linkAccessing is the process of the Corp showing one of their cards to the Runner for potential interaction.
- 7.1.2.linkWhile the Runner is accessing a card, the Runner is allowed to look at that card, even if it would normally not be visible to them. While the Runner is accessing a card, the Corp is allowed to look at it as well, except when the card is being accessed from R&D.
- 7.1.3.linkAn ability that meets its trigger condition when its source card is accessed is active even if the source card is inactive. See section 9.1.8.
- 7.1.4.linkDuring each access, the Runner has 1 opportunity to use a mid-access ability. This occurs after the reaction window at the beginning of the access, and before the Runner steals an accessed agenda.
- 7.1.5.linkThe Runner always has the ability "Access → Pay the trash cost of the accessed card: Trash it." This is the basic trash ability.
- a.linkAll assets and upgrades have trash costs, as do some ice and operations. If a card does not have a trash cost, the Runner cannot pay its trash cost, and therefore the Runner cannot use the basic trash ability during that access.
- b.linkThe Runner cannot trash or pay the trash cost of a card in the Corp's discard pile, either with the basic trash ability or with other mid-access abilities.
- c.linkOne card, Mumbad Virtual Tour, has the ability "If the Runner accesses this upgrade while it is installed, they must trash it, if able." When this ability applies, the Runner can use any mid-access ability they have available that trashes the card, but they cannot decline to use a mid-access ability or use one that would not trash the accessed card unless they are unable to pay the cost of any ability that would trash it.
- d.linkOne card, Neutralize All Threats, has the ability "The first time each turn you access a card with a trash cost, reveal it. You must trash that card by paying its trash cost, if able." When this ability applies, the Runner can only use the basic trash ability. They cannot decline to use a mid-access ability or use a mid-access ability available from a card unless they cannot pay the cost of the basic trash ability.
- 7.1.6.linkIf, after resolving mid-access abilities, the Runner is still accessing an agenda, they must steal it.
- a.linkSome abilities can create additional costs to steal an agenda. The Runner can decline to pay such costs and not steal the agenda. See section 1.16.10.
- 7.1.7.linkIf a card moves to another location while it is being accessed, the access ends immediately.
- 7.1.8.linkIf a run is in progress, an instruction to end the run ends any access taking place. If an access is occurring outside of a run, an instruction to end the run has no effect on that access.
- 7.1.9.linkOne card, Information Sifting, uses a method other than a breach to establish a set of cards for the Runner to access. The Runner accesses those cards one at a time in the order of their choice. Each access is performed as a separate instruction. See rule 9.11.4b. Accessing cards in this way is an exception to rule 9.12.2a.
- 7.1.10.linkOne card, Counter Surveillance, instructs the Runner to access a certain number of cards from a server without mentioning a breach. The procedure for these accesses follows the normal rules for breaching that server except: there is no random access limit if the server is HQ or R&D; and the procedure ends once the designated number of cards have been chosen for access.
- 7.2.1.linkThe card is accessed. Conditions related to accessing this card are met.
- 7.2.2.linkThe Runner may use a single mid-access ability, such as the basic trash ability.
- 7.2.3.linkIf the accessed card is an agenda, the Runner must steal it.
- 7.2.4.linkThe access is complete. Conditions related to an access ending are met.
- 7.3.1.linkBreaching a server is the process of the Runner accessing a particular set of cards associated with that server. Most accesses occur during a breach. Step 6.9.5b of a run calls for the Runner to breach the attacked server, but card abilities can also directly instruct the Runner to breach a server.
- 7.3.2.linkWhen the Runner breaches Archives, all the facedown cards in the Corp's discard pile are turned faceup before the Runner accesses any cards.
- a.linkIf a card is added to Archives facedown after this step, that card remains facedown for the remainder of the breach, even after it is accessed. The Runner can only look at a facedown card in Archives while accessing it.
- 7.3.3.linkThe cards associated with a breached server that the Runner could potentially access are called Candidates. The set of candidates is compiled from the cards in the root of the breached server and, for central servers, the cards in the zone that corresponds to that server (see rule 4.6.7a). Section 7.4 defines which of these cards are candidates.
- 7.3.4.linkDuring a breach, the Runner is presented with the current candidates. They choose 1 of those cards and access it. This process repeats until there are no longer any candidates.
- a.linkWhen presented with candidates during a breach of HQ, the Runner chooses either a specific candidate that is not in the Corp's hand or to access a random candidate from among the ones in the Corp's hand. A card randomly chosen this way is treated as though the Runner had chosen it.
- b.linkOne card, Dedicated Neural Net, instructs the Corp to choose which cards the Runner accesses from HQ. While this effect applies, the Runner still chooses candidates that are not in the Corp's hand as normal. Whenever the Runner chooses to access a candidate from the Corp's hand, instead of a candidate being chosen at random, the Corp chooses 1 of those candidates for the Runner to access. The chosen card is still treated as though the Runner had chosen it.
- 7.3.5.linkThe Runner can only choose candidates from the Corp's hand or deck a limited number of times during a breach of HQ or R&D, respectively. This number is called the Random Access Limit. Before the Runner begins accessing cards during a breach of HQ or R&D, the random access limit for that breach is determined, after which it will not change for the remainder of that breach.
- a.linkBy default, the random access limit is 1.
- b.linkIf an ability allows the Runner to "access additional cards" during a breach of HQ or R&D, the effect of that ability is to increase the random access limit. Such an ability can only be applied at the beginning of the breach, before the value of the random access limit is set.
- c.linkCards are counted against the random access limit in the manner described in rule 7.3.6a.
- 7.3.6.linkSome rules and abilities refer to the number of cards the Runner accesses or the number of times the Runner accesses a card.
- a.linkIf such a reference applies while a breach is in progress, it counts the number of times a candidate has been chosen so far during that breach, regardless of how many of those candidates have actually been accessed.
- Example: The Runner plays Immolation Script, and the subroutine on Hudson 1.0 resolves before Archives is breached. The Runner will only be able to choose 1 candidate during the breach, regardless of whether they choose to access that card or apply Immolation Script's replacement effect.
- b.linkIf such a reference applies after a breach is complete, it counts only the number of times the Runner actually resolved an access during that breach.
- Example: The Runner plays Rip Deal while they have Obelus installed. If they use Rip Deal's ability to replace accesses of cards in HQ with adding cards from the heap to the grip, the cards those replacement effects applied to were not accessed. When Obelus's ability resolves after the breach ends, it will only cause the Runner to draw cards for upgrades they accessed in the root of HQ.
- 7.3.7.linkIf a run is in progress, an instruction to end the run ends any breach taking place. If there is no run in progress, an instruction to end the run has no effect on a breach.
- 7.3.8.linkIf a server would be breached while a breach is already in progress, instead the new breach takes place when the current breach ends. The effect creating the delayed breach is treated as a conditional ability controlled by the Runner.
- Example: The Runner steals Clone Retirement during a breach of HQ, causing the Corp to take bad publicity. The Runner must complete the current breach before beginning the breach granted from Raymond Flint's first ability.
- 7.4.1.linkThe candidates at the beginning of a breach are as follows:
- a.linkEach card in the root of the breached server is a candidate
- b.linkIf the breached server is HQ, each card in the Corp's hand is a candidate
- c.linkIf the breached server is R&D, the top card of the Corp's deck is a candidate.
- d.linkIf the breached server is Archives, each card in the Corp's discard pile is a candidate.
- 7.4.2.linkIf at any time the Runner is prohibited from accessing an object, that object ceases to be a candidate and cannot become a candidate.
- Example: The Corp performs a successful trace with the ability on Ash 2X3ZB9CY, prohibiting the Runner from accessing any card other than Ash for the remainder of the current run. When the server is breached, Ash will be the only candidate for the Runner's first selection, and then there will be no candidates remaining, so the breach will end.
- a.linkOne card, Hudson 1.0, creates an effect that prohibits the Runner from accessing more than 1 card during a run. This effect always considers whether the Runner has actually accessed a card during that run, even when rule 7.3.6a would normally apply. If the Runner has accessed any cards, this effect prohibits all accesses, and therefore there will be no candidates.
- 7.4.3.linkOnce the Runner chooses a candidate for access, it ceases to be a candidate for the remainder of that breach. It does not matter whether the chosen candidate is actually accessed. As long as the card is chosen, it ceases to be a candidate.
- Example: The Runner is breaching Archives during a run made with Immolation Script. They choose a piece of ice from the set of candidates, and apply Immolation Script's replacement effect to trash another card instead of accessing the chosen ice. After resolving this, the chosen ice is no longer a candidate and cannot be accessed again this breach. (The newly-trashed card, however, could be a candidate.)
- Example:
- 7.4.4.linkWhen the random access limit is reached during a breach of HQ or R&D, all candidates in the zone corresponding to the breached server cease to be candidates, and no cards in that zone can become candidates for the remainder of that breach. See section 7.3.5.
- 7.4.5.linkIf a candidate leaves the breached server, it ceases to be a candidate. Note that the moved card could be a new object, which could be eligible to become a new candidate if appropriate.
- Example: The Runner trashes an installed upgrade during a breach of Archives. That card moves to the Corp's discard pile. The new object for the upgrade's existence in the Corp's discard pile becomes a candidate, so the Runner will access the same physical card twice during this breach.
- 7.4.6.linkCards entering a server while a breach is in progress can become candidates.
- a.linkIf a card enters the root of a server during a breach of that server, the Runner decides whether that card becomes a candidate during step 10.3.1i of the next checkpoint.
- b.linkIf a card enters the Corp's hand during a breach of HQ while the random access limit has not yet been reached, that card becomes a candidate.
- c.linkIf a card enters the Corp's deck during a breach of R&D, that card could become a candidate (either at that time or later in the breach), depending on the random access limit and its position within the deck. See section 7.4.7.
- d.linkIf a card enters the Corp's discard pile during a breach of Archives, that card becomes a candidate. See also rule 7.3.2a.
- 7.4.7.linkDuring a breach of R&D, the Runner is presented with 1 candidate from the Corp's deck at a time in turn, working down from the top of the deck. Cards are made candidates 1 at a time until the access limit is reached.
- a.linkAfter the Runner chooses a candidate from the Corp's deck and whenever any cards enter, leave, or are reordered within the Corp's deck, all cards in the Corp's deck cease to be candidates. Then, if the random access limit has not been reached, the topmost eligible card in the deck becomes a candidate. A card is eligible for this purpose if the Runner has not already chosen to access that object and is not prohibited from accessing that object in this breach.
- Example: The Runner plays The Maker's Eye and breaches R&D, accessing 2 additional cards. They access Celebrity Gift and then access and steal Bacterial Programming. The Corp uses Bacterial Programming's ability to rearrange cards in R&D, but they leave Celebrity Gift as the top card of R&D. The cards returned to the top of R&D are new objects, so the Runner must continue the breach from the top of R&D and will access Celebrity Gift again.
- Example: The Corp is playing Seidr Laboratories and has Strongbox rezzed in the root of R&D. The Runner breaches R&D with a random access limit of 4. They first access the top card of the Corp's deck and leave it in place. The 2nd card from the top now becomes a candidate, and turns out to be an agenda, which the Runner steals by spending [click] to pay the additional cost imposed by Strongbox. The Corp then uses Seidr Laboratories to add 1 card from Archives to the top of R&D. The 3rd candidate presented to the Runner is the card newly added to the top of R&D. After accessing that card, the next card down is still the object that was accessed first, so the card below that (currently 3rd from the top) becomes the 4th and final candidate.
- b.linkOne card, Showing Off, allows the Runner to access cards from the bottom of R&D. While this effect applies, candidates in the Corp's deck are presented working up from the bottom: treat rule 7.4.1c as if it said "bottom" instead of "top" and rule 7.4.7a as if it said "bottommost" instead of "topmost".
- 7.5.1.linkBreaching the server formally begins. Conditions related to breaching this server are met.
- 7.5.2.linkIf the breached server is Archives, turn all cards in the Corp's discard pile faceup.
- 7.5.3.linkIf the breached server is HQ or R&D, determine the limit to how many times the Runner can choose a candidate from the Corp's hand or deck.
- 7.5.4.linkThe Runner chooses a candidate. If they cannot, skip to step 7.5.7.
- 7.5.5.linkThe Runner accesses the chosen card.
- 7.5.6.linkReturn to step 7.5.4.
- 7.5.7.linkThe breach is complete. Conditions related to the breach ending are met.
- 8.1.1.linkAn agenda, asset, upgrade, or piece of ice is unrezzed if it is installed and facedown. An asset, upgrade, or piece of ice is rezzed if it is installed and faceup. Runner cards, faceup agendas, operations, events, and counters are neither rezzed nor unrezzed.
- 8.1.2.linkTo rez an unrezzed card is to turn it faceup.
- a.linkSome paid ability windows allow the Corp to rez assets and upgrades. See section 9.2.7. The paid ability window at step 6.9.2b of a run allows the Corp to rez ice.
- b.linkCard abilities can direct or allow the Corp to rez cards at other times.
- c.linkAgendas cannot be rezzed.
- d.linkBefore rezzing a card, the Corp must pay that card's rez cost. This includes both rezzing in a paid ability window and rezzing through a card ability. Card abilities can modify or ignore rez costs, but must state this explicitly.
- e.linkTo resolve rezzing a card, the Corp pays its rez cost (accounting for any modifiers or additional costs), a checkpoint occurs (as required by rule 10.3.4), then the Corp turns the card faceup. For purposes of meeting trigger conditions, the card is considered to be rezzed at the conclusion of this process.
- 8.1.3.linkTo derez a rezzed card is to turn it facedown.
- a.linkCards are only derezzed by card effects.
- b.linkThere is no inherent cost associated with derezzing a card.
- c.linkDerezzing a card is instantaneous and has no component steps.
- 8.1.4.linkSome abilities can install Runner cards facedown or turn already-installed Runner cards facedown.
- a.linkInstalled Runner cards that are facedown do not have a name, type, or subtypes, and their abilities are not active.
- b.linkFacedown installed Runner cards are distinct. The origin of each such card (when and how it was installed facedown, or what faceup installed card was turned facedown) is open information.
- c.linkAfter a facedown Runner card enters the heap, it is turned faceup.
- d.linkA Runner card turned facedown is not considered to be uninstalled and simply remains in the play area.
- e.linkIf an installed facedown Runner card is turned faceup, the card gains its name, type, and subtypes, and it becomes active. Turning an installed facedown Runner card faceup does not meet the trigger conditions of "when installed" abilities.
- f.linkRunner cards are never considered rezzed or unrezzed.
- 8.2.1.linkA movement is a way that cards change their zone or location following special rules. The movements are: arrange, draw, forfeit, install, play, search, score, steal, swap, and trash.
- a.linkOther terms that change the locations of cards are not movements. If an ability directs a player to "add" or "move" cards to 1 or more locations, simply put those cards in the indicated locations. If an ability or game rule directs a player to "discard", "set aside", or "remove from the game" 1 or more cards, simply put those cards in their owner's discard pile, the set-aside zone, or the removed-from-game zone, respectively.
- 8.2.2.linkIf a replacement effect modifies the effects of a movement, but does not replace the entire movement by name, the modified effect is still an occurrence of that movement and can still meet trigger conditions relating to that type of movement.
- Example: Harbinger's ability modifies the effects of trashing it by replacing adding Harbinger to the heap with turning it facedown. Harbinger is still trashed when the modified effect resolves. If this is the first time this turn that the Runner trashed one of their installed cards, they will be able to resolve Wasteland's ability.
- a.linkIf a movement is replaced or prevented entirely or otherwise cannot be carried out, that movement does not take place and conditions related to that type of movement are not met.
- Example: The Corp is resolving the first subroutine on Rototurret to trash an installed program. The Runner uses Sacrificial Construct to prevent the program from being trashed. Since trashing did not occur, the Runner does not place a power counter on District 99, and District 99 can still meet its trigger condition if a program or piece of hardware is successfully trashed later in the turn.
- 8.2.3.linkTo arrange a set of cards is to reposition them among their current locations. The full rules for arranging are detailed in section 8.3.
- 8.2.4.linkTo draw a given number of cards is to move that many cards from the top of a player's deck to their hand. The full rules for drawing cards are detailed in section 8.4.
- 8.2.5.linkTo forfeit an agenda is to move it from a player's score area to the removed-from-game zone. When a player forfeits an agenda, its agenda points no longer contribute to that player's score, and any objects hosted on it are trashed.
- 8.2.6.linkTo install a card is to move it from its current zone to the play area. The full rules for installing cards are detailed in section 8.5.
- 8.2.7.linkTo play an event or operation is to move it from its current zone to the play area, resolve its play abilities, and then trash it. The full rules for playing events and operations are detailed in section 8.6.
- 8.2.8.linkTo search is to look at a specified zone and potentially set aside cards from that zone. The full rules for searching are detailed in section 8.7.
- 8.2.9.linkTo score an agenda is to move it from its current zone to the Corp's score area. The full rules for scoring are detailed in section 1.17.
- 8.2.10.linkTo steal an agenda is to move it from its current zone to the Runner's score area. The full rules for stealing are detailed in section 1.17.
- 8.2.11.linkTo swap a pair of cards is to move each card to the other's location simultaneously. The full rules for swapping are detailed in section 8.8.
- 8.2.12.linkTo trash a card is to move it from its current zone to its owner's discard pile. The full rules for trashing are detailed in section 1.19.
- 8.3.1.linkTo arrange or rearrange an ordered set of 2 or more cards is to reposition them among their current locations. The words "arrange" and "rearrange" are synonymous.
- a.linkIf a player is instructed to arrange 1 or fewer cards, instead that player does nothing.
- 8.3.2.linkWhen a player arranges a set of installed ice, that player carries out the arrangement by repeatedly choosing and swapping 2 pieces of ice. Each swap follows all the usual rules for swapping cards in section 8.8.
- a.linkNo checkpoints occur during the sequence of swaps. An ability that meets its condition while ice is being arranged will become pending at the end of resolving the instruction in which arranging ice is taking place.
- 8.3.3.linkWhen a player arranges cards from the top of their deck or their opponent's deck, that player sets those cards aside facedown, secretly puts them in the order of their choice, and returns them to the top of that deck. They do not declare which cards moved to which positions. All of the arranged cards become new objects after they are arranged, even cards that remain in the same location in the deck.
- 8.4.1.linkdrawing cards is a process that moves cards from a player's deck to their hand.
- 8.4.2.linkTo draw 1 or more cards, a player sets aside that many cards from the top of their deck facedown. The cards are then considered drawn, and abilities with trigger conditions related to cards being drawn can act on them. When resolving any such abilities is complete, the set-aside cards are added to their owner's hand.
- a.linkAbilities with a trigger condition that refers to cards being drawn can see the drawn cards in the set-aside zone. This is an exception to rule 4.8.3.
- b.linkAbilities that do not refer specifically to cards a player has drawn are subject to rule 4.8.3, and only see the drawn cards move directly from the player's deck to their hand.
- 8.4.3.linkAbilities that resolve while drawn cards are set aside can move those cards or add new cards to that set.
- a.linkIf a drawn card leaves the set-aside zone, it is no longer considered "drawn" and remains in its new location when the drawn cards are added to the hand.
- b.linkIf a drawn card is swapped with another card, the card swapped into the set-aside zone is now considered "drawn", can be manipulated by other abilities, and will be added to the hand with the other drawn cards.
- Example: The Corp takes their mandatory draw while they have Daily Business Show and Raman Rai rezzed. They set aside Wraparound and Enigma from the top of R&D. After looking at those cards and the cards in Archives, the Corp uses Raman Rai to reveal the Enigma and a Tollbooth from Archives and swap them. Then, the corp uses Daily Business Show to add Tollbooth to the bottom of the deck. Finally, the Corp adds Wraparound to HQ.
- 8.4.4.linkIf an ability directs multiple players to draw cards at the same time, those players follow the procedure for drawing cards together. Abilities relating to all of those draws will become pending in the same reaction window.
- a.linkIf an ability gives multiple players the option to draw cards at the same time, first each player indicates whether or how many cards they will draw, starting with the active player. Then the indicated draws are performed simultaneously.
- 8.4.5.linkSteps of Drawing N Cards
- a.linkSet aside N cards from the top of the drawing player's deck. The cards are now considered drawn and can be looked at by their controller.
- b.linkA checkpoint occurs.
- c.linkAdd the set-aside cards to the player's hand.
- 8.5.1.linkInstalling an agenda, asset, ice, upgrade, hardware, program, or resource card is the act of placing that card into the play area. Events, operations, and identities are never installed.
- a.linkCards and counters can also be installed onto other cards if either the card being installed onto or the card or counter being installed has an ability allowing this. The relationship created this way is called hosting and is discussed in section 1.13. Some abilities also host cards without installing them.
- b.linkA card or counter is uninstalled when it stops being installed for any reason.
- 8.5.2.linkCorp cards are installed facedown, unrezzed, and remain inactive until rezzed. Corp cards are installed into specific locations. See section 4.6.6 for more information on servers and the locations of installed Corp cards.
- a.linkAs part of installing a card, the Corp chooses which server will be the destination for that card. The Corp can either choose an already existing server as the destination or announces that the card will create a new remote server.
- b.linkThe Corp always installs an agenda or asset into the root of a remote server.
- c.linkThe Corp always installs an upgrade into the root of a central or remote server.
- d.linkUnless otherwise indicated, the Corp always installs ice into the outermost position protecting the destination server.
- 8.5.3.linkCards in servers cannot be rearranged unless instructed by a card ability. To organize this hidden information for both players, it is important that the Corp observes the following rules for card orientation:
- a.linkAgendas, assets, and upgrades are always installed in a vertical orientation. An upgrade in the root of a remote server is installed in the same position as an agenda or asset. The Runner should not be able to tell what type of card is installed in the root of a remote server by its position.
- b.linkIce is always installed in a horizontal orientation.
- 8.5.4.linkRunner cards are normally installed faceup, active. Runner cards are generally installed without designated locations.
- 8.5.5.linkInstalling cards is an exception to rule 9.12.2a. If an effect would install more than one card, then those cards are chosen and installed one at a time, following all of the steps of the installation process (step 8.5.15) for each card before choosing and installing the next. Each such installation is performed as a separate instruction. See rule 9.11.4b.
- Example: The Runner uses Mass Install to install three programs. The Runner can install Dhegdheer first, and then host one of the other two programs on Dhegdheer in order to reduce the install cost.
- 8.5.6.linkAs part of the installation process, a player installing an agenda, asset, upgrade, ice, or program has the opportunity to trash like cards.
- a.linkWhen installing an agenda or asset in the root of a remote server, or an upgrade in the root of any server, the Corp may first trash any number of other cards already installed in the root of that server. If the card to be installed is an asset or agenda, the Corp must trash any other asset or agenda from that server. If the card to be installed is a region, the Corp must trash any other region from that server.
- b.linkWhen installing ice protecting a server, the Corp may first trash any number of other ice already installed protecting that server. Ice trashed in this way will not be counted when determining the install cost of the new ice.
- c.linkWhen installing a program, the Runner may first trash any number of programs already installed. They must do so if installing the new program would exceed their memory limit.
- 8.5.7.linkIf the Corp trashes any cards during the installation process, the trashed cards are placed in Archives with the same faceup or facedown status they had while installed.
- 8.5.8.linkIf the last card protecting a remote server or in the root of that server is uninstalled outside of the process of installing another card, then the server ceases to exist during the next checkpoint. See section 10.3.
- 8.5.9.linkThe Corp cannot destroy a server by installing cards. While the Corp is installing a card with a remote server as its destination, that server does not cease to exist during any checkpoints that occur before the install effect is complete. Even if the last card installed in the root of or protecting a remote server is trashed during the installation process, it is still considered the same server after the new card has been installed.
- 8.5.10.linkIf a piece of ice is uninstalled while being approached or encountered, any open paid ability window is completed. Then the approach or encounter ends without completing any further steps of that timing structure. The Runner passes the position the uninstalled ice had occupied, and the run continues. See section 6.2 for rules about positions during a run.
- 8.5.11.linkSome types of cards have an install cost, which must be paid before the card can become installed, unless an ability indicates that this cost should be ignored.
- a.linkThe install cost of a piece of ice is 1 credit for each piece of ice already installed protecting the destination server at the time the cost is to be paid. The install cost of a piece of hardware, program, or resource is indicated on the card. Assets, agendas, upgrades, and facedown Runner cards have no install cost. See also rule 1.16.6b.
- b.linkIf a card has an install cost of X, the value for X is chosen by the player at the time the cost would normally be paid, according to any stipulations indicated in the card's text box. This value of X is maintained until the install effect is complete.
- c.linkAfter the install cost is paid, a checkpoint occurs, as required by rule 10.3.4.
- 8.5.12.linkSome upgrades have an ability that specifies 1 or more central servers or "remote server" followed by the word "only". This is a restriction on the locations an upgrade can occupy that applies at all times, even if the upgrade is inactive. The Corp cannot choose the root of a non-specified server as the installation destination for such an upgrade, and such an upgrade cannot be swapped into the root of a non-specified server.
- 8.5.13.linkIf a player attempts to install a facedown card or a card from a hidden or secret zone, they are required in certain cases to reveal that card in order to verify that the installation is valid.
- a.linkPlayers are not required to and should not reveal an installed card simply to verify that it has an appropriate card type.
- Example: The Corp controls a remote server with a facedown card in its root, and uses a basic action to install another card into that root. To satisfy the rules, the new card must be an asset, upgrade, or agenda, since those are the only card types that can normally be installed in the root of a remote server. Additionally, at least one of the two cards must be an upgrade, since there can only be at most 1 asset or agenda in the root of a server. However, the Corp does not reveal cards to verify either of these properties.
- Example: The Corp resolves the first subroutine on Brân 1.0. They do not reveal the card they install to verify that it is a piece of ice as stipulated in the text of the subroutine, nor do they reveal the card to verify that it is a piece of ice as necessitated from installing it protecting a server.
- b.linkPlayers are not required to and should not reveal an installed card to verify that it meets server limitations.
- Example: The Corp installs a card in the root of a server with a rezzed region upgrade. The new card cannot also be a region upgrade (unless the old one is trashed as part of the installation), as per section 3.6.5. They do not reveal the installed card to verify this.
- c.linkPlayers are required to reveal an installed card to verify any other requirements imposed by the ability that installs the card.
- Example: The Corp triggers the ability on Ob Superheavy Logistics by trashing a card with printed rez cost 5. They search R&D for Archer and install it, but decline to pay the additional cost to rez Archer. Since the ability requires the installed card to have printed rez cost 4, and the card is not otherwise visible to the Runner at any point in this process, the Corp must reveal Archer to verify that the installation is legal.
- d.linkSome abilities "install and rez" 1 or more cards. If the player resolving an "install and rez" effect is allowed to choose a card that they are unable to rez, or if the installed card has an additional cost to rez that the player declines to pay (see rule 1.16.4c), the player must reveal the installed card, regardless of whether other restrictions apply.
- Example: The Corp plays Trust Operation and installs an agenda from Archives with its "install and rez" effect. Since agendas cannot be rezzed, the Corp must reveal the installed agenda.
- Example: The Corp plays Ad Blitz. Since the "install and rez" effect on this card stipulates "if able", the Corp cannot choose to install cards they are unable to rez, nor can they decline additional costs if any apply.
- 8.5.14.linkSome abilities install cards to a specific location. If an ability specifies a destination that is invalid or cannot be identified, no installation can take place.
- Example: The Corp uses Nanisivik Grid to resolve the first subroutine on a copy of Brân 1.0 in Archives. This subroutine attempts to install ice "directly inward" from Brân 1.0, but this copy of Brân 1.0 is not protecting a server and therefore does not have a position from which "directly inward" can be evaluated. There is no legal way to install a card as directed, so the subroutine will have no effect.
- 8.5.15.linkSteps of Installing a Card
- a.linkPlace the card into the play area with the same faceup or facedown status it will have when the installation is complete. It is not yet installed or active.
- b.linkChoose and declare the install destination appropriate to the card that will be installed, including any host relationships, if applicable.
- c.linkTrash like cards as described in section 8.5.6.
- d.linkPay the appropriate install cost. (The cost-paid checkpoint then occurs.)
- e.linkIf the card is to be the first card in the root of or protecting a new remote server, that server is created. Move the card to the chosen install location. It becomes installed. If the card is faceup, it becomes active.
- f.linkAny "When installed..." abilities that apply to the installation meet their trigger conditions, including those on the installed card, and the install effect is complete.
- 8.6.1.linkPlaying an event or operation is the act of placing that card into the play area. Agendas, assets, ice, upgrades, hardware, programs, resources, and identities are never played.
- 8.6.2.linkNormally, playing an operation or event requires paying its play cost. Abilities that initiate playing a card may ignore the play cost or require it to be paid.
- a.linkIf a card has a play cost of X, the value for X is chosen by the player at the time the play cost is paid, according to any stipulations written on the card. This value of X is maintained while resolving the event or operation.
- b.linkAfter the play cost is paid, a checkpoint occurs, as required by rule 10.3.4.
- 8.6.3.linkPlaying cards is an exception to rule 9.12.2a. If an effect would play more than one card, then those cards are chosen and played one at a time, following all of the steps of the play process (step 8.6.6) for each card before choosing and playing the next. Each such card is played as a separate instruction. See rule 9.11.4b.
- Example: The Corp uses Subcontract to play Hedge Fund and another operation. The Corp can use the credits gained from Hedge Fund to pay for the second operation.
- 8.6.4.linkOperations and events can create lingering effects. Once those effects exist, they become independent of the source operation or event and the card is considered fully resolved and ready to be trashed. See section 9.10.
- Example: Test Run creates a delayed conditional ability that will resolve at the end of the turn, but Test Run itself is considered fully resolved and is trashed once it finishes installing a program.
- 8.6.5.linkAn operation or event that initiates a timing structure remains active in the play area for the duration of that timing structure. It is not considered fully resolved until the timing structure is completed and any abilities on the card that meet their trigger conditions when the timing structure ends are resolved.
- 8.6.6.linkSteps of Playing an Event or Operation
- a.linkPlace the card faceup into the play area. It is not installed and not yet active.
- b.linkPay the play cost. (The cost-paid checkpoint then occurs.)
- c.linkThe card becomes active.
- d.linkConditions related to playing an event or operation are met.
- e.linkA checkpoint occurs.
- f.linkResolve the play abilities of the card.
- g.linkTrash the card if it is still in the play area.
- h.linkConditions related to after resolving or finishing resolving an event or operation are met.
- i.linkThe play effect is complete.
- 8.7.1.linkIf a player is instructed to search a zone for one or more cards, they look at all the cards in that zone for cards matching the criteria of the search.
- a.linkIf a player is instructed to search a hidden or secret zone, they are temporarily allowed to look at those cards until the search is complete, so long as they maintain that zone as hidden or secret as necessary to the other player.
- 8.7.2.linkWhile a player is searching, they may find an appropriate number of cards matching any criteria of the search by taking them from the zone being searched and setting them aside facedown.
- a.linkThe card found with a search must match the criteria specified by the search effect.
- b.linkWhen a search is followed by an install instruction referring to the found card(s), then the player must be able to install the card(s) they find. The same is true when the search is followed by a play instruction.
- Example: The Runner uses Artist Colony to search for a card and install it. They cannot find an event with the search because events can never be installed. They also cannot find a program, hardware, or resource that they cannot afford to install.
- Example: The Runner uses Self-Modifying Code to search for a program and install it. They have no more credits after using the ability of Self-Modifying Code, but they have an installed copy of Patchwork. They can search for Imp and install it, but they must use Patchwork by trashing a card from their grip to install Imp. If the Runner does not have a card in their grip, they cannot find and install Imp.
- Example: The Corp uses Tucana to search for Pharos while they have 0 credits. They are allowed to find and install Pharos, even though they cannot afford to rez it. The Corp must reveal Pharos to show that it cannot be rezzed. See rule 8.5.13d.
- c.linkThe searching player is not required to reveal any found cards unless instructed to do so by the ability that initiated the search. Found cards are not revealed until resolution of the ability that initiated the search resumes, pending any necessary shuffling.
- d.linkIf a player is searching for a set number of cards without any specified criteria, they must find that many cards from that zone or all the cards in that zone if there are not enough.
- e.linkIf a player is searching a deck for one or more cards with specified criteria, they may choose to fail to find anything, even if one or more cards matching the criteria exist in that deck.
- 8.7.3.linkOnce a search through a deck is complete, whether or not any cards are found, the deck must be immediately reshuffled before continuing to resolve any remaining effects from the ability that initiated the search. The shuffling takes precedence over anything that would be done with the found card(s), as well as any chain reactions that occur as a result of the search, finding, or remaining abilities.
- Example: The Corp is playing Near-Earth Hub and uses the ability on Tech Startup to search their deck for an asset and install it. After finding the asset, R&D must be immediately shuffled before the Corp installs the asset or triggers Near-Earth Hub's ability.
- 8.7.4.linkOnce the search is complete, and any shuffling necessary has occurred, resolution of the ability that initiated the search resumes. If no cards were found during the search, any effects referencing found cards fail to resolve, but as much of the remaining effects resolve as possible.
- 8.7.5.linkIf the trigger condition of a conditional ability involves a search, that ability becomes pending after the search is completed and any shuffling is performed, but before the found cards are acted on.
- 8.8.1.linkTo swap two cards is to exchange their locations.
- 8.8.2.linkA card can only ever be swapped into a location it is normally allowed to occupy. When a player resolves a swap effect, they must observe any applicable game rules or card abilities that would affect that card in its final destination. If a swap effect would resolve while there are no legal exchanges possible, then that effect does nothing.
- Example: When the subroutine on Metamorph resolves, the Corp cannot choose to swap an agenda and an upgrade such that the agenda would end up in the same remote server as an asset.
- 8.8.3.linkIf two installed cards are swapped, each card moves to the other's location simultaneously. The two cards remain installed throughout the process of swapping, and do not otherwise affect any other part of the game state.
- a.linkWhen swapping installed cards, any cards or counters hosted on either of the swapped cards maintain their hosting relationships.
- Example: The Corp uses Thimblerig's ability to swap it with a Palisade hosting Botulus. The Botulus remains hosted on the Palisade throughout this process.
- 8.8.4.linkIf two cards are swapped between zones, each card moves to the zone the other is in simultaneously.
- a.linkEach of the swapped cards enters its destination zone in the same state that a card would normally enter that zone. A card swapped into Archives enters Archives facedown unless it was visible to the Runner at the time of the swap, a Corp card swapped into the play area enters unrezzed, etc.
- b.linkIf only one of the cards to be swapped is installed, then it becomes uninstalled as it moves to the destination zone. Any cards or counters hosted on it are trashed. The other card becomes installed in the exact position the first card occupied, maintaining any specific location (such as server, ice position, or host). The normal procedure for installing a card is not followed, so no install cost is paid and like cards cannot be trashed. At the next checkpoint after the swap takes place, trigger conditions related to uninstalling or installing the two cards are met, respectively.
- Example: The Corp is playing A Teia: IP Recovery and has Tatu-Bola protecting a remote server. The Runner runs that server and passes Tatu-Bola. The Corp swaps it with a piece of ice from HQ. After the swap, the Corp can use A Teia's ability to install a card in the root of another remote server. They then continue resolving the next instruction of Tatu-Bola's ability, gaining 4[c].
- c.linkIf two agendas are swapped between the players' score areas, any hosted cards or counters remain hosted on their respective host agendas.
- d.linkIf a card is swapped with a set-aside card, the card moving into the set-aside zone becomes part of the group of cards being acted on by the ability that had set the other card aside, and the card moving out of the set-aside zone ceases to be acted on by that ability. See rule 8.4.3b for a specific case where this can happen, and see also rule 4.8.3 regarding effects acting on cards in the set-aside zone.
- 9.1.1.linkAn ability is an independent unit of text on a card or counter, a basic action, or the basic trash ability.
- a.linkAll rules text on a card or counter is part of an ability.
- b.linkThe basic actions are defined in section 5.2.7 and section 5.2.8.
- c.linkThe basic trash ability is defined in section 7.1.5.
- d.linkAn ability's text can include other abilities that it could grant to cards or counters or introduce directly to the game state. See also section 9.10.
- e.linkEach ability is categorized as either a static ability (section 9.4), a paid ability (section 9.5), a conditional ability (section 9.6), a play ability (section 9.7), or a subroutine (section 9.8).
- f.linkAbilities marked with [interrupt] or that include the words "prevent" or "avoid" in their instructions have special timing rules that differ from other abilities. See section 9.9.
- g.linkEach non-static ability contains one or more instructions that make up the ability's component steps. Section 9.3.4 describes the nature and function of instructions in an ability's text. An instruction that the game is presently concerned with can be either imminent or resolving.
- 9.1.2.linkTo resolve an ability means to resolve each of that ability's instructions in the order they appear. If an ability contains more than one instruction, a checkpoint occurs between each consecutive instruction. To resolve an instruction means to carry out that instruction.
- a.linkWhile resolving an ability, other abilities can meet their conditions. When this happens, a "chain reaction" is created. The current instruction finishes resolving, then more recent abilities fully resolve before the next instruction of the original ability. If any other abilities meet their conditions while resolving the "chained" abilities, then another "chain" is created before continuing to resolve the previous chained abilities. Resolve each set of chained abilities one at a time, from the most recently met condition to the oldest, before continuing with the original ability that started the chain reaction.
- Example: The Runner's identity is Armand "Geist" Walker. They access a Snare! from R&D with only 2 cards in their grip. Before taking a tag or suffering any net damage, the Runner triggers Decoy's ability in order to avoid the tag. Using the Decoy meets the trigger condition of Geist's ability. As this is the most recent ability to meet its trigger condition, Geist's ability must resolve first, before Decoy avoids the tag and before Snare! finishes resolving. The Runner draws a card from Geist, avoids the tag from Snare! with Decoy, and then finally suffers (and survives) the 3 net damage from Snare!.
- b.linkAn ability "is resolving" from when its first instruction becomes imminent until its last instruction has finished resolving. See also section 9.9. An event or operation "is resolving" throughout step 8.6.6f of playing that event or operation.
- Example: The Corp resolves a subroutine on Attini while its first ability is active. The subroutine is resolving during the interrupt window for its instruction, so the Runner cannot spend credits during that window and will not be able to use Caldera's ability to prevent net damage.
- Example: The Runner is playing Zahya Sadeghi: Versatile Smuggler and plays Direct Access to run HQ. The static ability on Direct Access removes Zahya Sadeghi's ability while it is resolving. Normally, that ability would meet its trigger condition and resolve immediately after the "Run any server." instruction. This reaction window is outside of the run, but it is still part of Direct Access resolving, so the ability is not present at the needed time and cannot be triggered or resolved.
- 9.1.3.linkThe source of an ability is the card, counter, or game rule that originated it.
- a.linkEach card is the source of its own printed abilities.
- b.linkIf something grants an ability to an object (see section 9.1.9), the source of the granted ability is that object, not whatever granted the ability.
- c.linkThe source of an ability that is being maintained by a lingering effect is the object that created that lingering effect. See section 9.10.
- 9.1.4.linkEach paid ability, conditional ability, and subroutine becomes independent of its source at a certain point before it resolves, as described in rules 9.5.4, 9.6.12 and 9.8.9, respectively. If the source changes zones after that point, the ability cannot act on the source.
- Example: The runner plays Compile, uses it to install Mayfly during the resulting run, and breaks subroutines with Mayfly during that run. When the run ends, delayed conditional abilities from both Mayfly and Compile become pending. The Runner decides to resolve Compile first, adding Mayfly to the bottom of their stack. The Runner then resolves the ability from Mayfly, which instructs them to trash its source program. Because Mayfly has changed zones, the copy of it on the bottom of the stack is a new object. With nothing to trash, the ability from Mayfly does nothing.
- 9.1.5.linkWhereas an ability, instruction, or declaration is made up of text, an effect is what happens in the game because of that text.
- a.linkAny of a non-static ability's effects that apply beyond the duration of that ability's resolution become independent of that ability and its source. The game engine takes responsibility for managing these lingering effects directly, and deletes them from the game state as their durations expire. See section 9.10.
- b.linkWhen determining whether a certain ability has the potential to change the game state, look only at the expected effects of the ability. Do not consider its costs or restrictions, and do not consider other abilities that could become pending or relevant because of triggering or resolving the ability. See rule 1.2.5 of the Golden Rules.
- 9.1.6.linkAny time a player chooses to resolve an optional ability or an optional part of an ability, the player is considered to be using that ability and the source card of that ability. Players do not "use" abilities that are entirely mandatory.
- a.linkA paid ability is considered used once the trigger cost has been paid. See step 9.5.6 for the steps of using a paid ability.
- b.linkA conditional ability is considered used once the relevant optional effects of the ability have been resolved by the controller of the ability. See step 9.6.15 for the steps of triggering and resolving conditional abilities.
- c.linkIf an ability allows a player to spend or move counters, that ability's source card is considered used at the time the player pays a cost by spending or moving those counters, even if the counters are spent or moved from cards other than the card that is the source of that ability.
- Example: The Runner spends the credit hosted on Cyberfeeder to pay the trigger cost of Mimic's ability. Because the Runner triggered Mimic's paid ability and Cyberfeeder's ability allowed the credit to be spent, both Mimic and Cyberfeeder have been used.
- d.linkA player can only use an ability if its effect has the potential to change the game state. See rule 1.2.5.
- 9.1.7.linkAbilities are active if they are eligible to be resolved or apply to the current game state, and inactive otherwise. By default, a card's abilities are active if and only if that card is active (see section 1.8.3). Abilities of counters are active for as long as the counter exists.
- 9.1.8.linkSome types of abilities are active even while their source card is inactive.
- a.linkConditional abilities that meet their conditions when their source card is accessed are active even while that card is inactive.
- b.linkAbilities stating that they are active in a particular zone are active in that zone. Abilities that can only ever meet their conditions in a particular zone are active in that zone. Abilities that can only affect the game state from a particular zone are active in that zone. When determining whether these stipulations apply, refer only to the game rules, not to any other effects that may be changing how cards move between zones.
- Example: I've Had Worse has an ability that meets its trigger condition when it is trashed due to damage. Normally, this can only occur by moving I've Had Worse from the grip to the heap. Therefore, this ability is active in the heap. However, if I've Had Worse is trashed, but the Corp uses Skorpios Defense Systems to remove it from the game instead of adding it to the heap, the ability is not active.
- c.linkAbilities that modify when or if their source card can be played, installed, or rezzed are active even while that card is inactive.
- d.linkAbilities that modify the cost to install, rez, or play their source card are active even while that card is inactive.
- e.linkAbilities that define or modify the advancement requirement of their source card or create an additional cost to steal their source card are active even while that card is inactive.
- f.linkAbilities allowing a card to be advanced are active even while that card is unrezzed.
- g.linkIf an active card moves to a zone where it is inactive, an ability of that card with a trigger condition that is met by this zone change remains active in the card's new location until any corresponding instances of the ability resolve. See rule 9.6.2 for information about instances of conditional abilities.
- Example: The Runner uses Singularity to simultaneously trash a rezzed Hostile Infrastructure and 2 upgrades. Those cards are moved to Archives and become inactive, but Hostile Infrastructure's ability remains active, and 3 instances will become pending, each doing 1 net damage when it resolves. Once all those instances are resolved, Hostile Infrastructure's ability stops being active.
- Example: The Runner plays Test Run to install Nanuq. When their turn ends, Test Run's delayed conditional ability adds Nanuq to the top of the Runner's stack. This meets the trigger condition of Nanuq's first ability, which remains active until it resolves even though Nanuq itself is inactive in the stack. The ability will move Nanuq from the top of the stack to the removed-from-game zone.
- h.linkIf a piece of ice is encountered while it is not installed, its subroutines are active during that encounter.
- Example: The Runner accesses Archangel from HQ, and the Corp uses its ability to force the Runner to encounter it. Archangel's subroutine is active and can resolve during that encounter.
- i.linkPersistent abilities can sometimes remain active after their source card is trashed. See section 9.12.5.
- 9.1.9.linkStatic abilities and lingering effects can make objects gain or lose abilities.
- a.linkIf an object loses an ability, that ability is completely ignored. If the lost ability is a subroutine, it is not considered by any effect that counts subroutines on that object.
- b.linkTo determine the actual abilities present on an object (as well as its other characteristics), follow the procedure described in rule 9.12.1d and rule 9.12.1e.
- c.linkAbilities on an object have no particular order, except for play abilities and subroutines. Play abilities cannot be added to or removed from an event or operation, and their order is the order they appear on their source card. To determine the order of subroutines on an object, refer to section 9.8.2 and section 9.8.3.
- 9.2.1.linkThe active player is the player whose turn it is. The other player is the inactive player.
- 9.2.2.linkA timing structure is a unit of the game in which a prescribed sequence of steps progress the game forward.
- a.linkThe Corp's turn and the Runner's turn are timing structures, as are each of the 3 phases of the turns. See section 5.
- b.linkA run is a timing structure, as are each of the 6 phases of a run. See section 6.
- c.linkBreaching a server is a timing structure. See sections 7.3 and 7.5.
- d.linkAccessing a card is a timing structure. See sections 7.1 and 7.2.
- e.linkOther procedures with prescribed steps, such as installing a card or resolving a trace attempt, are not timing structures.
- 9.2.3.linkPriority is a player's opportunity to act and make certain game choices. No more than one player can have priority at any given time.
- 9.2.4.linkA priority window is a general term for a timing step in which one or both players receive priority. Priority windows open for different purposes throughout the game. When a priority window closes, the game continues to the next timing step.
- a.linkAll priority windows give the player with priority the option to choose a relevant ability they control (if there are any) as the next ability for the game to resolve. This is often referred to as triggering the chosen ability. Some priority windows also give players other options.
- b.linkExcept during action windows, the player with priority has the option to pass in addition to the available options defined by that priority window. When a player passes, the game progresses to the next step, either by giving priority to the other player or by closing the priority window. Each type of priority window defines the method and resolution of passing.
- c.linkUnless otherwise noted, the player with priority receives priority again after resolving one of their available options. That player will continue to receive priority until they pass.
- d.linkWhile a priority window is open, another nested priority window can open as well. This nesting allows the game to resolve "chain reactions," as discussed in rule 9.1.2a. The most recently opened priority window is always resolved before returning to an earlier priority window.
- e.linkWhenever a player receives priority during a priority window, a checkpoint occurs immediately before that player may act. See section 10.3.
- 9.2.5.linkThe types of priority windows are action windows, paid ability windows, reaction windows, interrupt windows, and mid-access ability windows.
- 9.2.6.linkAn action window is a priority window that opens during a player's action phase if they have unspent clicks.
- a.linkAn action window gives only the active player priority.
- b.linkDuring an action window, the active player must take an action. Section 5.2 discusses actions. This type of window does not give the option to pass.
- c.linkAfter the active player takes an action, the action window closes and the game moves to the next timing step. The player does not receive priority again.
- d.linkThere are two timing steps during which an action window may open. The Corp has an action window in step 5.6.2b of their action phase. The Runner has an action window in step 5.7.1f of their action phase.
- 9.2.7.linkA paid ability window is a priority window that opens throughout the game's timing structures to allow players to trigger paid abilities, rez cards, or score agendas.
- a.linkPaid ability windows give both players priority, starting with the active player. When a player passes, the other player receives priority. Players continue to exchange priority until a player who receives priority from their opponent passes without resolving any other option available to them. Once this happens, the paid ability window closes.
- b.linkDuring every paid ability window, the player with priority has the option to trigger an active paid ability they control. Players cannot trigger actions, interrupts, or mid-access abilities in a paid ability window. See section 9.5. Within this document, paid ability windows are marked with the symbol (P) to denote the option to trigger a regular paid ability.
- c.linkDuring some paid ability windows, the Corp has the option to rez an asset or upgrade while they have priority. Within this document, the symbol (R) denotes a paid ability window in which cards can be rezzed. See section 8.1.
- d.linkDuring some paid ability windows, the Corp has the option to score an agenda while they have priority. Within this document, the symbol (S) denotes a paid ability window in which agendas can be scored. See section 1.17.
- e.linkDuring the paid ability window at step 6.9.2b of the Approach Ice Phase of a run, the Corp has the option to rez the piece of ice the Runner is approaching while they have priority.
- f.linkThe player with priority during a paid ability window may use any of the options available to them any number of times in any combination and order until they decide to pass, so long as they are allowed and the player pays any and all costs to use each option. Each option must be fully resolved before another is chosen. A player is not obligated to resolve any of the options available to them, except they must pass.
- g.linkPaid ability windows occur throughout the timing steps of turns and runs. Sections 5.6, 5.7 and 6.9 detail those steps and indicate which options are available in which windows. Section 11 also contains a summarized version of these steps.
- 9.2.8.linkA reaction window is a priority window that opens whenever one or more active conditional abilities become pending by meeting their conditions. Section 9.6 discusses conditional abilities.
- a.linkEach reaction window is associated with the fixed set of conditional abilities that met their conditions just before the window opened. If other abilities become pending during a reaction window, a separate reaction window opens to handle the new abilities. See rule 9.1.2a.
- b.linkReaction windows give both players priority, starting with the active player. When the active player passes, the inactive player receives priority. When the inactive player passes, the reaction window closes.
- c.linkDuring a reaction window, the player with priority has the option to trigger a pending conditional ability they control that is associated with that window.
- d.linkThe player with priority during a reaction window may trigger their pending abilities in any order until they decide to pass; they do not need to trigger mandatory abilities before optional ones. Each ability they trigger must be fully resolved before another is chosen.
- e.linkThe player with priority cannot pass if they control any pending mandatory abilities. They may pass with optional conditional abilities still pending, in which case those abilities lose their pending status without being triggered. Section 9.6.9 describes the differences between mandatory and optional conditional abilities.
- f.linkIf a reaction window opens due to a timing structure beginning, and during that reaction window the timing structure ends (e.g. by an effect moving the game to another timing point past the end of the structure), then the reaction window immediately closes. All remaining abilities associated with the window lose their pending status without being triggered, even if they are mandatory abilities.
- Example: The Runner has a Femme Fatale installed and chose a Tollbooth with its "when installed" ability. When the Runner encounters the Tollbooth, they pay 1[c] to bypass the Tollbooth with Femme Fatale. Because the resolution of Femme Fatale's ability causes the encounter to end, the pending ability from Tollbooth cannot be triggered. The Runner does not pay 3[c], and the run does not end.
- 9.2.9.linkAn interrupt window is a priority window that opens just before an instruction would resolve when one or more players have abilities that could modify that imminent instruction. See section 9.9 for rules about interrupt abilities.
- a.linkEach interrupt window is associated with the single imminent instruction being modified by the abilities triggered during the window, and with a fixed set of conditional ability interrupts determined as the window opens.
- b.linkAs an interrupt window opens, before players receive priority, the expected effects of the imminent instruction are determined, any applicable replacement effects are applied, and then relevant conditional abilities become pending. See section 9.9.4.
- c.linkInterrupt windows give both players priority, starting with the active player. When a player passes, the other player receives priority. Players continue to exchange priority until a player who receives priority from their opponent passes without resolving any other option available to them. Once this happens, the interrupt window closes.
- d.linkDuring an interrupt window, the player with priority has the option to trigger an interrupt ability they control that is relevant to the imminent effect. See section 9.9.3.
- e.linkThe player with priority during an interrupt window may trigger their abilities in any order until they decide to pass. They do not need to trigger mandatory abilities before optional abilities or trigger conditional abilities before paid abilities. Each ability they trigger must be fully resolved before another is chosen.
- f.linkThe player with priority cannot pass if they control any pending mandatory abilities that are still relevant to the imminent effect. They may pass with optional conditional abilities still pending. (Section 9.6.9 describes the differences between mandatory and optional conditional abilities.) Once a player has passed, if they receive priority again, they may continue to trigger paid abilities and pending conditional abilities that are relevant. As the interrupt window closes, any remaining pending conditional abilities lose their pending status.
- 9.2.10.linkA mid-access ability window is a priority window that opens while the Runner is accessing a card.
- a.linkA mid-access ability window gives only the Runner priority.
- b.linkDuring a mid-access ability window, the Runner may use a mid-access ability or may pass. In addition to any mid-access abilities available from cards, the Runner may use the basic trash ability (see section 7.1.5).
- c.linkAfter the Runner uses a mid-access ability or passes, the mid-access ability window closes and the game moves to the next timing step. The Runner does not receive priority again.
- d.linkThe only point at which a mid-access ability window occurs is at step 7.2.2 of accessing a card.
- 9.3.1.linkText is classified into conditions, restrictions, instructions, declarations, and ability flags. The rules text of an ability can contain text in any combination of these classes, except that no ability contains both instructions and declarations.
- 9.3.2.linkA condition is a unit of text that stipulates a requirement for when an ability's effects are allowed to apply.
- a.linkA cost condition describes a cost (either a nested cost or a trigger cost) that a player must pay to apply an effect. Costs are discussed in detail in section 1.16.
- b.linkA trigger condition describes a change in game state that must occur for an effect to apply. Trigger conditions often begin with words such as "if", "when", "whenever", or "after", or with ordinal phrases such as "the first time".
- c.linkA static condition describes a property of the game state that must be true for an effect to apply. Static conditions often begin with words such as "if", "during", or "while".
- 9.3.3.linkA restriction is a unit of text that applies one of a specific set of constraints for a card to be played or an ability to be used. If a restriction appears in an ability, it applies to the entire ability regardless of whether it is written before, after, or in the middle of the ability's other text. Many restrictions fall under section 9.1.8, meaning they are active even while their source is inactive.
- a.linkText modifying the cost to play, install, rez, or steal the card it appears on is a restriction, including text that adds an additional cost.
- b.linkConstraints on when or where a card can be installed, rezzed, played, or scored are restrictions.
- c.linkLimits on when, where, or how often an ability can be used are restrictions.
- d.linkConstraints on how a cost can be paid are restrictions.
- e.linkIf a card's text limits what cards it can host, the text describing that limit is a restriction. See also rule 1.13.5b.
- f.linkDefinitions for or constraints on a variable are restrictions.
- Example: Some abilities dictate a value for X, such as "X is the number of rezzed NEXT ice." Some abilities with X in their cost constrain the value that can be chosen for X, such as "X must be equal to or less than the number of tags the Runner has." These statements are restrictions.
- g.linkStipulations that an effect or part of an effect cannot be prevented are restrictions.
- h.linkAny text not falling under one of the above categories is not a restriction.
- 9.3.4.linkAn instruction is a statement or command that is resolved at a specific time and applies immediate effects to the game state. (This can include creating new lingering abilities or effects that will continue to apply over time; see section 9.10.)
- a.linkInstructions can originate from a game rule or from the text of an ability. An instruction in an ability resolves when that ability resolves (see section 9.1.2). An instruction in the game rules resolves during the timing step(s) when it appears. Section 9.11 explains how to determine the boundaries between consecutive instructions.
- b.linkIf an instruction requires any targets, players announce those targets before that instruction becomes imminent. See section 1.15.
- c.linkEach instruction is carried out as an atomic unit and cannot be interrupted once it begins to resolve. The procedure for carrying out an instruction can be altered by other effects such as interrupts, but only before the instruction begins to resolve. See section 9.9.
- d.linkOther than choosing targets, carry out the steps of a single instruction in the order they are written.
- e.linkInstructions in an ability can create effects that last beyond the resolution of the ability. See section 9.10.
- 9.3.5.linkA declaration is a statement describing an effect on components or game rules that is applied continuously. A declaration applies its effects as long as it is active.
- 9.3.6.linkAn ability flag is a keyword or symbol that appears at the beginning of an ability. Ability flags are separated from the main text of the ability by an arrow (→). Each ability flag changes the rules for how the flagged ability functions.
- a.linkThere are five ability flags: access, interface, [interrupt], persistent, and threat N.
- b.linkThe "access" flag appears on Runner card paid abilities and affects the timing for triggering those abilities. The Runner can use abilities with this flag only during the mid-access ability window at step 7.2.2 of accessing a card. See section 9.2.10.
- c.linkThe "interface" flag appears on icebreaker paid abilities and affects the timing for triggering those abilities. The Runner can use abilities with this flag only during an encounter, and only if the ability's source is an icebreaker with strength that equals or exceeds the strength of the encountered ice. See section 3.9.5.
- d.linkThe interrupt flag ([interrupt]) appears on paid and conditional abilities and affects the timing for triggering those abilities. Players can use abilities with this flag only during interrupt windows, and only if the ability is relevant to the imminent instruction. See section 9.9.
- e.linkThe "persistent" flag appears on Corp card abilities and changes the rules about when those abilities are active. An ability with this flag can persist until the end of the run after its source card is trashed. See section 9.12.5.
- f.linkThe "threat N" flag can appear on any type of ability. Abilities with this flag are only active if the threat level is greater than or equal to N, regardless of section 9.1.8. See rule 1.17.1a.
- 9.3.7.linkThe five types of abilities can be identified by the types of text they are made of.
- a.linkStatic abilities (section 9.4) can contain declarations, restrictions, and conditions, but never instructions. Static abilities are the only ability type that can contain declarations.
- b.linkPaid abilities (section 9.5) can always be identified by their formatting: a cost condition in bold text, a colon (:), then the remainder of the ability. The text after the colon can contain conditions, restrictions, and/or instructions.
- c.linkConditional abilities (section 9.6) always contain a trigger condition or static condition and at least one instruction. They can also contain restrictions, other instructions, or nested conditions. The primary condition is often written with a timing-related word or phrase like "when", "after", "the first time", and so on, and is usually the first part of the ability's text. Some older cards write the condition at the end of the ability or use "if" to indicate the condition.
- d.linkPlay abilities (section 9.7) are the abilities on events and operations that are not paid, conditional, or static abilities. They can contain conditions, restrictions, and/or instructions.
- e.linkSubroutines (section 9.8) always begin with the [sub] symbol, and can contain conditions, restrictions, and/or instructions.
- 9.4.1.linkA static ability is an ability that continuously affects the game as long as it is active. Static abilities are the only type of ability that can contain declarations, and they do not resolve or have associated priority windows.
- 9.4.2.linkIf a static ability contains a static condition, then the constrained parts of the ability apply to the game state only if that condition is met.
- 9.4.3.linkStatic abilities can include restrictions that apply to their source card. These restrictions are often active even while the card is inactive. See section 9.1.8.
- 9.4.4.linkThe effects of static abilities do not have durations and cannot directly create lingering effects (see section 9.10).
- Example: The runner controls Puffer with a hosted Gebrselassie. Gebrselassie changes the durations of abilities affecting its host's strength, so if the Runner uses Puffer's paid ability to give it +1 strength, that increase will last for the remainder of the turn. Gebrselassie does not affect Puffer's static ability that increases its strength for each hosted power counter, so if the Runner spends [click] to remove a power counter, then the increase in strength from Puffer's static ability will immediately be lost.
- 9.4.5.linkStatic abilities that modify a value maintain the same restrictions and specifications that were present on the original value.
- Example: The Cleaners has a static ability that gives every instance of meat damage done by the Corp +1 to the amount of the damage. Part of Flare's effect does 2 meat damage that can't be prevented. If this effect resolves while The Cleaners is active, then all 3 points of meat damage are unpreventable.
- 9.5.1.linkA paid ability is an ability players trigger at-will, during appropriate priority windows. In order to use a paid ability, the controller of that ability must pay its trigger cost. Paid abilities are always written with the trigger cost first, followed by a colon (:), followed by the remainder of the ability's text.
- 9.5.2.linkA player can trigger paid abilities they control while they have priority in an appropriate priority window.
- a.linkIf the trigger cost of a paid ability begins with a [click] symbol, the ability is an action. A player can use one action paid ability during each action window on their turn. See section 9.2.6 and section 5.2.
- b.linkIf the [interrupt] flag appears before a paid ability's trigger cost, that ability is an interrupt. A player can use interrupt paid abilities during appropriate interrupt windows. Each such ability can be used as many times as its effects could apply to the imminent instruction. See section 9.9.
- c.linkIf the "access" flag appears before a paid ability's trigger cost, that ability is a mid-access ability. The Runner can use up to 1 mid-access ability during the mid-access ability window at step 7.2.2 of accessing a card.
- d.linkIf the "interface" flag appears before a paid ability's trigger cost, that ability is an Interface ability and is subject to the restrictions of icebreakers discussed in section 3.9.5. Interface abilities do not have a special priority window type.
- e.linkA paid ability that is not an action, interrupt, or mid-access ability can be used during a paid ability window. Each such ability can be used an unlimited number of times as long as its cost is paid each time and any restrictions specified by its effect are observed.
- 9.5.3.linkPaid abilities are always optional. A paid ability and its source are considered used when the ability's trigger cost is paid.
- a.linkMid-access abilities the Runner is forced to trigger still count as optional abilities. See also rule 7.1.5c and rule 7.1.5d.
- Example: The Corp resolves the subroutine on Wendigo, prohibiting the Runner from using their installed Imp for the remainder of the run. Later, the Runner accesses an installed Mumbad Virtual Tour. Even though Mumbad Virtual Tour forces the Runner to trash it if able, Imp's ability is still optional for purposes of Wendigo's prohibition. Since Imp's ability cannot be used at all this run, Mumbad Virtual Tour cannot compel the Runner to spend one of its hosted virus counters. If the Runner can pay the cost of another mid-access ability, such as the basic trash ability, the Runner must use that ability. If not, the Runner will not be able to trash Mumbad Virtual Tour at all.
- 9.5.4.linkOnce a player pays the trigger cost of a paid ability, that ability becomes independent of its source and rule 9.1.4 applies to it.
- 9.5.5.linkIf the trigger cost of a paid ability uninstalls or forfeits the source of that paid ability, and the effects of that paid ability refer to or act on cards or counters hosted on that source, set aside any hosted cards and counters as the trigger cost is paid. The set-aside cards or counters are still considered "hosted" for purposes of this ability, but they are not trashed due to not having a host for as long as the ability is resolving. When the ability finishes resolving, if any of those cards or counters are still set aside, they are trashed during step 10.3.1f or step 10.3.1g of the next checkpoint, as appropriate. Other abilities cannot interact with these cards or counters while they are set aside (see rule 4.8.3).
- Example: The Runner has Fermenter installed with 4 hosted virus counters. They use its paid ability, which has a cost that includes trashing Fermenter. As the Runner pays this cost, they set aside the 4 counters. When the ability resolves and refers to the number of hosted virus counters, it includes the counters that were set aside, so the Runner gains 8 credits. When the ability is finished resolving, the counters are returned to the bank.
- Example: The Runner uses the [trash] ability on Street Peddler. They pay the trigger cost and set the 3 hosted cards aside. When the ability resolves, the Runner installs one of the set-aside cards. Since the other two cards are still set aside, the next checkpoint trashes them just as in any other case of cards that were hosted on a card that is no longer installed. No other abilities are able to tell that the cards were set aside: they are treated as having been installed or trashed from their previous location in the play area.
- Example: This example describes a situation similar to the previous examples, but covers the sequence of steps the game carries out in a higher level of detail. The Corp has priority in a paid ability window, and chooses to trigger the [trash] ability on Reconstruction Contract. As they pay the trigger cost, moving Reconstruction Contract to Archives, they set aside the advancement counters hosted on Reconstruction Contract. Next, a checkpoint occurs following the cost having been paid. After that checkpoint and any corresponding reaction window, the [trash] ability's instruction is ready to become imminent. The Corp chooses a card they can advance to be the instruction's target, and an interrupt window opens. After the interrupt window (assuming the effects of the instruction are not prevented), the Corp moves the set-aside counters to the target card.
- 9.5.6.linkSteps of Using a Paid Ability
- a.linkAnnounce the intent to trigger the paid ability.
- b.linkPay the trigger cost. The ability and its source are considered used. "When used" abilities meet their trigger conditions. (The cost-paid checkpoint then occurs.)
- c.linkAnnounce any targets for the ability's first instruction. That instruction then becomes imminent.
- d.linkAn interrupt window occurs, during which abilities can modify, prevent, or avoid the imminent effects.
- e.linkResolve the instruction, applying any changes to its effects from interrupts that were resolved.
- f.linkA checkpoint occurs.
- g.linkIf there are more instructions to resolve, announce any targets for the next instruction. That instruction then becomes imminent. Return to (d).
- h.linkResolution of the paid ability is complete.
- 9.6.1.linkA conditional ability is an ability that a player can or must trigger at a specific point in the game. Conditional abilities always include a primary condition and one or more instructions, but they have no special syntax requirements.
- a.linkThe primary condition of a conditional ability is usually a trigger condition, but can also be a static condition.
- b.linkThe primary condition of a conditional ability is often, but not always, written at the front of the ability. See rule 9.3.7c for details about conditional ability syntax.
- 9.6.2.linkWhen a conditional ability has met its condition, one or more instances of that conditional ability is created pending in the next reaction window that opens. Each instance of a conditional ability is a separate copy of that ability that resolves independently of the others. An instance of an ability with the pending status is waiting for its controller to trigger it.
- 9.6.3.linkA conditional ability with a static condition can only have one instance at a time.
- 9.6.4.linkA conditional ability with a trigger condition can have multiple instances.
- a.linkIf a trigger condition is met again while an instance of the corresponding ability is already pending, imminent, or resolving, a new instance can still become pending in the next reaction window.
- b.linkIf the trigger condition of an ability is met more than once between consecutive checkpoints, multiple instances of that ability become pending in the next reaction window.
- Example: The Runner plays Singularity, trashing 3 Corp cards simultaneously. Since Hostile Infrastructure's trigger condition is met separately for each card trashed, the next checkpoint handles all of those occurrences, and 3 instances of the ability become pending in the same reaction window.
- Example: The Runner controls Blackguard and plays Satellite Uplink, exposing 2 cards in a single instruction. In the next checkpoint, two instances of Blackguard's ability become pending, one corresponding to each card that was exposed.
- 9.6.5.linkThe trigger condition of most conditional abilities describes an occurrence that allows it to become pending. These rules about trigger conditions also apply to conditional abilities with static conditions, except as described in section 9.6.7.
- a.linkDuring each checkpoint, the game checks whether any conditional abilities have met their trigger conditions. If any have, a reaction window opens to resolve those abilities (See section 10.3). This reaction window is fully resolved and closed before the game proceeds to the next instruction of the original effect or game rule.
- b.linkA conditional ability can only recognize its trigger condition occurring if the ability is active at the time the trigger condition resolves. If a conditional ability becomes active after the point when its trigger condition was met, that ability does not become pending, even if other abilities sharing that trigger condition are still pending.
- c.linkA conditional ability can only recognize its trigger condition occurring if all the stipulations and requirements listed in the trigger condition are met at the moment that the trigger condition would occur.
- Example: The entire trigger condition on Quantum Predictive Model is "If the Runner is tagged when Quantum Predictive Model is accessed". Quantum Predictive Model can only meet its trigger condition if the Runner is tagged at the time the access occurs. Even if Casting Call is hosted on Quantum Predictive Model, the tag will be given after the access begins, and no ordering of the abilities will allow Quantum Predictive Model to meet its trigger condition.
- d.linkAdditional stipulations and requirements listed in the instructions of a conditional ability are checked as part of the ability's effects and are not part of the ability's trigger condition. For the effects under the scope of this kind of condition to resolve, the condition only needs to be met when the relevant instructions resolve. This can occur even if some or all of those conditions were not met at the time the ability met its trigger condition.
- Example: If a Runner with 1 link has both Underworld Contact installed and The Supplier installed hosting a Dyson Mem Chip, both Underworld Contact and The Supplier meet their trigger conditions at the same time. The Runner can trigger The Supplier first, installing the Dyson Mem Chip, thus allowing Underworld Contact to recognize that the Runner has 2 link and give them 1 credit, even though the Runner did not have 2 link at the time the Underworld Contact became pending.
- e.linkThe phrase "If successful" in reference to a run is a trigger condition with specific rules. See section 6.7.4. The phrases "If successful" and "If unsuccessful" are also frequently used as trigger conditions relating to the results of a trace. See section 10.8.
- 9.6.6.linkTrigger conditions look for an instantaneous change in the game state. The next checkpoint after that change takes place marks an instance of the ability as pending for each occurrence of the change that was looked for.
- a.linkSome conditional abilities refer to the game state before the trigger condition was met, using the word "had". The previous game state referred to is the game state at the time of step 10.3.1a of the checkpoint immediately preceding the checkpoint in which the ability became pending.
- Example: The ability of Weyland Consortium: Built to Last only causes the Corp to gain 2c when they advance a card that "had no advancement counters". This ability becomes pending immediately after an instruction resolves in which the Corp advances a card, and the requirement is checked against the state of the game at the previous checkpoint, before that advancement took place.
- 9.6.7.linkConditional abilities with a static condition instead of a trigger condition describe an effect that must be performed repeatedly, if possible, while the condition is true. Such abilities usually attempt to end their own repetition by uninstalling their source.
- a.linkDuring each checkpoint, the game checks whether any conditional abilities with static conditions should become pending, alongside conditional abilities with trigger conditions. However, there are further requirements for this kind of ability to be marked pending.
- b.linkA conditional ability with a static condition can only be marked pending during a checkpoint if the condition is true at the beginning of that checkpoint.
- c.linkA conditional ability with a static condition can only be marked pending if no other instance of the same ability from the same source is already pending, imminent, or resolving.
- d.linkA conditional ability with a static condition can only be marked pending if the instructions in the ability have the potential to change the game state.
- Example: Parasite is hosted on a piece of ice with 0 strength. Parasite's ability tries to trash that ice. If the effect of an interrupt ability prevents the ice from being trashed without increasing its strength, the condition is still true, so the ability will become pending again. But this does not occur while the previous instance of the ability is still pending or resolving. Conversely, if a static ability (such as the one on Architect) prohibits Parasite from trashing the ice, Parasite's ability does not have the potential to change the game state, and therefore it does not become pending.
- 9.6.8.linkA player can trigger a conditional ability while they have priority in a reaction window in which the ability is pending.
- a.linkOnce a player triggers a conditional ability, that instance of the ability loses its pending status. Other pending instances of the ability are unaffected and can still be triggered later, regardless of whether those instances are associated with the same reaction window.
- b.linkIf the [interrupt] symbol appears before a conditional ability's text, that ability is an interrupt. These abilities will become pending in interrupt windows rather than reaction windows, but are otherwise resolved in the same way as non-interrupt conditional abilities. See section 9.9.
- 9.6.9.linkIf a conditional ability gives its controller a choice of whether to apply its effects, such that the ability could potentially have no effects at all, it is considered an optional conditional ability. These abilities can usually be recognized by the presence of permissive words such as "may" or "allows", or by a restriction such as "Use this ability only once per turn." If the ability is not optional, then it is a mandatory conditional ability.
- a.linkInstances of optional conditional abilities can still be pending when their controller passes in the corresponding priority window. Players are not required to trigger optional conditional abilities.
- b.linkPlayers must trigger all instances of pending mandatory conditional abilities they control in a given priority window before they can pass in that window. See section 9.2.8.
- c.linkBoth optional and mandatory conditional abilities may have optional parts to their effects. Even if triggering the ability is mandatory, its controller may still decline any optional constituent effects that arise during its resolution.
- d.linkA conditional ability and its source are considered used when any optional component of the ability's effects is carried out.
- 9.6.10.linkIf any instances of a conditional ability are pending and the conditional ability itself becomes inactive, those instances lose their pending status and will not resolve.
- Example: The Runner has both Aesop's Pawnshop and Drug Dealer installed. Both cards have abilities that meet their trigger conditions when the Runner's turn begins. If the Runner chooses to trigger Aesop's Pawnshop first, and then uses it to trash Drug Dealer, Drug Dealer's pending ability can never be triggered, so the Runner does not lose a credit.
- 9.6.11.linkIf a priority window closes while any abilities still have pending instances associated with that window, the remaining instances lose their pending status and cannot be triggered or resolved. See rule 9.2.8f.
- 9.6.12.linkOnce a player triggers a conditional ability and its instructions become imminent, the ability becomes independent of its source and rule 9.1.4 applies to it.
- 9.6.13.linkA delayed conditional ability is a conditional ability maintained by a lingering effect (see section 9.10). Unlike other lingering effects, some delayed conditional abilities are created without an explicitly stated duration.
- a.linkIf an "if successful" ability contains a nested delayed conditional ability referring to breaching the attacked server, that ability applies to the breach at step 6.9.5b of the run the "if successful" ability is associated with. Its duration expires at the end of the run. See rule 6.7.4b.
- b.linkIf an instruction creates a delayed conditional ability and specifies a duration, the delayed conditional ability is active until that duration expires.
- Example: In the Groove creates a delayed conditional ability that specifies a duration of "this turn". Since a duration is specified, it is not limited to only being triggered once. The ability becomes pending and can resolve every time its trigger condition is met, and its existence only expires at the end of the turn.
- c.linkAny other delayed conditional ability exists until the next time it resolves, after which it expires.
- Example: Joshua B's ability allows the Runner to gain [click]. If they do, it creates a delayed conditional ability that is independent of Joshua B itself, which will meet its trigger condition only once, when that turn ends. After that ability resolves, the game no longer maintains the lingering effect creating the ability.
- 9.6.14.linkSome cards refer to a class of conditional abilities according to their trigger condition.
- a.linkA "when encountered" ability is any ability that could meet its trigger condition at step 6.9.3a of an encounter with its source.
- b.linkA "when installed" ability is any ability that could meet its trigger condition at step 8.5.15f of the process of installing its source.
- c.linkA "when scored" ability is any ability on an agenda that could meet its trigger condition as a result of the Corp choosing the option to score that agenda during a paid ability window (see rule 9.2.7d).
- d.linkIf an effect attempts to resolve a conditional ability according to one of the classes identified in section 9.6.14, the ability is marked pending as though the stipulation of that class had occurred. Any additional requirements of the trigger condition in question must still be met by the game state.
- Example: The Corp has scored AstroScript Pilot Program and Market Research. They forfeit one of those agendas to play 24/7 News Cycle and resolve the "when scored" ability of the other agenda, even though neither agenda was actually scored at this time. The Corp can forfeit Market Research to resolve AstroScript Pilot Program's ability and put an agenda counter on it, with no other stipulations. If the Runner is tagged, the Corp could instead forfeit AstroScript Pilot Program to put an agenda counter on Market Research. However, if the Runner is not tagged, the additional requirement of Market Research's trigger condition will not be met, so its "when scored" ability cannot become pending or resolve.
- 9.6.15.linkSteps of Triggering and Resolving a Conditional Ability
- a.linkAnnounce that you will trigger one of the pending abilities associated with the reaction window that gave you priority.
- b.linkAnnounce any targets for the ability's first instruction. That instruction then becomes imminent.
- c.linkAn interrupt window occurs, during which abilities can modify, prevent, or avoid the imminent effects.
- d.linkResolve the instruction, applying any changes to its effects from interrupts that were resolved. If the controller of the ability chooses to resolve an optional effect contained in this instruction, and this is the first instruction for which that player has done so, "when used" conditionals meet their trigger conditions.
- e.linkA checkpoint occurs.
- f.linkIf there are more instructions to resolve, announce any targets for the next instruction. That instruction then becomes imminent. Return to (c).
- g.linkResolution of the conditional ability is complete.
- 9.7.1.linkAny ability on an event or operation that is not a paid, conditional, or static ability is a play ability. Play abilities are the abilities that resolve as part of playing that event or operation during step 8.6.6f.
- Example: The operation card Hyoubu Precog Manifold has several abilities of different types. The first sentence reads "Play only if there is no active lockdown." This is a static ability that contains a restriction and no declarations. The second sentence ("This operation is not trashed until your next turn begins.") is a play ability that has no immediate impact on the game state but creates a lingering effect that alters how the operation will leave the play area after resolving. The second paragraph reads simply, "Choose a server." This play ability instruction is the main part of the card that actively affects the game state while the operation resolves. Finally, the third paragraph is a single conditional ability with multiple instructions that is active as long as the operation remains in the play area.
- 9.7.2.linkSteps of Resolving a Play Ability
- a.linkAnnounce any targets for the ability's first instruction. That instruction then becomes imminent.
- b.linkAn interrupt window occurs, during which abilities can modify, prevent, or avoid the imminent effects.
- c.linkResolve the instruction, applying any changes to its effects from interrupts that were resolved.
- d.linkA checkpoint occurs.
- e.linkIf there are more instructions to resolve, announce any targets for the next instruction. That instruction then becomes imminent. Return to (b).
- f.linkResolution of the play ability is complete.
- 9.8.1.linkA subroutine is an ability beginning with the [sub] symbol. Only ice can have subroutines.
- 9.8.2.linkSubroutines always have a specified order.
- a.linkThe order of the subroutines printed on a piece of ice is the order in which they appear on that ice.
- b.linkUnless otherwise specified, subroutines a piece of ice gains from an ability are added after all other subroutines the ice has at the time that ability begins to apply to that ice.
- Example: The Runner encounters Marker, and its subroutine resolves. The next ice the Runner encounters is Brainstorm. When the encounter begins, the lingering effect from Marker gives Brainstorm an "[sub] End the run." subroutine. Then, Brainstorm's conditional ability resolves, giving it the appropriate number of "[sub] Do 1 core damage." subroutines. The "[sub] Do 1 core damage." subroutines are all ordered after the "[sub] End the run." subroutine.
- c.linkIf multiple subroutines are added to a piece of ice at the same time in an unspecified order, the Corp declares the relative order of those subroutines at the time the ice gains them.
- 9.8.3.linkSome ice have static abilities that grant that piece of ice a variable number of subroutines. Subroutines from such an ability are always ordered before any other subroutines on that ice.
- a.linkIf the number of subroutines granted to a piece of ice by its own static ability increases, the additional subroutines are added immediately after the previously-existing subroutines from the same ability.
- Example: The Corp has no bad publicity and controls a rezzed copy of Ireress hosting a condition counter from Sub Boost. If the Corp takes bad publicity, the corresponding subroutines from Ireress's ability are added before the "[sub] End the run." from the condition counter.
- Example: The Corp has 3 cards in HQ while the Runner is encountering Ashigaru. After the Runner breaks Ashigaru's 3 subroutines, the Corp uses Panic Button to draw another card. The new subroutine is added after the previous 3, so the Runner can use Gbahali to break it.
- b.linkIf the number of subroutines granted to a piece of ice by its own static ability decreases, subroutines are lost beginning with the last subroutine the ice previously had from the same ability and working backwards.
- Example: The Corp has 3 cards in HQ while the Runner is encountering Ashigaru. The Runner breaks the first subroutine, then uses Utopia Shard to force the Corp to discard 2 cards. Ashigaru correspondingly loses its last 2 subroutines, leaving behind the subroutine that was already broken.
- 9.8.4.linkOne card, Hive, has a static ability that removes its own printed subroutines. Subroutines are lost to this ability beginning with the last printed subroutine and working backwards.
- 9.8.5.linkFor each encounter, the subroutines on the encountered ice have a status of broken or unbroken with respect to that encounter.
- a.linkWhen an encounter begins, each of the encountered ice's subroutines becomes unbroken with respect to that encounter.
- b.linkWhen a piece of ice gains 1 or more new subroutines during an encounter with it, those subroutines come into existence unbroken with respect to that encounter.
- c.linkWhen an encounter ends, card abilities can still check whether subroutines were broken or unbroken during that encounter.
- 9.8.6.linkTo break a subroutine is to change its status with respect to the active encounter from unbroken to broken. Many cards that can allow a player to break subroutines are icebreakers (see section 3.9.5). If the Runner breaks all the subroutines on the encountered ice, they fully break that ice (see section 6.5.7).
- 9.8.7.linkOnly unbroken subroutines can be chosen as targets for abilities that would break them.
- a.linkAn ability that breaks "all subroutines" does not target any subroutines, and can be used as long as the encountered ice has at least 1 unbroken subroutine.
- b.linkOne card, Grappling Hook, has the ability to break "all but 1 subroutine" on the encountered ice. To trigger this ability, its controller chooses as its target the 1 subroutine that will not be broken. When the ability resolves, it breaks all unbroken subroutines except the chosen subroutine.
- Example: The Runner uses two copies of Grappling Hook to break all of the subroutines on Heimdall 1.0. For the first Grappling Hook, the Runner chooses the unbroken "[sub] Do 1 core damage." subroutine as the target, and Grappling Hook breaks both "[sub] End the run." subroutines. For the second Grappling Hook, the Runner chooses one of the already-broken "[sub] End the run." subroutines as the target. They can choose the broken subroutine as Grappling Hook's target because Grappling Hook will not attempt to break the chosen subroutine. When the ability resolves, Grappling Hook breaks the "[sub] Do 1 core damage." subroutine, but does nothing to the other "[sub] End the run." subroutine, because it is already broken.
- 9.8.8.linkAt step 6.9.3c of an encounter, the Corp resolves subroutines that are unbroken with respect to that encounter.
- a.linkResolving subroutines is mandatory and does not open a priority window.
- b.linkThe Corp resolves the unbroken subroutines 1 at a time in order. The order of subroutines is discussed in section 9.8.2.
- c.linkIf the encounter ends during this process, no more subroutines are resolved.
- Example: The Runner encounters Little Engine and does not break any subroutines. Little Engine's first subroutine resolves and ends the run. Since the run and therefore the encounter have ended, no more subroutines resolve. The Runner will not gain 5[c].
- d.linkOne card, Street Magic, allows the Runner to set the order in which subroutines are resolved. If this ability is active when step 6.9.3c is reached for the first time in an encounter, the Runner declares an order for the unbroken subroutines, and the Corp must resolve them in this order instead of their normal order. The new order is determined before any subroutines are resolved.
- 9.8.9.linkOnce a subroutine's first instruction becomes imminent, the subroutine becomes independent of its source and rule 9.1.4 applies to it.
- 9.8.10.linkOne card, Tsakhia "Bankhar" Gantulga, can apply a replacement effect while a subroutine is imminent in order to resolve a different subroutine instead. The replaced subroutine is treated as having the same source as the original imminent subroutine.
- Example: The Runner encounters Bloop while Tsakhia "Bankhar" Gantulga's replacement effect applies. All 3 of Bloop's subroutines would resolve, but are replaced by "[sub] Do 1 net damage." by the replacement effect. These subroutines count as resolving from Bloop, so when the Runner passes Bloop after the encounter, the Runner can use Persephone to trash the top card of their stack and the top 3 cards of R&D.
- 9.8.11.linkSteps of Resolving a Subroutine
- a.linkThe subroutine itself becomes imminent.
- b.linkAn interrupt window occurs, during which abilities can prevent the subroutine from resolving. If this happens, the remaining steps are not carried out.
- c.linkAnnounce any targets for the subroutine's first instruction. That instruction then becomes imminent.
- d.linkAn interrupt window occurs, during which abilities can modify, prevent, or avoid the imminent effects.
- e.linkResolve the instruction, applying any changes to its effects from interrupts that were resolved.
- f.linkA checkpoint occurs.
- g.linkIf there are more instructions to resolve, announce any targets for the next instruction. That instruction then becomes imminent. Return to (d).
- h.linkResolution of the subroutine is complete.
- 9.9.1.linkAn interrupt is an ability that modifies either the effects of another instruction or the context in which that instruction will be resolved. Interrupts can be written in the form of a paid ability or a conditional ability.
- a.linkInterrupt abilities are denoted by the [interrupt] symbol appearing at the beginning of the ability, or by certain keywords in the ability's text.
- b.linkAny paid or conditional ability that uses the word "prevent", "avoid", or "would" is an interrupt ability.
- 9.9.2.linkThe expected effects of an imminent instruction are the effects described by the instruction's text, modified by any static abilities that affect it and any replacement effects or interrupt effects that have been applied. The expected effects of an instruction are continually updated throughout the interrupt window.
- Example: The Runner plays Process Automation and the instruction "Gain 2[c] and draw 1 card." becomes imminent. The expected effects of this instruction are that the Runner will gain 2[c] and draw 1 card.
- Example: The Runner plays Process Automation after Lockdown's subroutine resolves. The instruction "Gain 2[c] and draw 1 card." becomes imminent, but the Runner cannot draw cards. The expected effect of this instruction is that the Runner will gain 2[c].
- a.linkWhen an instruction resolves, its expected effects correspond to the effects that occur, except for situations where rule 9.9.7d applies.
- 9.9.3.linkIn order to trigger an interrupt, it must be relevant to an imminent instruction. An interrupt is relevant to an instruction if at least one of the following is true:
- a.linkIts effects could prevent or avoid part or all of the imminent instruction's expected effects. See section 9.9.5.
- b.linkIts effects could modify a value associated with the imminent instruction's expected effects. See section 9.9.6 and section 9.9.7.
- c.linkIts effects could create a replacement effect that applies to the imminent instruction's expected effects. See rule 9.9.10.
- d.linkIt has a trigger condition using the word "would" that is met by the imminent instruction's expected effects.
- Example: The trigger condition on The Class Act's second ability is "The first time each turn you would draw any number of cards". Even though this ability's effects do not directly modify the imminent instruction's effects, the ability is relevant to an instruction that is expected to draw cards.
- 9.9.4.linkWhenever an instruction becomes imminent, an interrupt window opens to allow players to modify the effects of that instruction. Section 9.2.9 contains the rules for handling priority during interrupt windows.
- a.linkAs the window opens, the initial expected effects of the instruction are determined, then any active replacement effects that replace all or part of the expected effects are applied. If multiple replacement effects could apply, the order in which they are applied follows the rules in section 9.9.11.
- b.linkAfter replacement effects have been applied, but before players receive priority, active conditional ability interrupts that are relevant to the imminent instruction are marked pending and are associated with the window. If a conditional ability interrupt becomes active after the interrupt window opens, it does not become pending.
- c.linkWhile a player has priority in an interrupt window, they can trigger a conditional ability interrupt they control only if it is pending in that window and still relevant to the imminent instruction.
- Example: An instruction is imminent that would trash an installed copy of Harbinger. The Runner uses Sacrificial Construct to prevent Harbinger from being trashed. The Runner can no longer trigger Harbinger's interrupt ability, even though it is still pending, because the expected effects of the instruction no longer include Harbinger being trashed and therefore the ability is no longer relevant.
- Example: An instruction is imminent that would give the Runner 2 tags. The Runner trashes Decoy to use its ability to avoid 1 of the tags, which meets the trigger condition for Thunder Art Gallery's ability. The latter resolves as a chain reaction (see rule 9.1.2a) while the interrupt window is still open, allowing the Runner to install No One Home, which has a conditional ability interrupt that is relevant since the instruction is still expected to give the Runner 1 tag. However, No One Home was not active when the interrupt window opened, so its ability is not pending and cannot be triggered.
- d.linkWhile a player has priority in an interrupt window, they can use a paid ability interrupt that is relevant to the imminent instruction. The ability does not have to have been active when the interrupt window opened, nor does a paid ability window need to be open at this time.
- Example: An instruction is imminent that would give the Runner 2 tags. The Runner trashes Decoy to use its ability to avoid 1 of the tags, which meets the trigger condition for Thunder Art Gallery's ability. The latter resolves as a chain reaction (see rule 9.1.2a) while the interrupt window is still open, allowing the Runner to install another copy of Decoy. The Runner receives priority again in the original interrupt window and uses the second Decoy's ability to avoid the other imminent tag.
- 9.9.5.linkTo prevent or avoid an effect is to stop that effect from happening. The terms "prevent" and "avoid" are synonymous.
- a.linkSome abilities look for an ordinal instance of an effect that "would" take place within a specified time period. These abilities look for the appropriate number of times that effect becomes imminent, not whether the effect actually resolves. Preventing or replacing an effect does not allow these abilities to meet their trigger conditions again in the same time period.
- Example: Tori Hanzō's interrupt can only be used "the first time you would do net damage" during a run. If the first net damage that becomes imminent is prevented by the Runner using Feedback Filter, Tori Hanzō cannot be used on any other instances of net damage for the remainder of the run, as the next imminent net damage is the second time the Corp "would" deal net damage, not the first time.
- b.linkAbilities that do not use "would" do not see effects that are prevented, as those effects did not occur.
- c.linkA static ability can stipulate that a particular effect is always prevented. This kind of prevention effect does not require a player to explicitly trigger it.
- Example: Paparazzi reads in part, "Prevent all meat damage." This is a static ability that applies automatically to any instruction that would deal meat damage.
- 9.9.6.linkSome instructions make use of an associated value. These values can be changed by interrupts and replacement effects.
- a.linkA number of tags the Runner would take from an effect is a value. Avoiding a number of those tags decreases that value. The value for a number of tags the Runner takes must be greater than 0 for the effect giving tags to occur.
- b.linkAn amount of damage the Runner would take from an effect is a value. Preventing an amount of that damage decreases that value. The value for an amount of damage the Runner takes must be greater than 0 for the damage effect to occur.
- c.linkA cost that would be paid while resolving an effect is a value. Rule 1.16.2a applies to the final value at the time the cost is paid. See also rule 1.16.1d.
- Example: Patchwork's interrupt modifies a play cost or install cost, so it is relevant to any instruction where a card will be played or installed and the corresponding cost paid.
- d.linkThe base trace strength of a trace attempt is a value. See section 10.8 for rules about trace attempts. A base trace strength value does not need to be greater than 0 for the trace attempt to occur.
- 9.9.7.linkValues associated with an imminent instruction are calculated continuously as part of the instruction's expected effects.
- a.linkWhile an instruction is imminent, values associated with that instruction can be reduced below 0. Values 0 or lower can still be modified by other interrupt abilities while the instruction remains imminent.
- Example: The Runner takes a tag on their turn, allowing the Corp to trigger Mr. Stone. While the 1 meat damage from Mr. Stone's ability is imminent, both players can trigger interrupts to modify the damage effect. Since it is the Runner's turn, they receive priority first and use Biometric Spoofing to prevent 2 damage. The imminent effect is now expected to do -1 damage. When the Corp receives priority, they trigger two copies of The Cleaners that each add 1 to the expected damage, increasing the total to 0 and then to 1. The ability will resolve with 1 damage even though the amount of damage was temporarily 0 or less while the effect was imminent.
- b.linkIf an effect prevents "all damage" or "any amount of damage" while an instruction is imminent, the damage is removed from the expected effects entirely, and there is no longer a value to be modified. If an effect avoids "all tags" or "any number of tags" while an instruction is imminent, taking tags is removed from the expected effects entirely, and there is no longer a value to be modified.
- c.linkOne card, Bio-Modeled Network, has an instruction that prevents "all but 1 net damage." This ability is relevant when the imminent instruction's expected effects include doing net damage and the amount of the damage is 2 or more. The effect of this ability is to set the value for the amount of damage to 1. Previously-applied modifiers to the value are ignored. The value can still be modified by other interrupts after being set to 1 this way.
- d.linkSome types of values must be greater than 0 for the associated effect to occur. See section 9.9.6. At the time an instruction resolves, if any value of one of those types is 0 or less, as much of that ability resolves as possible without applying the part of the effect making use of that value, following rules 1.2.3 and 1.2.4 of the Golden Rules.
- Example: The Runner accesses Breached Dome. While the instruction from its "when accessed" ability is imminent, the Runner uses Biometric Spoofing to prevent 2 damage. When the ability resolves, the value for the amount of damage is -1, which is less than or equal to 0, so the damage effect cannot occur and the Corp only trashes the top card of the stack.
- e.linkAny effects making use of modified values maintain their restrictions and specifications with the new values.
- Example: While the result of a successful trace from Flare is imminent, the Corp triggers The Cleaners to increase the imminent meat damage by 1. Even though the damage from Flare has been increased from 2 to 3, none of that meat damage can be prevented.
- 9.9.8.linkA replacement effect modifies another effect by replacing some or all of the original effect's behavior with different behavior. Replacement effects are indicated by the word "instead" in their text. Once created, replacement effects apply automatically and do not require players to explicitly trigger them.
- a.linkInterrupts can introduce replacement effects that apply to the currently imminent instruction. See rule 9.9.10.
- b.linkStatic abilities can stipulate replacement effects that apply whenever appropriate while the static ability is active.
- c.linkOther abilities can create replacement effects ahead of time, which apply to effects that could happen later. This is a type of lingering effect (see section 9.10).
- 9.9.9.linkReplacement effects most commonly apply to the effects of an instruction, but some apply to static abilities or alter the durations of lingering effects.
- a.linkIf a replacement effect modifies the effects of a static ability or the duration of a lingering effect, this modification applies continuously for as long as the replacement effect itself is active, and no longer applies once the replacement effect or the original effect being modified becomes inactive.
- Example: Gebrselassie's static ability replaces the durations of certain lingering effects affecting its host with a duration of "for the remainder of the turn." If Gebrselassie is uninstalled or moved to a different host, its replacement effect no longer applies to those lingering effects, so they revert to their normal durations. If any of those durations have already expired, the corresponding effects will end at the next checkpoint.
- b.linkIf an active replacement effect can apply to the expected effects of an imminent instruction, it is applied as the interrupt window opens, and the expected effects of the instruction are updated accordingly. This happens before the expected effects are checked for relevant active abilities that could become pending. Replacement effects created by interrupts will not yet be active at this time and are applied according to rule 9.9.10 instead.
- c.linkEach replacement effect can only apply once to any single effect. Once a replacement effect has been applied, even if the new effect it creates (or a new effect created by a later replacement effect) still includes an occurrence of the effect that gets replaced, the same replacement effect cannot be applied to that effect again.
- Example: The Runner accesses Project Vacheron and its interrupt ability resolves. The interrupt creates a replacement effect that will override adding the agenda to the Runner's score area. The Runner will still steal Project Vacheron, but they will do so by adding it to their score area with hosted agenda counters. Even though the modified effect still includes adding Project Vacheron to the Runner's score area, there is no way for the replacement effect to apply again to its own results.
- 9.9.10.linkSome interrupts create replacement effects to modify an instruction that is already imminent. When the interrupt resolves, if the replacement effect can apply to the expected effects of the imminent instruction, it is applied immediately.
- Example: An instruction is imminent with an expected effect of the Corp doing net damage to the Runner. The Corp uses Tori Hanzō's ability, creating a replacement effect replacing net damage with core damage. The replacement effect applies immediately, so after Tori Hanzō's ability resolves, the expected effect is now to do 1 core damage. When players get priority again, their interrupts are relevant or not based on the new expected effects.
- 9.9.11.linkIf multiple replacement effects would apply to an effect acting on a targeted card, that card's controller chooses the order in which the replacement effects apply. If multiple replacement effects would apply to any other effect, the controller of the base effect chooses the order in which the replacement effects apply.
- a.linkAfter applying one replacement effect, a subsequent replacement effect can only be applied if the effect it was to replace is still expected. A replacement effect cannot apply without something to replace.
- Example: The Runner chooses HQ with Security Testing when their turn begins, then plays Account Siphon. When the run becomes successful, both Security Testing and Account Siphon create replacement effects. When step 6.9.5b of the run becomes imminent, the Runner must choose to apply either the replacement effect from Security Testing or the one from Account Siphon. Since neither effect creates a new instance of accessing cards, the effect not chosen to apply first has nothing to replace and does not apply.
- Example: The Runner chooses R&D with Security Testing when their turn begins, then plays Showing Off. When a run on R&D becomes successful, both Security Testing and Showing Off create replacement effects. When step 6.9.5b of the run becomes imminent, the Runner must choose to apply either the replacement effect from Security Testing or the one from Showing Off. If they choose to apply Security Testing first, Showing Off's effect has nothing to replace and does not apply. If they choose to apply Showing Off first, the expected effects still include breaching R&D, albeit not in the usual way. Security Testing can still replace this access, so it applies next. Either way, the Runner will gain 2[c] and will not access any cards.
- 9.10.1.linkInstructions can create lingering effects that exist beyond their resolution. Once a lingering effect is created, it exists independently of its source even if the source becomes inactive. Lingering effects remain active only for the duration specified in the instruction that created them. Lingering effects with durations that have expired are removed from the game state at step 10.3.1b of each checkpoint.
- 9.10.2.linkSome lingering effects exist only to maintain the existence of another ability. Delayed conditional abilities are maintained this way and may have an implicit duration. See section 9.6.13.
- 9.10.3.linkSome lingering effects maintain a choice that a player made while resolving an ability in order for another ability or effect with the same source object to make use of that choice.
- a.linkIf the choice is only referred to by another lingering effect, the lingering effect maintaining the choice has the same duration as the other lingering effect.
- Example: The Runner resolves Pelangi's paid ability and chooses an ice subtype. The ability then creates a lingering effect adding the chosen subtype to the encountered ice. Both the choice of subtype and the effect adding it to the ice expire at the end of the encounter.
- b.linkIf a conditional ability has a "when your turn begins" trigger condition and no effects other than making a choice, the duration of the lingering effect maintaining the choice expires when that turn ends or the source object becomes inactive.
- Example: Security Testing's first ability reads, "When your turn begins, you may choose a server." The choice made when resolving this ability on a particular turn should be maintained only until that turn ends. The trigger condition of Security Testing's second ability refers to the chosen server, and it will always look for the server chosen this turn. A successful run on a server that was not chosen this turn will never meet that trigger condition, even if no server was chosen this turn.
- c.linkIf the previous cases do not apply, the duration of the lingering effect expires only when the source object becomes inactive.
- Example: Femme Fatale's first conditional ability directs the Runner to choose an installed piece of ice. Which ice was chosen is maintained as a lingering effect for as long as Femme Fatale remains active, and its last ability refers to the object that is being remembered by that lingering effect.
- 9.10.4.linkIf a lingering effect is created with a duration based on a timing structure that is not in progress at the time the lingering effect is created, the duration expires immediately, and the lingering effect persists only until the next checkpoint after it is created.
- a.linkAbilities on an icebreaker that modify their source's strength have an implicit duration of "for the remainder of the current encounter". See rule 3.9.5b.
- 9.10.5.linkOnly lingering effects have durations. An ability that modifies the durations of other abilities functions by keeping their corresponding lingering effects active until an additional duration expires. This type of ability does not interact with effects from static abilities.
- Example: The Runner controls Gebrselassie hosted on Na'Not'K. They run a server protected by 3 pieces of ice, and use Na'Not'K's last ability to raise its strength to a total of 6. When the run ends, Na'Not'K's static ability will no longer provide +3 strength, but the lingering effect of +2 strength from its paid ability will be maintained by Gebrselassie until the turn ends or Gebrselassie stops being hosted on Na'Not'K. If the Runner makes another run on a server protected by only 1 piece of ice, Na'Not'K will have 4 strength when that run begins.
To correctly resolve conditional abilities and interrupts that could meet their trigger conditions during the resolution of another ability (see rule 9.1.2a), players need to determine where checkpoints occur during the resolution of each ability. This section aids players in making this determination. For clarifications on particular cards, refer to the Rulings section of that card's page on netrunnerdb.com.
- 9.11.1.linkAn instruction normally cannot be paused once it begins to resolve. An instruction can only be paused if a checkpoint opens in the middle of its resolution, which only occurs in the following cases:
- a.linkAny time a cost is paid, a checkpoint must occur immediately afterward.
- b.linkWhen a timing structure is opened, the checkpoints in that timing structure are carried out. See section 9.2.2 for a list of timing structures.
- c.linkWhen a player draws cards, a checkpoint occurs at step 8.4.5b of that procedure.
- d.linkWhen an event or operation is played, a checkpoint occurs at step 8.6.6e of that procedure.
- e.linkWhen a trace is initiated, a checkpoint occurs at step 10.8.6b of that procedure.
- 9.11.2.linkEach step in a timing structure forms a single instruction, and is accordingly preceded by an interrupt window and followed by a checkpoint.
- a.linkSome game procedures that are not timing structures are presented as a sequence of steps. These steps do not indicate instruction boundaries, and checkpoints only occur in these procedures when explicitly called for.
- Example: The steps of installing a card are not separate instructions. Installing a card usually happens in its entirety as part of a single instruction. The only checkpoint that occurs during the procedure of installing a card is at step 8.5.15d, immediately after the install cost is paid.
- Example: The steps of a checkpoint are not instructions. No checkpoints take place in the middle of another checkpoint.
- 9.11.3.linkUsually, each sentence in the text of an ability forms a single instruction. After each instruction, an ability pauses its resolution to allow priority windows to open and other abilities to resolve. First, a checkpoint occurs, allowing any appropriate conditional abilities to be marked as pending in a reaction window, then targets are announced for the next instruction. Finally, the next instruction becomes imminent, allowing interrupts relevant to that instruction to resolve in an interrupt window.
- 9.11.4.linkSome sentences are not instructions, some sentences encompass multiple instructions, and some instructions encompass multiple sentences. These are the cases in which sentences do not correspond one-to-one with instructions:
- a.linkA sentence is not part of any instruction if it only provides clarification, restrictions or conditions on when or how the ability it appears in can be triggered, or otherwise does not give directions to the players or the game state that would be carried out as the ability resolves.
- Example: A sentence reading "Use this ability only by spending credits from a stealth card." is not an instruction or part of any instruction. It is a restriction that applies to the entire ability.
- b.linkIf a sentence directs a player to play, install, or access more than one card, each such card is handled as a separate instruction. The instruction ends and a new one begins immediately before each play, install, or access after the first.
- Example: The Corp plays Shipment from MirrorMorph, which has a single sentence directing them to install up to 3 cards from HQ. This is treated as though it said, "You may install a card from HQ. You may install a card from HQ. You may install a card from HQ.", or equivalently, "You may install a card from HQ. Repeat this process 2 more times."
- c.linkIf a sentence directs a player to choose 1 or more targets, but does not act on that choice or describe any other effects, that sentence and the following sentence form a single instruction.
- Example: Tinkering's play ability reads, "Choose a piece of ice. That ice gains sentry, code gate, and barrier until the end of the turn." The first sentence does nothing except direct the Runner to select a target, so it forms a single instruction with the second sentence. The target is chosen as the instruction becomes imminent, and the card gains the subtypes when the instruction resolves.
- d.linkSome older cards have search effects written in the same sentence as the effects that will be performed upon any found cards. Treat these sentences as if ending the search and performing any necessary shuffling is the end of an instruction. A checkpoint occurs while cards found by the search are in the set-aside zone, then the remainder of the sentence is treated as the next instruction.
- Example: The Runner uses Djinn to search for a program while the Corp has Personality Profiles in their score area. The Runner finds and sets aside a copy of Datasucker and shuffles the stack. This ends an instruction, and since the search has occurred, Personality Profiles's ability meets its trigger condition. The Corp resolves the ability during a reaction window before the next instruction becomes imminent, forcing the Runner to trash a random card from their grip. Finally, the second instruction resolves and the Runner adds the set-aside Datasucker to their grip.
- e.linkSome older cards direct a player to look at or reveal a set of cards in the same sentence as the effects that will be performed upon those cards. Treat these sentences as if making the cards visible to the relevant player(s) is the end of an instruction. A checkpoint occurs once the cards are visible to the relevant player(s), then the remainder of the sentence is treated as the next instruction.
- Example: The Corp is resolving the first subroutine on Architect, which, in one sentence, allows the Corp to look at cards in R&D and install one of them. Looking at the top 5 cards of R&D ends the ability's first instruction. Once the Corp is able to see those cards, they can choose a target for the second instruction, which will install it. Since the install is optional, the Corp can also decline to choose a target, and the second instruction will have no effect. After the second instruction resolves, the ability is complete, and the Corp's permission to look at cards in R&D ends.
- f.linkIf an ability contains a nested cost, the choice of whether or not to pay that cost ends an instruction. If the cost is paid (or not paid) such that the corresponding effect will be carried out, that part of the ability becomes the next instruction. See also section 1.16.11.
- g.linkIf an effect directs a player to choose between a set of options that would create different effects, that choice ends an instruction. Each option begins its own instruction or set of instructions, and the one chosen will resolve next.
- Example: The Runner encounters Data Raven and is forced by its first ability to resolve either "take 1 tag" or "end the run." Making this choice ends the first instruction, and the option the Runner chooses will become imminent after a checkpoint.
- 9.11.5.linkIf an ability initiates a timing structure, its source may have linked abilities that apply during that timing structure. These are frequently written directly after the instruction that creates the timing structure, but they are not instructions in the same ability.
- 9.12.1.linkSimultaneous Effects
- a.linkIf more than one effect attempts to modify the same value, determine its final value from its default value by first applying any effect that sets it to a specific value, then applying each effect that increases the value, and finally applying each effect that lowers the value.
- b.linkIf more than one effect attempts to add or remove the same subtype from a card, count the number of times the subtype is added (including from the card's printed text) and the number of times the subtype is removed. As long as the number of times added is greater, the card has that subtype. As long as the number of times removed is greater or the numbers are equal, the card does not have that subtype.
- c.linkIf more than one effect gives a player a choice of how to resolve an ability or game rule such that both players are instructed to make a choice that can only be made once, the active player makes that choice. The effects that granted the players the choice otherwise resolve as normal.
- Example: If Chronos Protocol and Titanium Ribs are both active, both players are instructed to choose the card trashed by the first net damage each turn. Since this is impossible, only the active player chooses that card. Since Chronos Protocol also instructs the Corp to look at the Runner's grip and this is not prevented or contradicted by any other ability, this part of the effect happens on either player's turn.
- d.linkIf a static or lingering effect changes whether a second effect is active, what objects it applies to, or what it does to those objects, the second effect depends on the first effect. To determine the characteristics of each object in a game state where dependencies exist, use the following process: begin with each object's printed characteristics. Then, apply effects that modify objects to the game state in the order specified by rule 9.12.1e. Do not apply an effect if it originates from a static ability that is no longer present or no longer active due to a previously-applied effect. When all active effects are applied, this process is complete and each object has its correct characteristics.
- e.linkWhen applying effects as indicated by rule 9.12.1d, an effect that is waiting to be applied is independent if it does not depend on any other effects waiting to be applied. Always choose an independent effect as the next effect to apply, if possible. If there are multiple independent effects at once, those effects can be applied in any order relative to each other. (The order chosen should have no impact on the ultimate result.) If there are no independent effects (because each remaining effect depends on another, forming a "loop"), check the source of each of those effects, and treat effects from hosted objects as if they did not depend on effects from the objects they are hosted on.
- Example: Mother Goddess, Ansel 1.0, and Warden Fatuma are rezzed, and Hush is hosted on Mother Goddess. Mother Goddess, Warden Fatuma, and Hush all produce effects that could modify the characteristics of Mother Goddess, so in order to determine Mother Goddess's true characteristics, we must examine how those effects depend on each other. Mother Goddess's effect grants it the subtypes of Ansel 1.0, including the bioroid subtype, which affects whether Warden Fatuma's ability applies to Mother Goddess, so Warden Fatuma's effect depends on Mother Goddess's effect. Hush's effect removes Mother Goddess's ability, so Mother Goddess's effect depends on Hush's effect. No other effects change how Hush's effect behaves. Since Hush's effect is independent, it must be applied first. When it is applied, Mother Goddess's ability no longer exists, so Warden Fatuma's effect is now independent. It is applied next and grants a subroutine to Ansel 1.0, but not to Mother Goddess, which does not have the bioroid subtype.
- Example: Hush is hosted on Magnet. Hush's ability creates an effect that removes abilities from Magnet, and Magnet's ability creates an effect that removes an ability from Hush. The dependencies of these effects form a loop, so the hosting relationship of their source objects is considered, and the effect from Hush's ability ignores its dependence on the effect from Magnet's ability. Hush's effect is therefore treated as independent and applied first. Magnet's ability and the resulting effect no longer exist, so they are never applied.
- 9.12.2.linkQuantities and Sets
- a.linkIf an effect acts on a set of cards for a single purpose, then the effect acts on all of those cards together simultaneously rather than one at a time.
- Example: The Runner uses Singularity to simultaneously trash a rezzed Warroid Tracker and a rezzed Hostile Infrastructure. Hostile Infrastructure has a trigger condition of "Whenever the Runner trashes a Corp card", so it sees both trashed cards and becomes pending twice. By contrast, Warroid Tracker has a trigger condition of "Whenever the Runner trashes at least 1 card…", so it sees only a single event that trashed multiple cards. Warroid Tracker's ability becomes pending only once.
- b.linkSome abilities calculate a quantity using phrases like "for each", "for every", or "plus". When a quantity is calculated this way for any of the purposes listed in rule 9.12.2c, the resulting effect is aggregated to the value that was calculated. Only a single instance of that effect takes place. If the calculated value is less than or equal to 0, the effect does not take place at all.
- c.linkThe following effects are aggregated when performed in a single instruction, as described in rule 9.12.2b: gaining, losing, or spending a number of credits; gaining, losing, or spending a number of clicks; taking, removing, or preventing a number of tags; taking, removing, or preventing a number of bad publicity; looking at or revealing a number of cards from a specified location; drawing a number of cards; trashing a number of cards from specified locations (including by damage); and shuffling a number of cards from a player's discard pile into their deck.
- Example: The Runner encounters a Cortex Lock and does not break the subroutine. If the Runner has 2 unused MU, both of the net damage can be prevented with Biometric Spoofing because Cortex Lock does a single instance of 2 net damage, not 2 instances of 1 net damage each. If the Runner has no unused MU, then no net damage is dealt because there is no MU to count.
- Example: The Runner controls Obelus and The Class Act, and they play Legwork to run HQ and access 3 cards. When the run ends, the ability on Obelus becomes pending. The expected effect of its instruction is 1 instance of the Runner drawing cards, where the number of cards they will draw is 3. When the Runner resolves The Class Act's interrupt ability, they will look at the top 4 cards of their stack and add 1 to the bottom.
- d.linkIf a condition refers to "all" items in a set and that set contains zero items, the condition is automatically satisfied as soon as it could be satisfied for 1 or more of that item.
- Example: The Runner plays Forked, initiating a run on a server. The first piece of ice that the Runner encounters is Troll. If Troll's "when encountered" ability does not end the run, the Runner is automatically considered to have broken all of the zero subroutines on Troll as soon as step 6.9.3b of the encounter begins, and Troll is trashed by Forked.
- e.linkSome values are defined with a variable "X". If the ability defining X is inactive or if the value of X cannot be evaluated, treat X as equal to 0.
- Example: The Corp uses the ability granted by ZATO City Grid to trash Surveyor and resolve one of its subroutines. Since Surveyor is in Archives when the trace on the subroutine initiates, the ability defining X is inactive, so the base trace strength is 0.
- Example: Hush is hosted on Surveyor. The ability defining X is lost, so Surveyor's strength is 0.
- 9.12.3.linkMust
- a.linkIf a card ability states that a player "must" do something without stipulating how that player must do so, then that player is forced to make any decisions necessary to satisfy the requirement, even if it requires the use of other card abilities.
- Example: The Runner has an Imp and a Scrubber installed and accesses Mumbad Virtual Tour. If the Runner only has 4[c], they must still choose to either spend a counter from Imp to trash Mumbad Virtual Tour if they are able to do so or spend recurring credits on Scrubber to help pay the trash cost of the Mumbad Virtual Tour.
- b.linkIf a card ability states that a player "must" do something and specifies the means by which that player must do so, then that player is not required to carry out the effect except by the means specified, even if it would be possible through the use of other card abilities.
- Example: The Runner has Imp and Neutralize All Threats installed when they access a card with a trash cost greater than the number of credits they have available to spend. Because they are unable to trash the card by paying its trash cost, they are not required to spend a counter from Imp in order to trash it.
- c.linkIf the "must" ability presents a player with a choice between two or more effects, that player must choose an effect that can be fully resolved. If none of the choices can be fully resolved, then the "must" ability does nothing.
- Example: If the first subroutine on Fairchild 2.0 resolves while the Runner has no installed cards but 3[c], then the Runner must choose to pay 2[c]. When the second subroutine on Fairchild 2.0 resolves, the Runner can neither pay 2[c] nor trash an installed card, so nothing happens.
- d.linkMaking a choice between effects is always a separate instruction from resolving the chosen effect (see rule 9.11.4g). The previous rule only requires the player to choose an effect that is possible to resolve; it does not require the chosen effect to actually resolve as expected. Once an effect has been chosen, the player can apply interrupts to modify, prevent, or replace that effect as normal.
- Example: If the Runner encounters Data Raven, they must choose to either take a tag or end the run. The Runner can choose to take the tag, then avoid the tag with Decoy. This does not cause the run to end, as the decision to take the tag has already been made.
- e.linkA singular "must" ability cannot force a player to pay an additional cost they wish to decline, but a player cannot avoid choosing a fully resolvable effect from among multiple options in a "must" ability by declining to pay the additional cost for one of those choices.
- Example: If Service Outage is active and the Runner has Always Be Running installed, the Runner can decline to pay the additional 1[c] to make a run with their first [click], thus satisfying the "must" of Always Be Running and allowing them to spend their first click on a different action. However, if a Runner plays a Forged Activation Orders on an unrezzed Archer, the Corporation cannot choose to rez the Archer but decline to forfeit an agenda; the Corp must either pay 4[c] and forfeit an agenda to rez the Archer or trash the Archer.
- 9.12.4.linkRepeat this process
- a.linkIf an ability instructs a player to "repeat this process" without specifying how many times to do so, then that player resolves the ability again, including the instruction to "repeat this process" if it is still applicable.
- b.linkIf an ability instructs a player to "repeat this process" a specified number of times, then that player resolves the entire ability, except for the repetition instruction, that many times in a row. The number of repetitions is determined after the first full resolution but before the first repetition, and once the number of repetitions is determined it cannot be changed.
- c.linkRegardless of the number of times an ability is repeated, a checkpoint occurs after each full resolution of the ability's instructions, before another repetition begins.
- d.linkEach repetition of the ability is resolved independently of the others. If the ability provides the player with any choices, they may choose differently each time.
- 9.12.5.linkPersistent
- a.linkA persistent ability is an ability on a Corp card marked with the "persistent" ability flag before its other text. When the Runner trashes a rezzed card they are accessing, its persistent abilities persist through a lingering effect that is created as the source card is trashed. See also section 9.10.
- b.linkA persistent ability begins to persist simultaneously with the trashing of its source card. The ability never becomes inactive, nor is it considered a new ability.
- c.linkAn ability only persists until just after the end of the run during which it began to persist. When the reaction window immediately following step 6.9.6d of that run closes, the lingering effect allowing the ability to persist expires, and the ability ceases to persist.
- d.linkA persisting ability is only applicable to the run during which it began to persist. After the checkpoint following step 6.9.6d of the run, no more instances of the ability can be created. Even if another run initiates during the reaction window following that checkpoint, new instances of any abilities persisting from the first run cannot become pending during the second run, even if their trigger conditions would normally be met during that second run.
- Example: The Runner trashes AMAZE Amusements, causing its "Whenever a run on this server ends" ability to persist. When the run ends, the Runner uses Doppelgänger to make another run while the persisting ability is still pending. The ability remains active so that its existing pending instance can resolve, but another instance cannot be created even if the Runner steals an agenda during the second run.
- 9.12.6.linkModal Abilities
- a.linkSome abilities contain text organized into bulleted lists. These are called modal abilities, and each list item is called a mode.
- b.linkEach modal ability contains an instruction directing its controller to resolve 1 or more of its modes. The effect of this instruction is for the relevant player to choose the next mode to resolve. The first instruction of the chosen mode will be the next instruction to become imminent. The player does not need to choose modes in the order they are written. If the description of the number of modes to resolve contains "up to", the player may also choose not to resolve any more modes.
- c.linkAfter the instructions of a mode are complete, the game returns to the instruction to resolve 1 or more modes. If the maximum allowed number of modes have not yet been resolved, the player will choose another mode to resolve, as if resolving that initial instruction again. If the maximum number of allowed modes have been resolved, the game proceeds to the next instruction or ability following the list of modes.
- d.linkIn a single instance of resolving a modal ability, each mode can be resolved no more than 1 time, unless the ability specifically states that its modes can be chosen more than once.
- 10.1.1.linkSome cards are unique, and have a unique symbol (◆) before their name to designate this. There can be only one unique card of the same name active at a time. If a unique card becomes active, any other card that shares its name is trashed during the next checkpoint. Trashing a card this way cannot be prevented. See section 10.3.
- 10.1.2.linkTo purge virus counters is to remove all virus counters hosted on cards and return them to the bank. The Corp can purge virus counters as a basic action or with a card ability.
- a.linkThe Corp can always use a purge effect, even if there are no virus counters currently hosted on any cards. This is an exception to rule 1.2.5.
- 10.1.3.linkSome abilities add a card to a player's score area "as an agenda". When this happens, the card loses all its previous properties and gains only those properties specified in the effect converting it. This conversion lasts until the card moves to a zone that is not a score area, at which point it returns to being its original printed card. If this happens in any way other than by agenda forfeit, the card is immediately trashed. See rule 8.2.5.
- 10.1.4.linkSome abilities can convert a card into a counter. When this happens, the card loses all its previous properties and gains only those properties specified in the effect converting it. This conversion lasts until the counter moves to another zone, at which point it reverts to being a card, regains its original printed characteristics, and is trashed.
- 10.1.5.linkSome cards are written with self-referential language. If a card references its own name without using the word "copy", treat that name as if it said "this object".
- Example: The subroutine on the original printing of Kitsune includes the phrase "trash Kitsune." This phrase means "trash this ice.".
- Example: Boomerang's text refers to "a copy of Boomerang". This is not self-referential language and refers to any card named Boomerang.
- 10.1.6.linkInfinite Loops
- a.linkIf a mandatory infinite loop is created (a player cannot choose to stop resolving the loop) then the player who is resolving the loop chooses a number. The loop instantaneously resolves that many times, and then ends.
- Example: The Runner runs into a rezzed Wormhole. The only other piece of ice that is rezzed is a Wormhole, and so a mandatory infinite loop is created where each of the Wormholes' subroutines resolves the other. The Corp chooses how many times this loop occurs, say 2,157 times, and then the Runner continues the run.
- b.linkIf an optional infinite loop is created (a player can choose to stop resolving the loop) during a run, then the Runner must jack out unless another card ability prevents them from doing so. If the Runner cannot jack out, then it is the Corp's responsibility to end the loop by letting the Runner continue the run.
The game, at its core, is about information. Much of the game revolves around deducing information about the opponent's cards and strategy.
- 10.2.1.linkInformation in the game is classified as hidden information or open information.
- 10.2.2.linkHidden Information
- a.linkhidden information is any information about the game, game state, or cards unavailable to one or more players. This includes facedown cards in play or in Archives, cards in HQ or R&D, cards in the Runner's grip or stack, etc.
- b.linkA player cannot learn hidden information without the aid of a game effect, rule, or another player verbally communicating the information. However, if a player that has access to information about the game or a card chooses to verbally share it with their opponent, that player is not required to tell the truth. Bluffing is allowed.
- Example: The Runner uses Indexing. While rearranging cards, the Runner places Braintrust on top of R&D, followed by Snare!. The Corp draws at the beginning of their next turn, then spends their first click to draw a card. For their second click, the Corp installs a card in an empty remote server, telling the Runner that they should run it because it is a Braintrust.
- 10.2.3.linkOpen Information
- a.linkopen information is any information about the game, game state, cards, or abilities that is available to both players. This includes faceup cards in Archives and the heap, the number of cards in HQ, R&D, the stack, and the grip, the number of credits in a credit pool, and any other information continuously available to both players.
- b.linkOpen information cannot be hidden from an opponent. A player must allow their opponent to discover the information themselves if they attempt to do so.
- Example: The Runner installs Femme Fatale, choosing a piece of ice protecting HQ with Femme's ability. The Runner must explicitly state to the Corp which ice has been chosen and must continue to do so if the Corp asks for Femme Fatale's target during a later turn.
- 10.3.1.linkA checkpoint is a process wherein objects that have entered an illegal state are corrected, expired effects are removed, and other important conditions are checked. This procedure is automatically performed at several timing points during the game, and entails the following steps, which are performed in order:
- a.linkEach active conditional ability looks at the changes to the game state since the beginning of the last checkpoint to see if its condition has been met. Any ability that has met its condition creates the appropriate instances of itself and marks them as pending, as described in section 9.6.
- b.linkAny ability with a duration that has passed is removed from the game state.
- Example: During the checkpoint that follows the end of an encounter, abilities that increased the strength of an icebreaker during that encounter expire and the icebreaker's strength is correspondingly lowered.
- Example: The Corp has Targeted Marketing in the play area when the Runner steals an agenda. In the next checkpoint, the game recognizes that the ability on Targeted Marketing that was preventing the operation from being trashed no longer applies, and so the Corp trashes Targeted Marketing as if it were completing its resolution.
- c.linkIf the agendas in either player's score area total 7 or more agenda points, that player wins the game. If both players would win this way simultaneously, the game ends in a draw.
- d.linkIf 2 or more unique (◆) cards with the same name are active, for each such name, all of those cards except the one that became active most recently are trashed. If 2 or more console cards are installed under the control of the same player, for each such player, all of those cards except the one that became active most recently are trashed.
- e.linkIf any objects break any restrictions of card abilities or the game rules (such as the Runner's memory limit) or are installed or hosted in an illegal location, an appropriate set of those objects are trashed. A set is appropriate for this purpose if trashing the objects in the set would leave all remaining installed or hosted objects in legal locations and if no object can be removed from the set while maintaining that property. If there are multiple distinct appropriate sets, and one player controls all the objects in each of those sets, that player chooses which set to trash. If the sets contain objects controlled by both players, the active player chooses which set is trashed.
- Example: The Runner controls a Chisel hosted on an unrezzed piece of ice. The Corp rezzes that ice, revealing it to be Tithonium. Since Tithonium has an ability prohibiting cards from being hosted on it, Chisel is now installed in an illegal location and must be trashed.
- Example: The Runner has installed programs with total memory cost equal to their memory limit when the Corp plays Bad Times, reducing the memory limit by 2[MU]. The Runner can trash any two programs with a memory cost of 1[MU] each, or any one program with a memory cost of 2[MU] or greater. They cannot trash any 0[MU] programs, nor can they trash any set of more than one program with a greater total memory cost than 2[MU], since those objects can be removed from the trashed set while maintaining that the result will be a legal game state.
- f.linkAny objects that were hosted on an agenda that moved from a score area to any zone other than a score area are trashed.
- g.linkAny objects that were hosted on an installed card that was uninstalled are trashed, except for cards or counters that are temporarily in the set-aside zone because of rule 9.5.5. This step is repeated until no more cards or counters are trashed.
- h.linkAny remote server with no cards protecting it, in its root, or in the process of being installed with a destination protecting it or in its root ceases to exist.
- i.linkIf a server is being breached and 1 or more cards entered the root of that server since the previous checkpoint, for each such card, the Runner declares whether or not it becomes a candidate for access in this breach. See also section 7.4.
- Example: The Runner accesses Ganked! and encounters Drafter in the middle of breaching a server. The second subroutine on Drafter resolves, and the Corp uses its effect to install a card in the root of the server being breached. When the installation is completed, the Runner declares whether or not the installed card becomes a candidate. If it does become a candidate, the Runner will select it for access later in the breach.
- j.linkAny cards in discard piles that had been converted into counters or agendas return to their printed characteristics.
- k.linkAny counters in a discard pile are returned to the bank.
- 10.3.2.linkAfter a checkpoint is completed, if it marked any instances of conditional abilities as pending, a new reaction window immediately opens to handle those abilities, even if this takes place during another reaction window. After a reaction window closes, the game proceeds to whatever was due to occur after the checkpoint that caused it to open.
- 10.3.3.linkWhenever a player would receive priority, first a checkpoint occurs. See also section 9.2.4.
- 10.3.4.linkWhenever a player pays a cost, a checkpoint occurs immediately afterward, before continuing with the effect or timing structure in which the cost was paid. See also section 1.16.
- 10.3.5.linkWhenever an instruction finishes resolving, a checkpoint occurs immediately afterward, before the next instruction becomes imminent. See also section 9.11.
- 10.3.6.linkThe checkpoint following the last step of a timing structure takes place outside of that timing structure, as does any associated reaction window.
- Example: The Runner, playing as Jesminder Sareen: Girl Behind the Curtain, steals an agenda during a run on a server with AMAZE Amusements rezzed in its root. Since AMAZE Amusements's ability meets its trigger condition when the run ends, it will become pending in the reaction window following step 6.9.6d and attempt to give the Runner 2 tags. During this window, the run timing structure has closed, and Jesminder's interrupt ability cannot apply to those tags.
- 10.4.1.linkMany cards and ice subroutines inflict damage on the Runner. The Runner suffers (sometimes referred to as "takes") damage according to the rules for the type of damage specified. If a Corp card "does" damage to the Runner, they suffer that much damage, with the additional provision that the Corp and the source card are responsible for that damage. If a card directs or allows the Runner to "suffer" damage, then the Runner and the source card are responsible for that damage.
- Example: The Corp, playing as Argus Security: Protection Guaranteed, has scored The Cleaners. The Runner makes a run on R&D and steals Hostile Takeover. Argus Security's ability triggers and the Runner chooses to suffer 2 meat damage. As The Cleaners only adds additional damage to damage done by the Corp, its ability does not apply. When the Corp plays Punitive Counterstrike on their next turn, The Cleaners does increase the amount of damage done by Punitive Counterstrike.
- 10.4.2.linkThe three types of damage the Runner can suffer are meat, net, and core damage
- a.linkmeat damage and net damage are resolved the same way. For each point of damage suffered, 1 card is randomly trashed from the grip.
- b.linkFor each point of core damage suffered, 1 card is randomly trashed from the grip, and the Runner's maximum hand size is permanently reduced by 1. The Runner takes a core damage counter for each core damage suffered to track the reduction in hand size.
- c.linkSome cards refer to "brain damage". This is an older term for core damage. The two terms are interchangeable.
- 10.4.3.linkIf the Runner suffers more than 1 damage of any type, the cards are randomly trashed simultaneously.
- Example: The Runner has 2 tags and four cards in their grip, one of which is I've Had Worse. The Corp plays BOOM!, dealing 7 meat damage to the Runner. If the Runner cannot or does not prevent at least 3 of the incoming damage, they immediately flatline as they have suffered more damage than they have cards in grip, and I've Had Worse does not have the opportunity to resolve. If the Runner does prevent enough of the damage to survive, the Runner randomly trashes as many cards as the remaining amount of damage. After all the cards have been randomly selected and placed in the heap, I've Had Worse meets its trigger condition if it is among those cards trashed by the damage.
- a.linkIf an effect modifies the procedure for dealing damage such that the cards trashed cannot be selected simultaneously, then the cards are selected sequentially but are still trashed simultaneously.
- Example: The Corp is playing as Chronos Protocol: Selective Mind Mapping when the Runner accesses a Snare! before taking any other damage during this turn. The Corp looks at the grip and selects a card to be trashed as the first point of net damage for the turn, then two other cards are randomly selected. All 3 cards are trashed simultaneously.
- 10.4.4.linkIf the Runner takes more damage than the number of cards in their grip, or if they have a maximum hand size of less than zero at the end of their turn, then they are flatlined and the Corp wins the game.
Tags represent the Corp's possession of valuable information about the Runner, such as a data trail they've left behind or the physical location they are jacked in from.
- 10.5.1.linkA tag refers to a tag counter placed on the Runner. Tags are used in card abilities and basic actions.
- 10.5.2.linkThe Runner is tagged if there are one or more tags on them.
- 10.5.3.linkWhile the Runner is tagged, the Corp can, as an action, spend [click] and 2[c] to trash one of the Runner's resource cards.
- 10.5.4.linkWhile the Runner is tagged, they can, as an action, spend [click] and 2[c] to remove one tag, returning it to the bank.
- 10.5.5.linkThe Runner controls each tag on them, but the Corp can pay costs involving tags as if they controlled the Runner's tags.
- Example: The Runner has a tag, and makes a run on a server with Keegan Lane installed. Even though the tag token is controlled by the Runner, the Corp can remove it to pay the cost of Keegan Lane's ability to trash one of the Runner's programs.
Nobody likes corrupt Corps, or at least, most people say they don't. If a Corp has a bad reputation, the Runner has an easier time finding help to attack that Corp's servers. This extra help is abstracted as extra credits the Runner gets to use during runs.
- 10.6.1.linkbad publicity refers to a bad publicity counter placed on the Corp. Bad publicity is used by card abilities and during runs.
- 10.6.2.linkFor each bad publicity the Corp has, the Runner gains 1[c] at the beginning of each run, during step 6.9.1b. Any unspent bad publicity credits return to the bank at the end of the run, during step 6.9.6b.
- a.linkIf the Corp takes bad publicity while a run is already underway, the Runner does not gain additional bad publicity credits for that run.
- 10.6.3.linkThe Corp controls each bad publicity on them, but the Runner can pay costs involving bad publicity as if they controlled the Corp's bad publicity.
The Runner's link is the number of points their path through the Net traverses between their rig and the Corp's server. The more proxies, redirects, and other intermediary connecting points between the Corp and the Runner, the harder it is for sysops to track down the Runner's virtual location.
- 10.7.1.linkThe Runner's link value is calculated by adding the base link on their identity card to the link ([link]) produced by their installed cards.
- 10.7.2.linkLink is primarily used to contest traces, as described in section 10.8, but other abilities can also refer to the Runner's link value.
A trace is the Corp's attempt to connect from their servers back to the Runner. Many traces can allow the Corp to gain information about the Runner, tagging them, but traces can also produce a wide variety of other effects. Traces most commonly originate from ice subroutines, but Corporate operations can produce some of the nastiest trace effects.
- 10.8.1.linkSome card abilities initiate a trace attempt (sometimes simply called a trace) on the Runner. Traces are marked by the language "Trace [N]" on a card, where the given value N is the base trace strength of the trace. A trace pits the Corp's trace strength against the Runner's link strength, both of which can be increased by spending credits.
- 10.8.2.linkThe Corp acts first during a trace attempt, openly spending any number of credits. This sets the trace strength, which is the base trace strength plus the number of credits spent.
- 10.8.3.linkAfter the Corp spends their credits, the Runner has the opportunity to spend credits to establish their link strength. The Runner's link strength is equal to their link value plus the number of credits spent.
- 10.8.4.linkAfter the Runner's link strength is established, it is compared to the Corp's trace strength. If the trace strength exceeds the link strength, the trace attempt is successful and any "if successful" abilities associated with the trace meet their trigger conditions. If the link strength is equal to or greater than the trace strength, then the trace attempt is unsuccessful, and any "if unsuccessful" abilities associated with the trace meet their trigger conditions.
- 10.8.5.link"If successful" and "if unsuccessful" effects following the "Trace [N]" indicator are conditional abilities tied to the results of the trace. Any instructions in the body of the trace without an "if successful" or "if unsuccessful" are conditional abilities with the implicit trigger condition, "when the trace is determined to be successful or unsuccessful."
- Example: Gemini's subroutine initiates a trace attempt with two associated conditional abilities. The first is "If successful, do 1 net damage." and the second is "When the trace is determined to be successful or unsuccessful, if your trace strength is 5 or greater, do 1 net damage." Both of these will become pending (if appropriate) after step 10.8.6e below.
- 10.8.6.linkSteps of Resolving a Trace Attempt
- a.linkThe trace initiates. At this time, any "when a trace is initiated" abilities meet their trigger conditions.
- b.linkA checkpoint occurs.
- c.linkThe Corp may spend credits to increase the trace strength.
- d.linkThe Runner may spend credits to increase their link strength.
- e.linkThe trace is determined to be successful or unsuccessful.
- f.linkThe trace is complete.
- 10.9.1.linkTo load a card with counters is to place those counters on that card. A card is empty when it is no longer hosting any counters of a type that were previously loaded onto it.
- 10.9.2.linkAn ability on a card that refers to that card becoming empty is always linked to a preceding ability on that same card that loaded it with counters.
- Example: The Runner installs Crowdfunding, and its first ability becomes pending. Even though there are no credits hosted on Crowdfunding until that ability resolves, the following "When it is empty, ..." ability does not meet its trigger condition because the card has not yet been loaded.
- 10.9.3.linkIf any other types of counters are placed on that card without having been loaded, and those counters are subsequently removed, then empty abilities on that card do not meet their condition.
- 10.9.4.linkLoading a card with counters does not impose any further restrictions upon those counters for that card. Other abilities can still issue instructions to act upon counters of that type, including but not limited to placing more of them or removing some of them.
A Runner's life is one of fluidity and adaptation; their rig is in a constant state of repair of upgrade, hideouts change, and belongings come and go. With creativity and skill, a Runner can apply their personal touch to get more out of their tools and resources than anyone else would think possible.
- 10.10.1.linkTo charge is to place 1 power counter on a card that already has at least 1 hosted power counter. Cards with no hosted power counters cannot be charged.
- 10.10.2.linkIf an instruction directs a player to charge 1 or more cards from among a set of cards, the particular cards to be charged are chosen as targets of that instruction. Only cards in the indicated set with at least 1 hosted power counter are valid targets. See section 1.15.
- 10.10.3.linkIf an instruction directs you to charge a particular card, that part of the instruction can only be resolved if the card has at least 1 hosted power counter at the time the instruction becomes imminent.
A savvy Runner is always ready to take advantage of an unexpected windfall or moment of vulnerability: an unguarded shipment, sudden tip-off from a trusted friend, an inattentive guard or merely an unsecured PAD. Many Runners refer to these opportunities as "marks", and pursue them for access and profit.
- 10.11.1.linkThe mark is a designation that can be applied to a particular server. It has no inherent effect, but abilities can refer to it.
- a.linkThere is only ever a single server designated as the mark, and all cards that refer to a player's mark share the same designated server.
- 10.11.2.linkIf a player is instructed to "identify your mark", determine if any server is currently designated as the mark. If there is no mark, a random central server becomes the mark for the remainder of the turn.
- a.linkThe random central server can be selected by any method, as long as there is an equal probability to select each of the 3 central servers (HQ, R&D, and Archives). Recommended methods include designating 1 card from outside the game to represent each server, shuffling those 3 cards, and drawing 1, or designating an equal number of faces of a die to represent each server and rolling that die.
- 10.11.3.linkIf a server is already designated as the mark, an instruction to "identify your mark" does nothing. The mark is immutable for the remainder of the turn.
- 10.11.4.linkThe designation of a server as the mark is treated as a lingering effect that expires at the end of the turn. When the effect expires, there is no mark until another instruction to "identify your mark" resolves.
- 10.11.5.linkWhen a condition checks a game property related to a player's mark, it only checks from the moment that server was designated as the mark.
- Example: The Runner has no mark and plays Jailbreak to make a run on HQ. When the run is successful, they draw Virtuoso with Jailbreak's ability. The Runner continues their turn by installing Virtuoso and playing Carpe Diem. If Carpe Diem's instruction to "identify your mark" results in HQ becoming the mark, the subsequent run it allows will meet the trigger condition for Virtuoso's third ability if it is successful. Even though there was a successful run on HQ earlier in the turn, HQ was not designated as the mark at that time, so the run made with Carpe Diem is the first time the Runner makes a successful run on their mark this turn. The Runner will access 1 additional card when they breach HQ.
Sabotage can be quietly working to undermine a Corp from the inside, organizing protest action, sinking a transport ship, or simply inspiring others to spread the actions further. An act of sabotage at just the right moment can severely limit the Corp's options and force them into making difficult decisions.
- 10.12.1.linkSome Runner card abilities sabotage the Corp. An instruction to "sabotage N" directs the Corp to trash N cards collectively from HQ and the top of R&D.
- 10.12.2.linkTo resolve a sabotage effect, the Corp chooses which cards to trash from HQ and determines the remaining number of cards to be trashed from the top of R&D. Then, all of those cards are trashed simultaneously
- a.linkCards trashed by a sabotage effect enter Archives facedown.
- b.linkThe Corp cannot look at cards trashed from R&D by a sabotage effect until after making all decisions for the resolution of that effect.
- 10.12.3.linkIn resolving a "sabotage N" effect, the Corp may be required to trash cards from a certain zone if there are not enough cards in the other zone.
- a.linkIf there are fewer than N cards in R&D, but at least N cards total in HQ and R&D combined, the Corp must choose enough cards to trash from HQ such that the remaining number of cards to be trashed from the top of R&D is equal to or less than the actual number of cards in R&D.
- b.linkIf there are fewer than N cards in HQ and R&D combined, the Corp trashes all cards from HQ and all cards from R&D.
- Example: The Runner uses Esâ Afontov: Eco-Insurrectionist's ability to sabotage 2. The Corp has 2 cards in HQ and 30 cards in R&D. The Corp can choose not to trash any cards from HQ and trash 2 cards from the top of R&D; choose 1 of the 2 cards in HQ and trash that card and the top card of R&D; or choose and trash both cards from HQ.
- Example: The Runner uses Chastushka's ability to sabotage 4. The Corp has 5 cards in HQ and 2 cards in R&D. The Corp must choose at least 2 cards in HQ to be trashed, so that the total number of cards trashed is 4.
- Example: The Runner uses Chastushka's ability to sabotage 4. The Corp has 2 cards in HQ and 1 card in R&D. The Corp must trash all cards from HQ and R&D.
- 10.13.1.linkA bid is a number of credits that a player secretly chooses to spend as part of resolving an ability. Some effects instruct only a single player to bid, while other effects require both players to bid simultaneously.
- 10.13.2.linkPlayers select their bids in secret. This can be accomplished by writing down a number, by hiding a number of credit counters in a closed fist, or by any other unambiguous method.
- 10.13.3.linkA player cannot bid a number of credits they are unable to spend. Players can always bid 0[c].
- Example: The Runner has no credits in their credit pool and 1 credit hosted on Fencer Fueno when they make a successful run on a server with Adrian Seis rezzed in its root. When the ability on Adrian Seis resolves, the players play a Psi Game, which requires them both to bid 0, 1, or 2[c]. In this case, the Runner cannot bid 2[c], as they are not able to spend that number of credits. They can, however, bid 1[c], as they will be able to spend the credit from Fencer Fueno to pay for that bid.
- Example: The Runner encounters RSVP and its subroutine resolves. Later in that run, they are required to bid credits by another ability. Since the effect of RSVP's subroutine prohibits the Runner from spending credits, they must bid 0[c].
- 10.13.4.linkAfter all bids are selected, the ability that called for the bids continues resolving. Players will later be instructed to reveal their bids. Each player must spend a number of credits equal to their bid as soon as the bid is revealed.
- a.linkSpending credits for a revealed bid is not a conditional ability and does not wait for a checkpoint or priority window after revealing the number of credits bid.
- b.linkSpending credits for a bid counts as paying a nested cost. See section 1.16.
- c.linkIf both players are bidding and a player has multiple sources of credits available from which to pay for their bid (see rule 1.10.3c), that player chooses how to pay after learning the number of credits their opponent bid. If both players have multiple ways to pay for their bids, first the active player chooses how to pay, then the inactive player chooses how to pay. In either circumstance, the credits are spent simultaneously.
- 10.13.5.linkSome older cards direct players to "secretly spend credits" without reference to bidding. These abilities still follow the rules for bidding. Trigger conditions based on players "secretly spending credits" or "revealing secretly spent credits" are met at the next checkpoint after bids are revealed and paid for.
- 10.13.6.linkPsi Games
- a.linkA Psi Game is a bidding contest in which the outcome depends on whether the number of credits each player bid was the same or different. The instruction "Play a Psi Game." encompasses both bidding and revealing bids.
- b.linkWhen playing a Psi Game, each player can bid 0[c], 1[c], or 2[c].
- c.linkPlaying a Psi Game is handled as a single instruction. After both players have selected a bid for a Psi Game, they immediately proceed to reveal and spend their bids. There are no checkpoints during this process until after both players have paid for their bids.
- d.linkIn an ability that calls for a Psi Game, subsequent instructions will depend on the outcome of the Psi Game. The condition "if the bids match" is satisfied if the Corp and Runner bid the same number of credits. The condition "if the bids differ" is satisfied if the Corp and Runner did not bid the same number of credits.
- 11.1.1.linkThe following pages contain quick reference guides for the main timing structures in the game. When initiating a new timing structure, begin at the first numbered step and proceed through the structure sequentially, unless instructed to move to a different phase or step.
- 11.1.2.linkThese guides are intended to serve as shorthand references only; for comprehensive rules relating to each timing structure, see the accompanying rules sections.
- Draw Phase
- The Corp gains allotted clicks.
- Paid ability window: (P) (R) (S).
- The Corp's recurring credits refill.
- The Corp's turn begins.
- The Corp draws 1 card.
- Action Phase
- Paid ability window: (P) (R) (S).
- Does the Corp have unspent clicks?
- If no, go to (3).
- If yes, the Corp takes an action.
- Return to (a).
- Discard Phase
- The Corp discards cards.
- Paid ability window: (P) (R).
- The Corp loses unspent [click].
- The Corp's turn ends.
- The Corp's turn is complete, and the game moves to the Runner's turn.
- Action Phase
- The Runner gains allotted clicks.
- Paid ability window: (P) (R).
- The Runner's recurring credits refill.
- The Runner's turn begins.
- Paid ability window: (P) (R).
- Does the Runner have unspent clicks?
- If no, go to (2).
- If yes, the Runner takes an action.
- Return to (e).
- Discard Phase
- The Runner discards cards.
- Paid ability window: (P) (R).
- The Runner loses unspent [click].
- The Runner's turn ends.
- The Runner's turn is complete, and the game moves to the Corp's turn.
- Initiation Phase
- The Runner announces the attacked server.
- The Runner gains bad publicity credits.
- The run begins.
- Is there ice protecting server?
- If yes, go to (2).
- If no, go to (4).
- Approach Ice Phase
- The Runner approaches ice.
- Paid ability window: (P) (R) and ice can be rezzed.
- Is the approached ice rezzed?
- If yes, go to (3).
- If no, go to (4).
- Encounter Ice Phase
- The Runner encounters ice.
- Paid ability window: (P) and subroutines can be broken.
- Are there unbroken subroutines to resolve?
- If yes, the Corp resolves the next one.
- If no, go to (e).
- Return to (c).
- Go to (4).
- Movement Phase
- If the run got here from (2) or (3), the Runner passes ice.
- Paid ability window: (P).
- The Runner may jack out.
- The Runner moves 1 position inward, if possible.
- Paid ability window: (P) (R).
- Did the Runner move to a new position?
- If yes, go to (2).
- If no, go to (g).
- The Runner approaches the server.
- Go to (5).
- Success Phase
- The run is declared successful.
- The Runner breaches the attacked server.
- Go to (6).
- Run Ends Phase
- Close or resolve priority windows from before "end the run".
- The Runner loses unspent bad publicity credits.
- If applicable, the run is declared unsuccessful.
- The run is complete.
- The breach begins.
- If breaching Archives, facedown cards in Archives are turned faceup.
- If breaching HQ or R&D, determine how many accesses from Corp's hand or deck.
- Are there candidate cards remaining to access?
- If yes, the Runner chooses a candidate.
- If no, go to (7).
- The Runner accesses the chosen card.
- Return to (4).
- Breaching the server is complete.
- The card is accessed.
- The Runner may trash the card or use another mid-access ability.
- If the card is an agenda, the Runner steals it.
- Access is complete.