Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add pity to card upgrades #7

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

yaspo
Copy link
Contributor

@yaspo yaspo commented Sep 1, 2024

Implemented this as a way to propose its workings, I think the results are solid

  • Added Pity column to the Card entity
  • Pity gets increased by 1 every time a card downgrades
    • Pity increases the chance to upgrade a card by 7%, capped at 80% maximum
    • Pity decreases the chance to downgrade a card by 7%, capped at 30% minimum

basically applying an "what doesn't kill you makes you stronger" philosophy to limit extreme sequences of bad luck, without tampering with regular fail chains

tested through simulating upgrades from badly damaged to mint, the system has the following effects:

Upgrades No Pity Pity
Mean 1750 1622
Median 1350 1350
Std Dev 1092 833

Aka it mainly aims to lower the standard deviation, as most of it is built up in the upper end due to Mean - Std Dev going far below the minimum cost to upgrade
Below are 2 graphs for comparison across the board

No Pity (current)
firefox_cHGPEGhpcy

Pity (implemented in this PR)
firefox_x68rocqryS

`Upgrading the \`${card.mapper.username}\` card from from **${condition.id}** to **${condition.nextUpgrade.id}** has a ${Math.floor(condition.upgradeChance * 100)}% chance of success.`,
condition.previousUpgrade ? `If the upgrade fails, there is a 50% chance the card will be downgraded to **${condition.previousUpgrade.id}**` : `If the upgrade fails, nothing will happen.`,
`Upgrading the \`${card.mapper.username}\` card from from **${condition.id}** to **${condition.nextUpgrade.id}** has a ${Math.floor(upgradeChance * 100)}% chance of success.`,
condition.previousUpgrade ? `If the upgrade fails, there is a ${Math.floor(downgradeChance * 100)}% chance the card will be downgraded to **${condition.previousUpgrade.id}**` : `If the upgrade fails, nothing will happen.`,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the pity factor should be advertised anywhere

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it displays the odds and the odds change, felt like basic transparency

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd still prefer not to give it away, ppl should not really be aware of the pity system

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's a fair standpoint, can remove when we've figured it all out

const success = random < condition.upgradeChance;
const downgrade = !success && Math.random() < 0.5;
const success = random < upgradeChance;
const downgrade = !success && Math.random() < downgradeChance;
if (success) {
currentCard.condition = condition.nextUpgrade;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pretty sure pity should be reset on success

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typical pity systems would do that, but I don't think it would fit here

the main killer in the upgrade system is how much it can fluctuate, in 10% of cases your card downgrades 3+ times by going from good to poor and back on repeat for example
so resetting on success would be a bit pointless since it'd continue to allow those sequences to escalate costs anyway

at that point just reducing overall costs or reducing chance to downgrade in general would be more effective changes, which people would probably also be happy with

@@ -75,6 +75,9 @@ export class UpgradeCommand extends Command {
}

const upgradePrice = condition.upgradePrice * (card.foil ? 2 : 1);
const pityFactor = 0.07 * card.pity;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably not be linear, rather something that slowly approaches but never reaches 1

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can agree with making it non-linear, though making it "slowly" approach anything seems a bit pointless since most upgrade sequences currently don't even reach 10 total rolls
; this isn't like spending 100 gacha pulls to get your guaranteed SSR character

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about this? It's pity / (pity + 8)

image

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comparison with previous formula

image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

simulated this and got this, it going up steeper early has a stronger effect it seems
but having the average coincidentally hover around the price of a superdrop seems rather neat

Costs
Mean 1501
Median 1300
Std Dev 713

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants