fbpx

Elevation Rules Update

Elevation’s release on April 24th will be accompanied by an update to the Netrunner Comprehensive Rules (CR) as well as updates to the official text of about 100 existing cards.

I’m Jamie, Rules Manager for NSG, and I’m here on behalf of the Rules team to talk about what you can expect from those updates. We’re going to get into things in a fair bit of detail, but there will be a short recap at the end. Let’s start with some news that’s been highly anticipated by rules enthusiasts.

Completing “NCIGS” Reform

With this release, the “No Change in Game State” (NCIGS) rule is finally going away! For those unfamiliar, this was a catch-all rule that tried to stop players from using abilities at times that don’t make sense. It did this by requiring that an ability’s effects must have the “potential to change the game state” in order for a player to trigger that ability. 

The particular way that this requirement was checked has a lot of unintuitive consequences, and over the past several years we’ve been gradually working to make the game less reliant on this subsystem. You can find more details on NCIGS and the changes that have happened up to now in this article from last year, where we announced the previous stage of reform.

Most cases where abilities need to have restricted timing have already been codified through interrupts (which can only be used when they are relevant to an imminent instruction’s expected effects), interface abilities (which require an encounter to be in progress and their source icebreaker to match the strength of the encountered ice), and other restrictions that are explicitly visible in the ability’s text. When working on this project, we knew that some implicit restrictions would still be needed, but we wanted to ensure that the new rules replacing NCIGS would minimize how many new principles players would need to learn for understanding how cards work, make those principles easy to understand, and avoid ‘gotchas’ where a card can’t be used in ways it would be intuitively expected to work.

After thoroughly reviewing the entire Eternal card pool, we are pleased to report that we have a set of restrictions we are happy with. The rules replacing NCIGS will live in the paid abilities section of the CR, and they stipulate that:

  • You can only use paid abilities that break subroutines (like the one on Botulus) during an encounter, even if they don’t have the interface flag.
  • You can only use paid abilities that refer to ice the Runner is encountering (like the paid abilities on Leech and Arruaceiras Crew) during an encounter.
  • You can only use paid abilities that refer to ice the Runner is approaching while a piece of ice is being approached.1
  • Additionally, if a paid ability refers to the Runner encountering, approaching, or breaking subroutines on a piece of ice with specific characteristics, such as having a particular subtype, the ability can only be used if the ice has those characteristics.2

We settled on these cases because the timing restrictions they impose generally only come up for abilities that don’t make sense without them. Restrictions that come up more broadly will still be written out explicitly.

The most notable example of a case where we didn’t add an implicit rule is with abilities that can only be used during a run. Some paid abilities, like the one on Transport Monopoly, only make sense in the context of a run, and could arguably benefit from a rule like this to shorten their text. But plenty of other abilities, like those on House of Knives and Arissana Rocha Nahu, actually need an explicit restriction, because they do make sense outside of a run and would be functionally different without the restriction. Additionally, it’s fairly common for “use only during a run” abilities to be further restricted based on the attacked server. Abilities that can only be used during a run will continue to have this restriction explicitly written out.

If an ability only makes sense in context, why does it matter whether a player can use it outside of that context? This primarily comes up when the player has a way to benefit from just paying the ability’s trigger cost. Trashing cards is the most well-known example of this, both historically and in the modern game, but other costs like taking or removing tags can matter as well. Despite its flaws, NCIGS successfully did the job of preventing unintended exploits with cases like this. While we’re fine with this rules update creating minor functional changes—even happy about it in cases like Simulchip—we don’t want to drastically change what’s possible.

