Hi all! I got a message about some changes to the way jinteki.net works and the offer of a related article potentially mentioning a previously unscooped card - so of course I said yes! So if you absolutely can't wait til tonight (UK time) for scoops then my guest writer has got you covered... take it away, Presheaf!
With the release of Downfall, there has been a shift towards making abilities optional if possible. This means that we avoid illegal game states caused by players forgetting to trigger an ability they were required to, which is good for IRL play. FFG may have come to a similar realization while working on Kitara, as evidenced by Friday Chip and Consume.
However, Jinteki does not face the same constraint as the game engine can actually ensure players do not forget mandatory abilities. We have therefore introduced a new feature in the game engine called autoresolve. Much like how Friday Chip and Consume notify you that you can click them to toggle automatically adding counters, some cards with Yes/No prompts now have a new ability which lets them toggle between three behaviors – always click yes, always click no, and always ask. To avoid any nasty surprises and annoying players who prefer always explicitly choosing to saving some clicks, the default is the old behavior of always asking.
Currently, we have only written methods for doing this for prompts asking Yes/No specifically. This is because such prompts are common enough to have special helper methods in the game engine, meaning it was easy to make the prompt resolution function displaying these prompts first check if the card whose effect caused the prompt has a special flag set, and if so use that flag to make a choice without asking the user. We can therefore add autoresolve functionality to a card by giving it an ability setting this flag in itself.
As an example of this, consider Direct Access, a new Runner Event card from Ashes, with the following card text: "While Direct Access is resolving, each player's identity text box is blank. Make a run. When that run ends, you may shuffle Direct Access into the stack." I’ll go into the reshuffle ability later, but let’s first take a look at what the card actually does for the game, and how it can be implemented on Jinteki.
The effect of Direct Access is similar to Employee Strike, allowing you to contest Mti’s or Replicating Perfection’s remote without taking their powerful ID abilities into account. Unlike Employee Strike, the Runner needs to give up their own ability for the duration of the run to do so, and the Corp gets their ID back once the run is over. Although it saves you a click compared to playing Employee Strike and then running, which can be stronger against Replicating Perfection in particular, it seems to be an overall weaker Employee Strike. Hopefully, it will allow for counterplay against strong IDs without being as oppressive as Employee Strike or forcing the swingy current war, and I am very much looking forward to its release.
Implementing this card on Jinteki.net was actually relatively straightforward. As Cerebral Static and Employee Strike already existed, other devs had made helper methods for blanking and unblanking an ID. So in principle, Direct Access can be implemented by blanking each ID at the start of the run, then once it ends unblanking both.
The one thing I needed to account for was what happens if e.g. Cerebral Static is already in play. Currently, Cerebral Static blanks the Runner ID when entering play, and unblanks it when leaving play. This has worked just fine until now because it is the only way a Runner ID can be blanked in the game. However, if we used the naive implementation of Direct Access, this would mean the Runner ID would be unblanked when the run was over, even if Cerebral Static was in play. Oops. The reverse situation of Employee Strike being in play seems less common, but could conceivably happen if you are Nasir or Apex and are playing Direct Access mainly to blank your own ID.
My first idea for fixing this was having Direct Access check whether either ID was blank before blanking them, and if so not bother unblanking them. This seems to work at first glance, but it is a bit of a hack, and fails to work properly if we steal an agenda mid-run, which then means Cerebral Static is trashed and unblanks the Runner ID too early. This is a rare occurrence indeed, but if I’m going to go the trouble of writing a messy hack, it’s nice if it at least always works.
The solution I ended up with was simpler and also more robust, and involved slightly changing the way blanking an ID works. Now, each call to the enable-/disable-identity function decrements/increments the number-of-times-blanked counter, and only actually goes to the trouble of turning all their effects on/off if this makes the counter go to/from 0. Making this change, the naive implementation of Direct Access works just fine, as now it just adds a new ‘layer’ of blanking, and the game engine handles the necessary enabling/disabling of stuff dependent on whether there already was a layer there or not.
The autoresolvable effect on Direct Access is the reshuffling into deck. This is not something you literally always want to do, but in most cases where you bother playing the card, it is likely that you want to do it. So if you want to, you can click Direct Access while resolving and toggle autoresolve on it, and it should shuffle itself back into the stack after the run without prompting you.
A consequence of the implementation is that if you have multiple copies of a card, they can have separate autoresolve settings. Knowing this lets you perform an admittedly unspectacular magic trick with Direct Access. If you have a copy in hand, play it and set it to auto-shuffle itself into the deck. Then, later in the game, if you draw a Direct Access from your deck, you can tell whether the copy you drew was the card you played earlier or not by playing it and seeing whether it autoresolves. If it does, it has the autoresolve flag set, so it is the card you played before, and if it doesn’t, it’s a new copy. Magic!
Another use for autoresolve is for making playing with narrow use cards slightly less annoying. If you have Whistleblower installed, for example, you will be prompted on literally every successful run about using it. That gets old fast when you’re just running Archives for Datasucker tokens, so you can set it to always choose “No”, and change that setting on the run you think you may want to use it. Autoresolve can currently be set for the following cards:
- Amani Senai
- Marilyn Campaign
- Friday Chip
- Find the Truth
- RNG Key
- Laramy Fisk
- Aeneas Informant
- Direct Access
To use it, click the card and trigger their new ability, which will open a prompt asking you which setting you prefer. Note that in every case, the only prompts you can currently make autoresolve are Yes/No prompts. This means, for example, that you can make the CtM or Amani Senai trace always fire, but you can’t make it always bid 0.
As a small precaution, note that making the game choose for you can lead to nasty surprises. For example, if your opponent notices that you instantly click ‘Yes’ on the 419 prompt, they may infer that you have autoresolve set, and exploit this by installing a Psychic Field. Or you may end up playing yourself by setting Whistleblower to not bug you, and end up forgetting to change this setting on the run on which you want to use it.
A notable omission here is Security Testing, which many players playing IRL will handle by e.g. saying “If I say nothing, I mean for this to go on Archives”, which is effectively what we want autoresolve to accomplish. Sadly, as this is not a Yes/No prompt, it cannot be handled by the existing autoresolve system, although this may change in the future if autoresolve proves useful and there are enough game effects for which adding a default behavior makes sense.
Well I hope you read that article if you play on jinteki.net rather than just look at the picture because it answers a lot of potential questions about this change... and I think now is a good time for all of us to show some love to the jnet development team, because they do some fantastic work! If you want to help out, check the #jinteki_net channel on Stimslack, or go to the relevant github page for details.
I'll be back in about 9 hours with the full list of Runner cards so rather than urge you to "be running", until then...