Recurring Credit Cards are only partially implemented

[justinliew]

Most if not all of the recurring credit cards are only partially implemented. I believe this is because there is no mechanism to filter those recurring credits to specific uses (ie. for using fracters, for rezzing ice).

[justinliew]

I can try to take this on as my first task unless there are any objections. I think it would be a good starter task to get me acquainted with the code and how the card definitions work. I'll definitely ask questions as they come up.

[nealterrell]

That is indeed the reason! This sounds like a challenging task but definitely doable, and will very much help you learn the code :).

[justinliew]

My thought is to break the recurring credit usage into cases, and then deal with each case separately. From all the recurring credit cards, the following categories surfaced:

Runner:
Credits for installing (programs, hardware, virus only)
Credits for using cards (icebreakers, specific icebreaker types, hosted program)
Credits for using during run (anywhere, on HQ)
Credits for playing events (any, run only)
Credits for using traces
Credits for removing tags
Credits for trashing (anything, assets only)

Corp:
Credits for using traces
Credits for advancing cards (anything, ice, in specific server)
Credits for rezzing ice
Credits for installing (anything, in a specific server)

Question: Can anyone think of a situation where a player would NOT want to use their recurring credits first before regular credits? I feel like we could automate this by always using recurring credits for a specific category if they are available, and then deduct from regular pool after that. If we think players might want to micromanage which credits get used, then we'll likely need UI entries for every case. I could see the install case being challenging since it's a click to auto install/deduct, so there'd be new UI flow around that.

Thoughts?

[nealterrell]

I can think of few times that recurring credits should not be used automatically:

1. Spending stealth credits for icebreaker abilities that don't require stealth credits. I would not necessarily want to use Cloak to pay for Refractor's "break 1 code gate subroutine" ability if I knew there was another code gate coming up that I needed to boost Refractor for.
2. I might not use recurring credits to rez cards during an Account Siphon run, as that might leave me with more credits for the Runner to siphon and double up on. (I would rather spend 3 of my 5 real credits to rez some ice rather than the 3 credits on The Root.)
3. I would certainly want to prioritize which card provides the credit I'm spending in many situations... prioritize Lockpick over Cloak for using Refractor, prioritize Because We Built It over The Root for advancing ice, Paricia over Whizzard for trashing assets, etc.

This is sounding more difficult :). An hierarchical categorization might be needed for number 3... spend credits under :trash :assets before credits under :trash if trashing an asset, etc. I'm not sure that 1 and 2 could be automated.

Keep thinking about a design. If you want to start with something related but a little easier, we (devs) have casually brainstormed about how to implement Bad Publicity's credit in a way that would tie nicely into Stimhack, and could start the foundation for this system. The idea we've tossed around is to set a variable inside @state [:run :run-credit] when the run starts, equal to corp's bad publicity; then change (pay) to use those credits first. A UI change would show the run-credits in orange next to the real credits.

[justinliew]

Thanks for the feedback, Neal. Your points definitely convince me that we shouldn't automate any recurring credits. These use cases definitely point to instances where a player would be frustrated if we automatically spent credits on their behalf.

I'll look at Stimhack and Bad Pub and keep thinking about recurring credits, as I think you're right; a lot of these are related and it would be good to think about how they might tie together.

[justinliew]

On a related note, how fully implemented are Stimhack and Bad Pub separately?

Stimhack seems to give the 9 creds but I can't see where/if it removes unused credits.
Bad Pub is set/retrieved but I can't see where/if it's used.

Bad Pub seems like a good straight forward starting point for recurring credits.

[nealterrell]

You've answered your own question: Stimhack does not remove credits, and bp credit is completely manual.

[MasterAir]

I actually quite like the way jinteki.net handles stealth credits. It's much easier to play a stealth deck on jinteki.net than it is on octgn (where recurring credits are used automatically).

I think that Bad Pub and stimhack are things that could definitely be improved though.

My thoughts about both is that a dummy card could be installed for the duration of a run with either Bad Pub or 9 credits respectively that can be used like recurring credits.

As a related point, the feature I would most like to see added is a game state editor, to fix mistakes made by either player. Being able to add/remove tokens from cards would be really handy.

Edit: Neal's suggestion about BP is better than mine. Ignore me...

[t-lor]

I think automating recurring stealth credits is gonna be hard. And dont even mention blackat where u have to chose if u use a normal or stealth cred. The current implementation might not be perfect, but works pretty wel imho.

On the other hand. Automating scrubber and wizzard doesnt sound to hard. Cant imagine a case where u wouldnt want to use rec. cred first to trash something.

[MasterAir]

There are a bunch of edge cases where you would want to use your credit pool even with whizzard/scrubber.

I think it's dangerous to automate recurring credits until you can easily put them back so you can choose to not use them retroactively.

• there's a Tollbooth somewhere you know about/think you know about - you want to reduce your credit pool to below 3 creds by trashing something.
• Theophilius - the edge case machine.
• Nasir - the other edge case machine.
• Perhaps Order of Sol.

I know 95%+ of the time you're going to want to use the recurring credits, but I actually think automating them will be detrimental to the UX of jintiki.net.

[justinliew]

