Popularity and Pity Points #37

Open
opened 2025-05-27 16:50:03 -07:00 by waifu · 4 comments
Owner

Overview

This is a new gameplay mechanic proposal for how we can connect card popularity with a pity system in the game. The goal is to create conscious engagement from players while keeping the system fair, diminish abuse, and get more social interactions.

System Breakdown

🎯 Player Reactions

  • Players can heart-react or like a card only when it appears in a roll.
  • These reactions give them a chance to get randomly selected to receive a pity point.
  • Only one pity point is given per roll.
  • Players must have played the game recently to be eligible.
  • Boosts/repeats/replies and other passive actions do not count.
  • Only deliberate, conscious engagement is rewarded.

🎯 Pity Point Limits

  • Players have a maximum number of pity points they can hold at a time.
  • This creates strategic tension as players must choose carefully what to react to.
  • Prevents “spam-reacting” to everything without consequence.
  • Pity points are personal and cannot be traded.

🎯 Popularity Point System

  • Each card can earn popularity points, which are limited globally.
  • For example: a total of 1000 popularity points exists across the entire game.
  • One card can’t exceed a certain amount (e.g. 100), meaning popularity is a zero-sum system.
  • Popularity is not tied to rarity. A common card can be popular purely through community love.
  • But they are tied to rolling, making it so when a card gets popular it becomes more difficult to get.
  • The popularity landscape will shift over time, keeping the meta fresh.

Open Questions

Strengths

  • Encourages meaningful interaction.
  • Ties social engagement into game mechanics non-exploitative way.
  • Popularity becomes a limited resource, encourages trends.
  • Because popularity is a stat, it means the meta is constantly changing, there could be a sudden change in popularity for a specific card, making it popular, and at the next day, it could become worthless.

Potential Issues

  • Pity RNG: Some players may feel frustrated by lack of rewards even with engagement.

    • Should we add a visible progress tracker? Or “increasing chance” system?
  • Cap Confusion: Players may not realize they're at the pity cap.

    • Maybe a reminder would help.
  • Bandwagoning: Players might only chase popular cards.

    • Should we implement underdog incentives or limited-time boosts for less-popular cards?

Final Thoughts

This is an evolving system proposal, perhaps tied to another kind of pity system, where you get a pity point for a specific character after you roll a set amount of times without getting the card. Balance will be key, but making mechanics that relate to the social aspects of the fediverse has a lot of potential to deepen engagement and give cards emotional/social value.

## Overview This is a new gameplay mechanic proposal for how we can connect **card popularity** with a **pity system** in the game. The goal is to create conscious engagement from players while keeping the system fair, diminish abuse, and get more social interactions. ## System Breakdown ### 🎯 Player Reactions - Players can **heart-react** or **like** a card *only when it appears in a roll*. - These reactions give them a chance to get **randomly selected** to receive a pity point. - Only one pity point is given per roll. - Players must have **played the game recently** to be eligible. - **Boosts/repeats/replies and other passive actions do not count**. - **Only deliberate, conscious engagement** is rewarded. ### 🎯 Pity Point Limits - Players have a **maximum number of pity points** they can hold at a time. - This creates **strategic tension** as players must choose carefully what to react to. - Prevents “spam-reacting” to everything without consequence. - Pity points are personal and **cannot be traded**. ### 🎯 Popularity Point System - Each card can earn **popularity points**, which are limited globally. - For example: a total of **1000 popularity points** exists across the entire game. - One card can’t exceed a certain amount (e.g. 100), meaning popularity is a **zero-sum system**. - Popularity is **not tied to rarity**. A common card can be popular purely through community love. - But they are tied to rolling, making it so when a card gets popular it becomes more difficult to get. - The popularity landscape will **shift over time**, keeping the meta fresh. ## Open Questions ### Strengths - Encourages meaningful interaction. - Ties social engagement into game mechanics non-exploitative way. - Popularity becomes a limited resource, encourages trends. - Because popularity is a stat, it means the meta is constantly changing, there could be a sudden change in popularity for a specific card, making it popular, and at the next day, it could become worthless. ### Potential Issues - **Pity RNG:** Some players may feel frustrated by lack of rewards even with engagement. - Should we add a visible progress tracker? Or “increasing chance” system? - **Cap Confusion:** Players may not realize they're at the pity cap. - Maybe a reminder would help. - **Bandwagoning:** Players might only chase popular cards. - Should we implement underdog incentives or limited-time boosts for less-popular cards? ## Final Thoughts This is an evolving system proposal, perhaps tied to another kind of pity system, where you get a pity point for a specific character after you roll a set amount of times without getting the card. Balance will be key, but making mechanics that relate to the social aspects of the fediverse has a lot of potential to deepen engagement and give cards emotional/social value.
waifu added the
Feature
Feedback Wanted
labels 2025-05-27 16:50:03 -07:00
Collaborator