Fortunately, only three cards in Standard3 have paid abilities with costs that are exploitable in this way and effects that aren’t covered by the new rules:

  • As mentioned a moment ago, Simulchip is a case where NCIGS had a particularly negative impact: the rule wants to see that a potential target exists for Simulchip’s install effect, so it restricts Simulchip to only be usable if there is a program already in the heap before the Runner pays the costs of its ability. But often the Runner just wants to reinstall the same program they are about to trash to pay Simulchip’s additional cost. It’s unintuitive that the presence or absence of some other program in the heap affects whether this is allowed. With NCIGS going away, this will no longer be an issue! It is now legal to trigger Simulchip’s ability regardless of whether your heap already has a program in it. There will not be a text update for this card.
  • B-1001 is written in a way that would now allow the Corp to arbitrarily remove tags when there is no run in progress. This is not a use that we might naturally expect from reading the card, and it has significant functional implications. Accordingly, we are updating the official text of B-1001 so that instead of “You cannot use this ability during a run on this server.” it reads “Use this ability only during a run on another server.”
  • Cybersand Harvester falls somewhere in between the previous two cases. Under NCIGS, its paid ability was only legal to use when there was at least 1 hosted credit for the Corp to take. With that requirement gone, Ob Superheavy Logistics now has more freedom to use the ability to search for a 1-cost card. We could add an explicit restriction on the card to avert this change, but that text would be unlike anything that appears elsewhere in the cardpool, rather than a standard clause like “Use this ability only during a run”. And the presence of the restriction would potentially be confusing to players looking at the official text of Cybersand Harvester without the Ob interaction in mind. Fortunately, it turned out that the interaction does not cause significant balance problems, so we are not changing the card’s text. The Corp can now trash Cybersand Harvester whenever they want.

Run Timing and the Initiation Phase

Suppose we’re in the middle of a run. The Runner passes a piece of ice, and moves to the position of the next ice protecting the server. As the Runner progresses through the phases of the run to get past that ice, players have a paid ability window before and after every major step of the process: before the Runner approaches the ice, while the Runner is approaching the ice, during the encounter with that ice, and after they pass it. Some of those windows also allow the Corp to rez assets and upgrades that might affect whether the Runner can get through or what consequences they suffer.

Now suppose we’re at the beginning of a run. The first piece of ice the Runner has to deal with mostly follows the same process, but there’s a notable missing piece: since we don’t go through the Movement Phase until the Runner passes the ice, we don’t ever resolve step 6.9.4e for that position. In other words, there is no paid ability or rez window before the Runner approaches the first piece of ice protecting a server. If the Corp wants to rez a card before the approach begins, they need to anticipate the Runner and act before they even take an action to run. Even if the Corp can predict the Runner’s plans exactly, rezzing a card ahead of time gives away information and will likely change those plans.

From a rules point of view, the worst thing about this asymmetry is that it breaks the expectations of players who aren’t deeply familiar with the timing chart. Complex interactions are one thing, but for the most part, teaching a player that you can rez cards any time during a run, except during an encounter or after the Runner approaches the server, ought to be a sufficient level of detail.

But before we start trying to fix theoretical problems, do we actually care about rezzing cards before the Runner approaches ice? What kind of abilities would make this important?

Mitra Aman preview

⬩ Mitra Aman

Jinteki Upgrade: Clone

Rez cost: 0 – Trash cost: 3 – Influence cost: 2

Whenever the Runner approaches a piece of ice protecting this server, you may trash this upgrade. If you do, gain 3credit and you may swap the ice being approached with a piece of ice from Archives or HQ.

Spring-loaded minds, kept in suspension to be launched into the net at any incursion.

Illustrated by Oliver Morit

Historically, trigger conditions that look for the Runner to approach a piece of ice have been very rare. But there’s a negative feedback loop here: the ‘rez before the run’ timing and the incentive structures it creates discourages these kinds of effects from being designed, or from surviving very long in playtesting when they do come up, and the lack of cards that care about the issue make it hard to justify changing the rules to address the problem. But this time, Jinteki wasn’t willing to let go.

The Development and Rules teams worked together on many different versions of Mitra Aman, trying to find an ability that would suit the needs of the Jinteki upgrade slot and hit a reasonable power level. Other ways to structure the ability either didn’t work for technical reasons or enabled unacceptable combo plays, so it had to be an “approach ice” trigger condition, but that timing effectively made it unusable on the outermost piece of ice, and that in turn made the card unplayably restrictive.

