WIP: Stop revealing hidden information to clients #10

Draft

LunarTides wants to merge 7 commits from hide-deckcode into main

LunarTides commented

2024-04-24 09:05:56 +00:00

(Migrated from github.com)

Closes #5

TODO:

Set the opponents hero at the start of the game.
Reveal the cards at correct points.
Apply the placeholder card's changes to the real card when revealed. Maybe add a Card.replace(new_card: Card, keep_changes: bool) function.

Closes #5 TODO: - [x] Set the opponents hero at the start of the game. - [ ] Reveal the cards at correct points. - [ ] Apply the placeholder card's changes to the real card when revealed. Maybe add a `Card.replace(new_card: Card, keep_changes: bool)` function.

LunarTides commented

2024-04-24 11:09:02 +00:00

(Migrated from github.com)

There is a lot of repeat code here. Put some of it in functions.

There is a _lot_ of repeat code here. Put some of it in functions.

LunarTides commented

2024-04-28 16:07:57 +00:00

(Migrated from github.com)

This needs some serious consideration and thinking, since this PR needs to solve a bigger problem than just the decks¹. The latest 2 commits already begun trying to solve the underlying problem, and I think I am on the right track. Here is a rundown of my thought process right now:

Ideally, the clients wouldn't know anything that isn't shown to the user. The clients should know what is in the friendly player's hand, but not what is in the opponent's hand or the cards in the deck. The problem then is, how can the client change cards? How can a card, for instance, add +1/+1 stats to a random card in the friendly player's deck?

The solution I am thinking, is that every card is given a UUID, which cards can reference. E.g. Select a random card from the deck, grab its UUID, and send it over to the server along with an enchantment that adds +1/+1². When the card is drawn, the server sends the card's UUID to the clients, and the clients go: "Oh yeah! This card has this enchantment!", and then it gets applied.

This requires a pretty big rewrite of some core code to get working, but should make cheating a lot harder to do (The anticheat is kind of useless when all of the cards get sent to the client when joining anyways), and would probably be worth it.

I could do this incrementally, so solve these issues one at a time, but I do need to get this working asap so I can work on other things. I wouldn't want to have to rewrite another PR multiple times because these big PRs change some of the core things, so I would ideally want to do most of these changes in this PR. ↩︎
I am thinking that enchantments should be their own cards instead of the war-crime that Hearthstone.js's implementation is. This is being implemented in its own pr which will be merged first: #11 ↩︎

This needs some serious consideration and thinking, since this PR needs to solve a bigger problem than just the decks[^1]. The latest 2 commits already begun trying to solve the underlying problem, and I think I am on the right track. Here is a rundown of my thought process right now: Ideally, the clients wouldn't know **anything** that isn't shown to the user. The clients should know what is in the friendly player's hand, but not what is in the opponent's hand or the cards in the deck. The problem then is, how can the client change cards? How can a card, for instance, add +1/+1 stats to a random card in the friendly player's deck? The solution I am thinking, is that every card is given a UUID, which cards can reference. E.g. Select a random card from the deck, grab its UUID, and send it over to the server along with an enchantment that adds +1/+1[^2]. When the card is drawn, the server sends the card's UUID to the clients, and the clients go: "Oh yeah! This card has this enchantment!", and then it gets applied. This requires a pretty big rewrite of some core code to get working, but should make cheating a lot harder to do (The anticheat is kind of useless when all of the cards get sent to the client when joining anyways), and would probably be worth it. [^1]: I could do this incrementally, so solve these issues one at a time, but I do need to get this working asap so I can work on other things. I wouldn't want to have to rewrite another PR multiple times because these big PRs change some of the core things, so I would ideally want to do most of these changes in this PR. [^2]: I am thinking that enchantments should be their own cards instead of the war-crime that [Hearthstone.js's implementation](https://github.com/LunarTides/Hearthstone.js/blob/0e04aa180dd9e5ce7a0fc743fe5e4f028cb622a9/src/core/card.ts#L1080-L1280) is. This is being implemented in its own pr which will be merged first: #11

This pull request is marked as a work in progress.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin hide-deckcode:hide-deckcode

git switch hide-deckcode

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch main

git merge --no-ff hide-deckcode

git switch hide-deckcode

git rebase main

git switch main

git merge --ff-only hide-deckcode

git switch hide-deckcode

git rebase main

git switch main

git merge --no-ff hide-deckcode

git switch main

git merge --squash hide-deckcode