Nice proposal! Though I don't think you've detailed what pity points actually do? 🤔

I'm assuming they'd increase a player's chance of rolling a particular card. Maybe each pity point a player has on a card increases that card's drop weighting to base_drop_weight × (num_pity_points + 1) and pity points towards a card will be removed when a player rolls that card. If they're rare, I think the benefit should be significant.

In terms of a pity cap, I think we can just have pity points operate on a stack system: If a player is at the pity cap and gains another pity point on a card, the oldest pity point they have is removed.

In terms of a progress tracker, or cap communication, I think the system would benefit from a lack of transparancy. Obviously the source code is public so people can just look at how it works, but I think keeping players in the dark about what pity points they have could make interactions with the system more organic. Maybe we tell players how many pity points they had on a card once they pull it.

I've recently tossed around the idea of allowing multiple pulls in a single roll (think 10-pulls in some gacha games: #32), if we decide to move forward with that, we'd need to think about how we distribute pity points in a roll with multiple pulls. Maybe we just distribute a pity point for each pull in the roll at random.

I'm concerned about the scalability of the system as described:

Pity scalability

Distributing a fixed number of pity points per roll is super overpowered if there's only a handful of people playing, but not very impactful if there's a lot of people playing - sort of like voting.

Additionally, pity points as described can't be distributed on-demand, as we'd need to pool the reactions on a post at some point in time after it's gone live:

  • When do we distribute pity points on a roll?
  • Are we cocerned about players who react after pity points are distributed?

If we instead make it so that players have a flat chance of receiving a pity point upon reacting to a roll, that would make the system more scalable and eliminate the need for implementing a job scheduler into the bot. We could also have that flat chance decrease over time from when the post was made, incentivising people reacting to newer posts as they happen and decreasing the effectiveness of going back and reacting to older posts.

Popularity scalability

Having a fixed number of total popularity points in the game could mean that as we add more cards, popularity becomes more spread out among cards and we may end up with a significant number of cards stuck at 0 popularity, and even the 'poplar' cards stuck in single-digit popularity because it's just that sparse.

IMO, an easy fix would be making it so that popularity points scale linearly with the number of cards in circulation: every card added comes with 50 popularity points by default, keeping the total amount of popularity points per card constant.

Popularity flux

If popularity is constantly updating, it could have a negative impact on games being played: if you make a strategic decision based on a card having a certain number of popularity points, then the popularity calculation runs in the middle of the game, it could alter the outcome of that game without player involvement. This will be especially problematic if we implement a type of game that takes a long time to play.

I think we'd want to have games operate with 'snapshots' of cards taken at the time of starting the game, that would fix this issue somewhat.