The timing problem became one of the key obstacles to making this a card we could print with reasonable text. Some versions were given to playtesters with an additional ability to try to let the card rez itself—and naturally, we got feedback along the lines of “What is this ability for? Can’t I do this anyway?” Ultimately, the Rules team identified the underlying problem, and started researching whether it was something we could fix in the rules rather than in the text of this one card.

The solution was to add a paid ability window to the Initiation Phase, bringing symmetry to the way each position is handled during a run. Here are the timing steps you’ll see when the CR update is published:

  1. The Runner announces the attacked server.
  2. The Runner gains bad publicity credits.
  3. The run begins. (Tributary jumps in here!)
  4. The Runner’s position is set.
  5. Paid ability window (P) (R) (Rez Mitra Aman here!)
  6. The Initiation Phase is complete; proceed to the next phase.

Lots of things can happen in a paid ability window, so we needed to make sure to correctly handle a bunch of scenarios without drastically changing how runs work. Note that there is now an explicit step for setting the Runner’s initial position, just as there’s an explicit step in the Movement Phase that moves the Runner from one position to the next. Abilities with “run begins” trigger conditions get to resolve before that step, so effects like Tributary’s ability can still get in front of the Runner, but the paid ability window is after the positioning step. Ice that gets installed during this window will be outward from the Runner’s position, so the Corp can’t use Ob Superheavy Logistics or other tricks to reconfigure the server in ways they couldn’t before. Well, aside from using Mitra Aman itself.

Simplifying Positions

To support these changes and generally make it easier to understand what happens when ice moves around in the middle of a run, we’ve overhauled the rules for positions. Ice positions are now explicit game constructs, with their own checkpoint step to tidy them up.

The positions protecting a particular server are an ordered sequence, but they are not numbered or tied to any fixed reference. If ice comes and goes, there’s no need to define how other ice ‘shifts’, we just maintain the order of each piece of ice relative to the others. The new presentation doesn’t change how any of the practical scenarios function, but we think it makes it easier to reason about what’s happening.

Most importantly, in the new framework, removing ice from the Runner’s position neither ‘collapses’ the server nor sends the Runner to the next position right away. The position itself sticks around until the Runner leaves it via the normal progression of the run.

The final step of the Initiation Phase now has three possible cases to handle in order to correctly send the game to the next phase: 

  • If the Runner has a position that has a piece of ice in it, we proceed to the Approach Ice Phase. 
  • If the Runner has a position that does not have a piece of ice, that means they were assigned a position and then the ice that was there got moved or uninstalled during the paid ability window. The run proceeds to the Movement Phase, where the Runner will go on to move to the next position just as if they had approached and passed a piece of ice. 
  • Finally, if the Runner doesn’t have a position at all, that means there was no ice protecting the server at the time the game tried to set an initial position for them. If there is ice protecting the server now, it doesn’t matter: it got there too late to be in the Runner’s way. The run goes to the Movement Phase and the Runner will go on to approach the server.

A final note for Eternal players: for a server with no ice protecting it, “pass all ice” trigger conditions are met the first time the run enters the Movement Phase. The “pass all ice” trigger condition is not used anymore, with the modern “approach server” trigger condition serving essentially the same function, but some important older cards like Caprice Nisei have “pass all ice” timing. The new paid ability window happens before this trigger condition is met, so it is now possible for the Corp to rez and use an unprotected Caprice Nisei after the Runner begins a run on its server.

The Future of Card Text Updates

The way that card text updates have been communicated for the last few years is less than ideal. The Card Text Updates document is a giant PDF file that nobody uses, and even if you were to use it, it doesn’t include cards where the updates were introduced through a reprint, so it isn’t especially helpful to players that have older versions of cards. It’s time to do away with this obsolete document and make NetrunnerDB the official source for up-to-date card text. That’s already the source players go to in practice, so we are eliminating the extra steps.

The reasons we haven’t made this change before now mostly come down to technical issues. We have recently been working with the NSG Webdev team to create a new workflow for writing card updates, which is now up and running. Our new process closely mirrors the way rules text is written for new cards in development, and allows for more robust scripting to export finalized changes smoothly to NetrunnerDB, as well as making it easier to review past notes and discussions when we revisit a card again.

