Why not simply use that directly, without any point multiplications, with the player committing to a random seed in an ordinary commit-and-reveal scheme?
Because it would work only if everything will be used outside of coins. But if BTC on-chain coins are involved or even BTC-LN coins, or maybe some other altcoins, then standardness rules apply. And then making some transaction with for example OP_SHA256 will be non-standard. Maybe in testnet, signet or regtest it will be ok, but in real life scenario it should sooner or later be somehow connected with real money, so there is a need of getting the whole game history and turning it into some transaction that will allow the winner to claim the reward in a decentralized way.
But yes, you are right, it could be simpler, and in case of free P2P game (with no coins or other goods involved), we could get rid of addresses and just use SHA-256 of some seed.
How is this turned into a hand of cards?
If you have two players and each of them has 52 cards, it is simple. The same if there are two players and one of them has all black cards and another player has all red cards. It is simple in all cases where players start from the same cards (sorted in different order) and the chances of winning depends more on their skills rather than their luck. But of course if both players use one shared deck of 52 cards, then things are more complicated.
The semi-centralized way is having someone acting as Escrow and holding the cards. Then, we have two players and one Escrow, all cards are unknown to both players. But this way is somewhat centralized, because both parties have to trust Escrow. So, if players want to split the deck to make it unbalanced (where one player could for example get four Aces), then it is definitely possible if they know how their shared deck is splitted, but still the order of the cards will be unknown and decided on-the-fly.
For ease of analysis, assume an oversimplified card game: Alice and Bob are each dealt 1 card (*). Each player looks at his or her own card, then chooses an amount to bet; after both players bet, they reveal their cards to each other. The player with the highest-valued card wins.
The more I think about this example, the more interesting it gets. It is equivalent to the problem of
Playing Dice with transactions. So far, I think that both players should create a transaction, where they both put their coins on some 2-of-2 multisig wallet, choose their seeds, reveal hash of their seeds, and then reveal their seeds after signing their betting transaction. By using provably fair dice algorithm, they can simply check who won the prize. And then, if the loser sends coins to the winner, everything works as desired. If the loser became uncooperative, then funds will be locked on multisig wallet, as long as needed to solve that dispute (which could be never, but then only these two player lose and everyone else wins, because there will be less coins in circulation, so everyone else's coins will be worth more). Earlier I thought about some kind of "emergency timelocks" or "making it non-risky for each party", but it seems that risk of losing funds is necessary.
(Note that there have been no previous moves.)
The first move they made was revealing the hash of their public keys (or seeds if you want to make it simpler). By choosing their master private keys, generating master public keys from them and revealing master addresses, they started playing the game and they made everything deterministic from that point. And that kind of data can be hashed and used during the first time when the first player picks the first card.
exactly what data do Alice and Bob exchange?
I assume that Alice want to pick her first card. She needs:
1) her deck
2) Bob's public key
3) game's public key
The first one was explained above, she has her deck of 52 cards and it is shuffled correctly. The second one is taken from Bob, because Alice cannot know the next card without Bob's agreement. The third one is just the hash of the block that is multiplied by the ECDSA generator point. So, she could sum Bob's public key and game's public key. Then, she could add this point to each card to see, which one has the lowest public key and pick it.