Nice proposal! Though I don't think you've detailed what pity points actually do? 🤔 I'm assuming they'd increase a player's chance of rolling a particular card. Maybe each pity point a player has on a card increases that card's drop weighting to `base_drop_weight × (num_pity_points + 1)` and pity points towards a card will be removed when a player rolls that card. If they're rare, I think the benefit should be significant. In terms of a pity cap, I think we can just have pity points operate on a stack system: If a player is at the pity cap and gains another pity point on a card, the oldest pity point they have is removed. In terms of a progress tracker, or cap communication, I think the system would benefit from a *lack* of transparancy. Obviously the source code is public so people can just look at how it works, but I think keeping players in the dark about what pity points they have could make interactions with the system more organic. Maybe we tell players how many pity points they had on a card once they pull it. I've recently tossed around the idea of allowing multiple pulls in a single roll (think 10-pulls in some gacha games: #32), if we decide to move forward with that, we'd need to think about how we distribute pity points in a roll with multiple pulls. Maybe we just distribute a pity point for each pull in the roll at random. I'm concerned about the scalability of the system as described: #### Pity scalability Distributing a fixed number of pity points per roll is super overpowered if there's only a handful of people playing, but not very impactful if there's a lot of people playing - sort of like voting. Additionally, pity points as described can't be distributed on-demand, as we'd need to pool the reactions on a post at some point in time after it's gone live: - When do we distribute pity points on a roll? - Are we cocerned about players who react after pity points are distributed? If we instead make it so that players have a flat chance of receiving a pity point upon reacting to a roll, that would make the system more scalable and eliminate the need for implementing a job scheduler into the bot. We could also have that flat chance decrease over time from when the post was made, incentivising people reacting to newer posts as they happen and decreasing the effectiveness of going back and reacting to older posts. #### Popularity scalability Having a fixed number of total popularity points in the game could mean that as we add more cards, popularity becomes more spread out among cards and we may end up with a significant number of cards stuck at 0 popularity, and even the 'poplar' cards stuck in single-digit popularity because it's just that sparse. IMO, an easy fix would be making it so that popularity points scale linearly with the number of cards in circulation: every card added comes with 50 popularity points by default, keeping the total amount of popularity points per card constant. #### Popularity flux If popularity is constantly updating, it could have a negative impact on games being played: if you make a strategic decision based on a card having a certain number of popularity points, then the popularity calculation runs in the middle of the game, it could alter the outcome of that game without player involvement. This will be especially problematic if we implement a type of game that takes a long time to play. I think we'd want to have games operate with 'snapshots' of cards taken at the time of starting the game, that would fix this issue somewhat.
Author
Owner

what pity points actually do?

My bad I completely forgot about that, initially I thought of pity points as "tokens" so imagine you have place for 10 tokens and you need 6 pity points of a specific card to redeem it. This redeeming would take the place of a roll but with 100% probability of getting that specific card. This way players have a tangible progress towards getting the card that they want, even if it's very slowly.

Now the problem is if they actually roll the card. Those pity points go into the trash since they already got the card they wanted, so adding an increased chance of specific card drop would work better.

We could also have that flat chance decrease over time from when the post was made

Yes, perhaps just a set of posts that we watch for reactions, and after a while they just get removed from the set.

When do we distribute pity points on a roll?

Yes I agree we should give them to the player as they give the reaction.
So for example it would be like:

  • Notification gets received
  • (Other code)
  • Is it a reaction? (Yes)
  • Is the reaction to one of the roll posts being watched? (Yes)
  • Is it a heart or a like? (Yes)
  • Calculate if it receives a pity point. (Yes)
  • Add the pity point to the Player

Popularity

I like the fix for the popularity system!
I know it's kind of a strange mechanic since it's supposed to be constantly changing yet I see some potential in it. Another question that comes to my mind is, if the game has a set number of popularity points. When a reaction happens, which card gets their popularity removed?

>what pity points actually do? My bad I completely forgot about that, initially I thought of pity points as "tokens" so imagine you have place for 10 tokens and you need 6 pity points of a specific card to redeem it. This redeeming would take the place of a roll but with 100% probability of getting that specific card. This way players have a tangible progress towards getting the card that they want, even if it's very slowly. Now the problem is if they actually roll the card. Those pity points go into the trash since they already got the card they wanted, so adding an increased chance of specific card drop would work better. >We could also have that flat chance decrease over time from when the post was made Yes, perhaps just a set of posts that we watch for reactions, and after a while they just get removed from the set. >When do we distribute pity points on a roll? Yes I agree we should give them to the player as they give the reaction. So for example it would be like: - Notification gets received - (Other code) - Is it a reaction? (Yes) - Is the reaction to one of the roll posts being watched? (Yes) - Is it a heart or a like? (Yes) - Calculate if it receives a pity point. (Yes) - Add the pity point to the Player >Popularity I like the fix for the popularity system! I know it's kind of a strange mechanic since it's supposed to be constantly changing yet I see some potential in it. Another question that comes to my mind is, if the game has a set number of popularity points. When a reaction happens, which card gets their popularity removed?
Author
Owner

I kept thinking about it and two things:

  • Daily posts from the bot with random cards

This is so they can get popularity points even if they don't get rolled

  • When a reaction happens perhaps we could take a popularity point randomly from another card

This means popular cards are more likely to get their points taken, so it's a constant battle for popularity

perhaps we'll only know once it goes live and pregnant cards get 300 million popularity points

I kept thinking about it and two things: - Daily posts from the bot with random cards This is so they can get popularity points even if they don't get rolled - When a reaction happens perhaps we could take a popularity point randomly from another card This means popular cards are more likely to get their points taken, so it's a constant battle for popularity perhaps we'll only know once it goes live and pregnant cards get 300 million popularity points
Author
Owner

One point that kept going in my mind was about how decisive it is to set a main stat as a constantly changing value, it seemed difficult to implement and a bit too disruptive, so perhaps we could change popularity to be a passive buff in popularity tiers like this:

  • 0–49: 💤 Unnoticed → -5% stat debuff
  • 50–69: 🌱 Stable → no bonus
  • 70–89: 💫 Trending → +5% to main stat
  • 90–100: 🌟 Beloved → +5% to all stats

This gives a soft, edge without invalidating design. So we don't decide "popularity" but it is something natural that changes as time goes. It would be easier to implement since it's just a check before the game plus a temporal change of the stats, and could even be toggled if people want to play without it.

One point that kept going in my mind was about how decisive it is to set a main stat as a constantly changing value, it seemed difficult to implement and a bit too disruptive, so perhaps we could change popularity to be a passive buff in popularity tiers like this: - 0–49: 💤 Unnoticed → -5% stat debuff - 50–69: 🌱 Stable → no bonus - 70–89: 💫 Trending → +5% to main stat - 90–100: 🌟 Beloved → +5% to all stats This gives a soft, edge without invalidating design. So we don't decide "popularity" but it is something natural that changes as time goes. It would be easier to implement since it's just a check before the game plus a temporal change of the stats, and could even be toggled if people want to play without it.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: waifu/kemoverse#37
No description provided.