I'm definitely going to make them manual. Same with Bad Pub and Stimhack credits. Ideally I'll make the defaults in the choice prompt max out the values so by default it should be quick to confirm credits, but then allow for manual tinkering if necessary. Sounds good?

[justinliew]

Here's what I'm thinking for recurring credits. Since this is my first big-ish feature I thought I'd put my thoughts in the issue in case people see flaws or better ways to do this. I'm going to give it a run for one of the easier cases where there's existing UI I can co-opt.

Currently the recurring credits are just a map of the :recurring keyword to a value.
{:recurring 1}

My plan is to change this to point to another map containing the following:
:types - a vector of types.
:count - the number of credits.

Here's what it might look like generally:
{ :recurring {:types [:type1 :type2 [:subtype2]] :count 3}}

Then in places we use these recurring credits, we can check the relevant player's hand for the specific type of recurring credit that may exist and augment the UI accordingly to allow for manual spending.
The per-turn refresh will work the same way it does now; by refreshing the :rec-counter property at the the start of the turn.

Here are some potential examples:

"Dedicated Server"
{:recurring {:types [:rez] :count 2}}

"Net Police"
{:recurring {:types [:trace] :count (effect (set-prop card :rec-counter (:link runner)))
:effect (effect (set-prop card :rec-counter (:link runner)))}

"Primary Transmission Dish"
{:recurring {:types [:trace] :count 3}}

"Net Celebrity"
{:recurring {:types [:run] :count 1}}

"Cyberfeeder"
{:recurring {:types [:use [:icebreakers] :installing [:virus]] :count 1}}

"Cybsoft MacroDrive"
{:recurring {:types [:install [:programs] :count 1]}}

"Dyson Fractal Generator"
{:recurring {:types [:use [:fracters]] :count 1}}

"Cloak"
{:recurring {:types [:use [:icebreakers] :stealth] :count 1}}`

Here's the full list of client changes needed:

Credits for installing - will need new UI since this is done automatically.
Credits for using cards - can just add to the existing UI.
Credits for using during run - potentially the run arrow being proposed.
Credits for playing events - will need new UI since this is done automatically.
Credits for using traces - can just add to the existing UI.
Credits for removing tags - add to the main UI.
Credits for trashing - can just add to the existing UI.

Credits for using traces - can just add to the existing UI.
Credits for advancing cards - can just add to the existing UI.
Credits for rezzing ice - will need new UI since this is done automatically.
Credits for installing - will need new UI since this is done automatically.

[JoelCFC25]

Justin, do you want an invite to the developer Slack that was started?

On Wed, Aug 5, 2015 at 1:28 PM, Justin Liew [email protected]
wrote:

Here's what I'm thinking for recurring credits. Since this is my first
big-ish feature I thought I'd put my thoughts in the issue in case people
see flaws or better ways to do this. I'm going to give it a run for one of
the easier cases where there's existing UI I can co-opt.

Currently the recurring credits are just a map of the :recurring keyword
to a value.
{:recurring 1}

My plan is to change this to point to another map containing the following:
:types - a vector of types.
:count - the number of credits.

Here's what it might look like generally:
{ :recurring {:types [:type1 :type2 [:subtype2]] :count 3}}

Then in places we use these recurring credits, we can check the relevant
player's hand for the specific type of recurring credit that may exist and
augment the UI accordingly to allow for manual spending.
The per-turn refresh will work the same way it does now; by refreshing the
:rec-counter property at the the start of the turn.

Here are some potential examples:

"Dedicated Server"
{:recurring {:types [:rez] :count 2}}

"Net Police"
{:recurring {:types [:trace] :count (effect (set-prop card :rec-counter
(:link runner)))
:effect (effect (set-prop card :rec-counter (:link runner)))}

"Primary Transmission Dish"
{:recurring {:types [:trace] :count 3}}

"Net Celebrity"
{:recurring {:types [:run] :count 1}}

"Cyberfeeder"
{:recurring {:types [:use [:icebreakers] :installing [:virus]] :count 1}}

"Cybsoft MacroDrive"
{:recurring {:types [:install [:programs] :count 1]}}

"Dyson Fractal Generator"
{:recurring {:types [:use [:fracters]] :count 1}}

"Cloak"
{:recurring {:types [:use [:icebreakers] :stealth] :count 1}}`

Here's the full list of client changes needed:

Credits for installing - will need new UI since this is done automatically.
Credits for using cards - can just add to the existing UI.
Credits for using during run - potentially the run arrow being proposed.
Credits for playing events - will need new UI since this is done
automatically.
Credits for using traces - can just add to the existing UI.
Credits for removing tags - add to the main UI.
Credits for trashing - can just add to the existing UI.

Credits for using traces - can just add to the existing UI.
Credits for advancing cards - can just add to the existing UI.
Credits for rezzing ice - will need new UI since this is done
automatically.
Credits for installing - will need new UI since this is done automatically.

—
Reply to this email directly or view it on GitHub
#362 (comment).

[justinliew]

I would love to, please!

[JoelCFC25]

Let me know at jkoepp -at- gmail.com so I can get your email for sending it!

On Thu, Aug 6, 2015 at 10:06 AM, Justin Liew [email protected]
wrote:

I would love to, please!

—
Reply to this email directly or view it on GitHub
#362 (comment).

[mtgred]

Sent.