Feat: Stat-based Duel Mode #14

New issue

Open

opened 2025-05-20 22:14:13 -07:00 by waifu · 5 comments

waifu commented 2025-05-20 22:14:13 -07:00

Owner

Copy link

We want to add a duel mode to the Kemoverse gacha game that connects directly with the gacha system. This mode will give players more meaningful interaction with the cards they collect, beyond simply rolling them.

Core Gameplay Loop (MVP)

• Each duel is 3 rounds between two players.
• At the start of the duel, each player receives 3 random cards from their own collection.
• Players do not see any of their cards until it is their turn.
• Players take turns - they alternate who plays each round. Starting with the one being challenged.

Round Flow

1. On their turn, the bot sends the current player a private message with the next random card from their set:
   • The card's Power and Charm stats.
2. That player replies privately to the bot with either "Power" or "Charm" as their chosen stat.
3. The bot then selects a random card from the opponent's stack (not revealed to the player) and compares the chosen stat.
4. The bot posts the result publicly in a dedicated thread:
   • Which stat was used.
   • The stat values.
   • Who won the round.

After 3 rounds, the bot declares the overall winner.

Bot Messaging Flow

• A single thread is used where the bot replies to itself for each round's public result.
• The bot tags both players in public messages to help them follow the duel.
• All stat choices and card reveals happen in private messages to the bot, only for the current player.

Optional Feature: Duel Stakes

• The duel can optionally be played with stakes:
  • The winner receives a random card from the loser's collection.
• Favorite cards are excluded from loss (see future feature below).

---

Related Issues To Create

• Implement Power and Charm stats for each card.
• Add favorite card tagging to protect them from duels/stakes.
• Add toggle to enable/disable duel stakes (friendly vs. competitive mode).
• Implement bot thread logic (single public thread per duel).
• Build duel backend: turn logic, messaging flow, result announcements.
• Make sure players only see their cards on their turn.

---

This feature ties directly into the gacha loop by making each card useful and playable. It gives weight to rolling and collecting, and encourages player interaction. Starting simple allows us to test and improve based on community feedback.

We want to add a **duel mode** to the Kemoverse gacha game that connects directly with the gacha system. This mode will give players more meaningful interaction with the cards they collect, beyond simply rolling them. ## Core Gameplay Loop (MVP) - Each duel is **3 rounds** between two players. - At the start of the duel, each player receives **3 random cards** from their own collection. - Players **do not see any of their cards** until it is their turn. - Players **take turns** - they alternate who plays each round. Starting with the one being challenged. ### Round Flow 1. On their turn, the bot sends the **current player** a private message with the next random card from their set: - The card's **Power** and **Charm** stats. 2. That player replies privately to the bot with either `"Power"` or `"Charm"` as their chosen stat. 3. The bot then selects a random card from the opponent's stack (not revealed to the player) and compares the chosen stat. 4. The bot posts the **result publicly** in a dedicated thread: - Which stat was used. - The stat values. - Who won the round. After 3 rounds, the bot declares the **overall winner**. ## Bot Messaging Flow - A **single thread** is used where the bot replies to itself for each round's public result. - The bot **tags both players** in public messages to help them follow the duel. - All **stat choices and card reveals** happen in **private messages** to the bot, only for the current player. ## Optional Feature: Duel Stakes - The duel can optionally be played **with stakes**: - The **winner receives a random card** from the loser's collection. - **Favorite cards** are excluded from loss (see future feature below). --- ## Related Issues To Create - Implement `Power` and `Charm` stats for each card. - Add `favorite` card tagging to protect them from duels/stakes. - Add toggle to enable/disable **duel stakes** (friendly vs. competitive mode). - Implement bot thread logic (single public thread per duel). - Build duel backend: turn logic, messaging flow, result announcements. - Make sure players only see their cards on their turn. --- This feature ties directly into the gacha loop by making each card useful and playable. It gives weight to rolling and collecting, and encourages player interaction. Starting simple allows us to test and improve based on community feedback.

❤️ 1

waifu added the

Feature

label 2025-05-20 22:14:27 -07:00