As mentioned above, the first update using this process will contain about 100 cards, generally aligning to a few categories that are discussed in the other sections of this article.

New Ability Flag: Once per Turn

Some of the most common feedback we’ve gotten from players is that it’s jarring when an ability looks like it’s going to work every time something happens…and then it ends with “Use this ability only once per turn.” This sentence is also pretty lengthy. While we don’t want to bloat the game with too many ability flags—when we inevitably start to see 2 or even 3 flags on the same ability, the front of the paragraph will be getting pretty crowded—it felt worthwhile to make this pretty common restriction cleaner, and Elevation felt like the right time to introduce the change. As you might expect, the new “Once per turn →” ability flag simply means that an ability can only be used at most once during each turn of the game.

Out of the three cards in the set with “Once per turn →” abilities, Topan and LEO Construction have already been revealed. When the third one shows up in a couple of days, take note that it can be used on either player’s turn!

There are no conditional abilities with “Once per turn →” flags in Elevation, but they are an important part of this new standard. All cards with “once per turn” restrictions are getting updates to their official text, including both paid abilities and conditional abilities. This accounts for more than half of the cards receiving text updates with Elevation’s release.

There are just a couple of relevant cards, all long since departed from Standard, that aren’t getting the new flag, because it would change their functionality: most obviously, Kati Jones and Shell Corporation need their “once per turn” restrictions to apply across all abilities on the card. But Tri-maf Contact and Oracle May are written in a way that puts them into the same category: it’s possible (with MCA Informant) to give them another ability that the restriction would need to apply to.

Style Change for End of Turn Abilities

A couple of years ago, we introduced “When your discard phase ends” as a trigger condition. This has exactly the same timing as “When your turn ends”, but was a new alternate phrasing intended to emphasize that abilities using it resolve after the player discards to their maximum hand size. Elevation turned out to have quite a few cards that care about the end of your turn, including one card that really wanted its ability to resolve before the discard step. The natural way to write this timing is “When your action phase ends”, so we’ve added that phrase to the game for the first time.

With the new condition, we are retiring “When your turn ends”. Having two similar-looking conditions that mean the same thing turned out to be confusing for some players, but it would likely cause much greater confusion to have three similar-looking conditions where two of them mean the same thing and the third one is different. With just “action phase ends” and “discard phase ends”, all abilities of this type refer to the same level of the turn structure (phases), and the point of contrast is clearly evident.

In terms of the CR, the only changes here are an added step in both the Runner’s and the Corp’s action phases, calling out the point where “action phase ends” trigger conditions are met, and an update to section 5.4.3 making clear that these abilities still get to resolve after playing a terminal operation.

Due to time constraints, the Elevation card text updates will most likely not be removing “turn ends” phrasing from past cards, except cards that are getting a text update for other reasons.

“Install and Rez” Clarifications

As promised in the last rules article, we’re adding some CR entries to make it more clear how to resolve “install and rez” effects. This set of changes includes 2 new rules in the costs section: a subrule to rule 1.16.3 clarifying that it still applies to costs of 0, and a rule detailing how to resolve a modifier that applies across multiple costs, like the one on Tucana. It also includes a new rule in the installing cards section making explicit that an instruction to “install and rez” a card is resolved by following the procedure to install it, then following the procedure to rez it. Finally, we are updating the text of rule 9.6.5b to be more clear and consistent in describing the precise timing of how conditional abilities check their trigger conditions, and we are attaching some new examples to that rule including an example specifically about Tranquility Home Grid.

Text Updates for Interrupts

Many interrupt abilities have previously received text updates to add the interrupt glyph. We are finishing the job, adding the interrupt ability flag to the remaining abilities that want it. Interrupt abilities nested within another ability, like the conditional ability interrupt on Shred, will continue to be marked by the word “would” rather than an ability flag.