VD15 commented 2025-05-21 08:30:23 -07:00

Collaborator

Copy link

I suppose another question would be: how are stats determined?

The way I see it, we can either have stats be random or specified by users. We would also want some mechanism to stop super high-stat characters being super common in the drop pool. It'd disincentivise rolling if exodia's right arse cheek was a 1 in 3 drop chance and dominating the game.

Random Stats:

• Adding more stats in future would be easier (they're still just random)
• Users can't cheese the system by flooding the db with max stat cards

User-Specified Stats:

• Stats may better reflect the personality of the card
• Users would not be allowed to specify rarity anymore

I suppose another question would be: how are stats determined? The way I see it, we can either have stats be random or specified by users. We would also want some mechanism to stop super high-stat characters being super common in the drop pool. It'd disincentivise rolling if exodia's right arse cheek was a 1 in 3 drop chance and dominating the game. #### Random Stats: - Adding more stats in future would be easier (they're still just random) - Users can't cheese the system by flooding the db with max stat cards #### User-Specified Stats: - Stats may better reflect the personality of the card - Users would not be allowed to specify rarity anymore

VD15 commented 2025-05-21 10:19:46 -07:00

Collaborator

Copy link

Other ideas:

• Maybe call 'friendly' mode 'casual' to align better with vocabulary used in e-sports games?
  • Need to make it clear that players will forfeit their cards in competitive.
• Leaderboard that tracks players win rate in both casual and competitive categories.
  • Purely for bragging rights.
  • Could sort by number of wins, win/loss ratio or implement an elo system.
  • Could assign ranks based on how high players are in the leaderboards.
  • Players may seek to rig the leaderboards by playing thousands of matches against dummy accounts. An elo system may mitigate the effectiveness of this.
• favourite card tagging doesn't make much sense to me when the no-stakes mode exists.
  • The whole point of the competitive stakes mode is you forfeit your cards if you lose.
  • If you don't want to lose your cards, just don't play competitive?
  • It also feels like something players could use to rig their decks so only their omega good cards are able to be selected.

Other ideas: - Maybe call 'friendly' mode 'casual' to align better with vocabulary used in e-sports games? - Need to make it clear that players will forfeit their cards in competitive. - Leaderboard that tracks players win rate in both casual and competitive categories. - Purely for bragging rights. - Could sort by number of wins, win/loss ratio or implement an elo system. - Could assign ranks based on how high players are in the leaderboards. - Players may seek to rig the leaderboards by playing thousands of matches against dummy accounts. An elo system may mitigate the effectiveness of this. - `favourite` card tagging doesn't make much sense to me when the no-stakes mode exists. - The whole point of the competitive stakes mode is you forfeit your cards if you lose. - If you don't want to lose your cards, just don't play competitive? - It also feels like something players could use to rig their decks so only their omega good cards are able to be selected.

VD15 commented 2025-05-21 10:42:38 -07:00

Collaborator

Copy link

My Problem With The Game as Outlined

Players not being able to see their own hand doesn't feel like a good or engaging decision.

This doesn't feel satisfying or earned as the person issuing the duel: You send a message to start the duel, the other player accepts and then you are told that you won or lost a round with absolutely no input on your end. You might as well just wager a card and flip a coin (Which could be a separate game tbh).

The game as described is essentially set up like rock-paper scissors except each round, one player's move is decided for them, entirely at random. On paper, RPS is entirely luck based: Both players have no way of knowing what the other party is going to pick, but they're the one choosing what they throw out, so it feels like you have agency and it feels like you can strategize. This is what makes RPS engaging to people.

Proposed Improvement

Below, I've detailed a proposal for a revised version of the Stat-Based Duel Mode and its' message flow that I believe to be an improvement:

Pre-Game

Alice messages The Bot with the duel command and tagging Bob.
The Bot replies to Alice, issuing a Duel request to Bob.
Bob replies with 'accept', initiating a Duel with Alice.
The Bot picks three cards at random from Alice's and Bob's inventories.
The Bot Replies to Bob, showing both players' hands and instructing them to reply only to the direct messages that are to follow.
Play Round 1.

Round 1

The Bot sends a direct message to Alice, instructing her that she is Attacking and needs to pick one card from her hand to play.
The Bot sends a direct message to Bob, instructing him that he is Defending and needs to pick one card from his hand to play as well as a stat to assess.
Alice and Bob both reply to The Bot's direct message and make their play.

Once The Bot receives both players' responses, it replies to the main thread, detailing what cards both players played, and whose card has the highest value in the stat the Defender Chose.
The Bot assigns a point to the winner.
Both chosen cards are removed from the players' hands and put in the graveyard.

Play Round 2.

Round 2

Bob is now Attacking.
Alice is now Defending.
Another round plays.

If either player has two points at the end of Round 2, skip to the Post-Game.
Otherwise, play Round 3.

Round 3

Alice is now Attacking.
Bob is now Defending.
The outcome of the game is decided automatically, assuming ideal play from Bob.

If Bob's last card has at least one stat that is higher than that of Alice's last card, Bob wins.
Otherwise, Alice wins.
Both players' cards are added to the graveyard.

Post-Game

The bot replies to the main thread, ending the duel and announcing a victor.
If the duel was competitive in nature, the contents of the graveyard are awarded to the victor
Otherwise, the contents of the graveyard are returned to their original owners.

Summary

This proposal is admittedly more complex than the original, however I believe it serves as an improvement:

• Both players moves are still done in secret.
• Both players make a decision every round, granting them the feel of more agency in the game and lessening the apparent randomness of the game.
• Having knowledge of their opponent's hand allows players to strategize and make more interesting choices.
• The addition of a graveyard means players retain what's left of their hand if a game ends early, allowing them the opportunity to throw the second round in order to save a valuable card.

Room For Improvement:

Round 3 of my proposal is entirely automatic, since both parties only have one card left to play and the only decision the Defender has to make is trivial: just pick the higher number.

On paper, it is massively weighted in the Defender's favour, however the Attacker does have opportunities to affect how it plays out by making strategic decisions in the rounds prior. This may affect the overall balance of the game to favour the Defender, but I can't tell without first playtesting.

A couple of solutions if Round 3 ends up biasing the game:

• Could allow both players to draw another card every round so they always have three to play.
  • Increases effect of randomness on the game.
  • Less forward-thinking strategy, but decisions are simpler.
  • Increases the cards required to play the game from 3 to 5.
• Could go to overtime until somebody is 2 points up.
  • Opportunity for endless overtime.
  • Someone may run out of cards to draw.
  • Stakes can spiral out of control.
• Call the duel a tie at Round 2.
  • Both players' cards are returned to them, even in competitive.
• Make it so The Bot (predictably) chooses the stats each round instead of the Defender.
  • Stats at play each round are made known at the start of the game.
  • Would benefit from the addition of a third statistic, that way there's a different stat each round.

### My Problem With The Game as Outlined Players not being able to see their own hand doesn't feel like a good or engaging decision. This doesn't feel satisfying or earned as the person issuing the duel: You send a message to start the duel, the other player accepts and then you are told that you won or lost a round with absolutely no input on your end. You might as well just wager a card and flip a coin (Which could be a separate game tbh). The game as described is essentially set up like rock-paper scissors except each round, one player's move is decided for them, entirely at random. On paper, RPS is entirely luck based: Both players have no way of knowing what the other party is going to pick, but *they're* the one choosing what they throw out, so it feels like you have agency and it feels like you can strategize. This is what makes RPS engaging to people. ### Proposed Improvement Below, I've detailed a proposal for a revised version of the Stat-Based Duel Mode and its' message flow that I believe to be an improvement: #### Pre-Game Alice messages The Bot with the `duel` command and tagging Bob. The Bot replies to Alice, issuing a Duel request to Bob. Bob replies with 'accept', initiating a Duel with Alice. The Bot picks three cards at random from Alice's and Bob's inventories. The Bot Replies to Bob, showing both players' hands and instructing them to reply only to the direct messages that are to follow. Play Round 1. #### Round 1 The Bot sends a direct message to Alice, instructing her that she is Attacking and needs to pick one card from her hand to play. The Bot sends a direct message to Bob, instructing him that he is Defending and needs to pick one card from his hand to play as well as a stat to assess. Alice and Bob both reply to The Bot's direct message and make their play. Once The Bot receives both players' responses, it replies to the main thread, detailing what cards both players played, and whose card has the highest value in the stat the Defender Chose. The Bot assigns a point to the winner. Both chosen cards are removed from the players' hands and put in the graveyard. Play Round 2. #### Round 2 Bob is now Attacking. Alice is now Defending. Another round plays. If either player has two points at the end of Round 2, skip to the Post-Game. Otherwise, play Round 3. #### Round 3 Alice is now Attacking. Bob is now Defending. The outcome of the game is decided automatically, assuming ideal play from Bob. If Bob's last card has at least one stat that is higher than that of Alice's last card, Bob wins. Otherwise, Alice wins. Both players' cards are added to the graveyard. #### Post-Game The bot replies to the main thread, ending the duel and announcing a victor. If the duel was competitive in nature, the contents of the graveyard are awarded to the victor Otherwise, the contents of the graveyard are returned to their original owners. ### Summary This proposal is admittedly more complex than the original, however I believe it serves as an improvement: - Both players moves are still done in secret. - Both players make a decision every round, granting them the feel of more agency in the game and lessening the apparent randomness of the game. - Having knowledge of their opponent's hand allows players to strategize and make more interesting choices. - The addition of a graveyard means players retain what's left of their hand if a game ends early, allowing them the opportunity to throw the second round in order to save a valuable card. ### Room For Improvement: Round 3 of my proposal is entirely automatic, since both parties only have one card left to play and the only decision the Defender has to make is trivial: just pick the higher number. On paper, it is massively weighted in the Defender's favour, however the Attacker does have opportunities to affect how it plays out by making strategic decisions in the rounds prior. This may affect the overall balance of the game to favour the Defender, but I can't tell without first playtesting. A couple of solutions if Round 3 ends up biasing the game: - Could allow both players to draw another card every round so they always have three to play. - Increases effect of randomness on the game. - Less forward-thinking strategy, but decisions are simpler. - Increases the cards required to play the game from 3 to 5. - Could go to overtime until somebody is 2 points up. - Opportunity for endless overtime. - Someone may run out of cards to draw. - Stakes can spiral out of control. - Call the duel a tie at Round 2. - Both players' cards are returned to them, even in competitive. - Make it so The Bot (predictably) chooses the stats each round instead of the Defender. - Stats at play each round are made known at the start of the game. - Would benefit from the addition of a third statistic, that way there's a different stat each round.

❤️ 1

waifu commented 2025-05-21 11:27:02 -07:00

Author

Owner

Copy link

Very nice feedback I love it!
Some comments to keep the conversation going:

I suppose another question would be: how are stats determined?

I'm guessing the easier option would be going random, but then you could also flood the card system until you get a card with good stats. This would also be a question, are normal users allowed to add cards?
I think this could be a toggled mechanic if someone wants to create a chaotic server, but initially just the admins should be fine.

If you don't want to lose your cards, just don't play competitive?

I just don't want to lose my Ultra Rare Pleroma-tan Pregnant card

With my initial post I tried to place a MVP so we can direct our attention to the things we can get going regardless of how the gameplay mechanics work since they could change in the future with playtesting.

So all of these are more or less starting points since they're the basis of the card game:

• Implement stats for each card.
• Duel command with a toggle to enable/disable duel stakes (casual vs. competitive mode).
• Implement bot thread logic (single public thread per duel).
• Build duel backend: turn logic, messaging flow, result announcements.

But your mechanics are really good point of start, they're not that complex and people could start playing from the start if we implement a time mechanic between rolls but give people some bonus untimed rolls in the beginning, or the first roll gets 10 cards.

Very nice feedback I love it! Some comments to keep the conversation going: > I suppose another question would be: how are stats determined? I'm guessing the easier option would be going random, but then you could also flood the card system until you get a card with good stats. This would also be a question, are normal users allowed to add cards? I think this could be a toggled mechanic if someone wants to create a chaotic server, but initially just the admins should be fine. >If you don't want to lose your cards, just don't play competitive? ~~I just don't want to lose my Ultra Rare Pleroma-tan Pregnant card~~ With my initial post I tried to place a MVP so we can direct our attention to the things we can get going regardless of how the gameplay mechanics work since they could change in the future with playtesting. So all of these are more or less starting points since they're the basis of the card game: - Implement stats for each card. - Duel command with a toggle to enable/disable duel stakes (casual vs. competitive mode). - Implement bot thread logic (single public thread per duel). - Build duel backend: turn logic, messaging flow, result announcements. But your mechanics are really good point of start, they're not that complex and people could start playing from the start if we implement a time mechanic between rolls but give people some bonus untimed rolls in the beginning, or the first roll gets 10 cards.

❤️ 1

nai commented 2025-05-21 20:23:25 -07:00

Collaborator

Copy link

What I would have proposed is already proposed by VD, nice.

My additional nit

In players "idle" time (meaning time outside of duels) let players build a deck. Since we don't have complex card mechanics, by "deck" here I mean simply a poll of cards the bot will draw from.

Why?

If a player has a fixed amount of cards in the inventory and then accidentally draws several super rare cards in the row, they are not going to have the motivation to keep rolling, because every other weak common card will reduce the chance for the super rare ones to appear in their hand in a duel.

B-but so players will just fill the entire deck with ultra rare chads and new players will never win!!!

I imagine we could steal the approach from other similar games and make a "deck weight" restriction. Either by accumulative power of stats, or simply by "3 commons, 2 uncommons, 2 rares" and so on, depending on what ranks of cards the game will have.

Other than that, the gameplay discussed above looks very good.

Do you have any idea how overcomplicated the flow is going to be

Yes, this is why we put this to a backlog and never ever implement it, marking it "known issue"

What I would have proposed is already proposed by VD, nice. ### My additional nit In players "idle" time (meaning time outside of duels) let players build a deck. Since we don't have complex card mechanics, by "deck" here I mean simply a poll of cards the bot will draw from. ### Why? If a player has a fixed amount of cards in the inventory and then accidentally draws several super rare cards in the row, they are not going to have the motivation to keep rolling, because every other weak common card will reduce the chance for the super rare ones to appear in their hand in a duel. ### B-but so players will just fill the entire deck with ultra rare chads and new players will never win!!! I imagine we could steal the approach from other similar games and make a "deck weight" restriction. Either by accumulative power of stats, or simply by "3 commons, 2 uncommons, 2 rares" and so on, depending on what ranks of cards the game will have. Other than that, the gameplay discussed above looks very good. ### Do you have any idea how overcomplicated the flow is going to be Yes, this is why we put this to a backlog and never ever implement it, marking it "known issue"

❤️ 2

VD15 referenced this issue 2025-05-23 15:45:19 -07:00

readme update #22

VD15 added this to the v1.1 project 2025-05-24 14:30:33 -07:00

VD15 self-assigned this 2025-05-24 15:04:56 -07:00

VD15 removed their assignment 2025-05-24 15:50:45 -07:00

VD15 removed this from the v1.1 project 2025-05-25 08:00:54 -07:00

VD15 added this to the v2.0 project 2025-05-26 06:07:15 -07:00

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

master

dev

stats_system

website

pleroma-support

any-env-and-bind-address

misc-bugfixes

docs

card-creator

18_reduce_tuples

fix_username_case_sensitivity

No results found.

Labels

Clear labels   

Bug

Something's Not Working Right

  

Feature

New Functionality For The Bot

  

Feedback Wanted

Looking for Feedback

  

Refactoring

Codebase Changes

  

Won't Do

Nah Mate.

No labels

Bug

Feature

Feedback Wanted

Refactoring

Won't Do

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

v2.0

Assignees

Clear assignees

No assignees

3 participants

Notifications

Subscribe

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#14

No description provided.