A handful of older cards have “prevent” effects formatted as a static ability. It was unclear how exactly these abilities are applied during an interrupt window. Some cards originally written like this, such as Jesminder Sareen, have already been updated to use a conditional ability interrupt, which fits more cleanly into the modern timing framework. We are updating the remaining static “prevent” abilities in a similar way.

Abilities that prevent a card “from being trashed” are being updated to instead prevent “a player from trashing” the card. This helps make clear that trashing performed by the game (for example, because of uniqueness) cannot be prevented.

Nested Costs with X

The variable X gets used on cards in two different ways: when it appears in a play cost or paid ability cost, like on IP Enforcement or Matryoshka, the value of X is declared by the player paying that cost. There can be restrictions on what values the player is allowed to declare, but it’s ultimately chosen by the player. When X appears outside of a cost, its value is defined by a formula stated on the card.

Nested costs are unusual because they appear in the middle of abilities, and can easily blend in with non-cost instructions. It can sometimes be difficult to tell whether a particular phrase is part of a nested cost or not. So when an X is used in a nested cost, it can be ambiguous whether the value of X is supposed to be chosen by a player or defined by a formula. We are attempting to remove this ambiguity and make it easier to understand how X works by removing player-chosen X from nested costs.

For example, Atman’s first ability currently has a nested cost of X{c}. This is, admittedly, not a particularly confusing case, but it also doesn’t particularly need the X. This ability is being updated to read “When you install this program, you may spend any number of credits to place that many power counters on it.”

Other CR Changes

Some quick hits before we wrap up:

  • We are updating the rules on memory to support the new language used on both sides of Dewi Subrotoputri.
  • We are adding a rule about alternative ways to pay a cost, to support an ability that hasn’t been revealed yet.
  • We are updating the list of subtypes to add unsubstantiated as an identity subtype and deep net as an asset subtype.
  • We are clarifying the exact timing of flatlines due to negative hand size. If a Runner playing Magdalene Keino-Chemutai reaches the discard step with −1 hand size, they will lose the game. They cannot save themself by installing a discarded T400 Memory Diamond before the flatline occurs.
  • Elevation introduces a new keyword mechanic, appearing on four cards. We’re adding rules for it to section 10 of the CR, but that’s all I can say about it for now! The new keyword will not be added to any past cards.

Summary

For most players, the big takeaway from this CR update is that the run timing chart has been updated to add a new paid ability window just before the Runner approaches the outermost piece of ice, allowing the Corp to rez Mitra Aman in time to meet its trigger condition from that approach.

Another important change is that NCIGS is finally gone for good. The new rules replacing it mainly just stipulate that paid abilities involving encounters can’t be used outside of an encounter. This overhaul results in functional changes to Simulchip and Cybersand Harvester, and comes alongside a text update to B-1001 that preserves its existing functionality.

Finally, NetrunnerDB is now the primary source for official card text, rather than just the de facto source. The separate Card Text Updates document will be discontinued from Elevation onwards.

I also talked about the new “Once per turn →” ability flag and some other smaller updates to rules and card text. That’s all I have for you today. Enjoy the rest of preview season, and please do send us your questions about the new cards! As usual, we are compiling FAQ throughout the season, and we’ll be uploading rulings on Elevation cards to NetrunnerDB shortly after release.


Footnotes

1. This case mainly exists for futureproofing. The only card it currently applies to is Project Wotan.

2. Most of the abilities this rule applies to are also constrained by the interface rules: in addition to the strength requirement, this rule says you can’t use Revolver’s interface ability during an encounter with a barrier, and you can’t use Banner’s ability during an encounter with a code gate. But this rule also applies in some other cases, like the bypass ability on Abagnale.

3. For Eternal players: we are also adding “Use this ability only during a run.” to Bio Vault.

Join us in Kota Kalimantan when Elevation releases on April 24th 2025!

Author

  • Jamie Perconti

    Jamie is the Rules Manager for Null Signal Games. They live in Somerville, Massachusetts, where they have a reputation for putting Snare! in every Corp deck. They also work on the Worldbreakers card game as a designer and rules manager.