0

Preface

I am new to learning Solidity and about smart contracts in general. I think that asking here would save me time rather than trying to fully figure things out myself.

Scenario

Suppose that I would like to implement a two player game with a smart contract such as rock paper scissors. I would like to have a random matchmaking algorithm which pairs players who are queued to play. Once players are paired, they are both entered into a smart contract. I understand that randomness is not possible within Solidity, so I think that the matchmaking will have to be done offchain. What are some different frameworks for making this system?

Edit: Rock paper scissors was probably not the best example game for my scenario. The aim of the random matchmaking is to make it impossible to reliably queue into yourself or a collaborator. This would be important for a game like poker, where queuing into yourself or your friend can result in unfair collusion.

Improve this question

1 Answer 1

Reset to default
1

Better idea.

Why not have players start a game or join a game at their leisure? For example, if the games are for money, start one with a wager, or join one by matching the wager and committing a move.

The big challenge isn't ensuring the randomness of the player matching. The challenge is about concealing the moves. When a player starts a game, they should commit a move, and this move has to be concealed from the other player until the other player commits.

This is because the real game is played with simultaneous moves but the blockchain forces us to think in sequential terms. A close analog is secret moves.

Think of it like cards face down. Each player is fully committed to their move before the other players can decipher what that move is. You can determine the winner in a "reveal" stage. Try searching for something like "Solidity commit/reveal pattern" in your search engine.

Hope it helps.

Improve this answer
7
  • 1
    Thanks for your answer! Rock paper scissors was perhaps not the best example of a game to illustrate my point. Suppose we are playing a game which requires both secret moves, but which breaks down if I am able to reliably queue into my friend, or myself. For instance, on a poker table, we want to ensure that two friends are not able to reliably enter the same table, as to prevent collusion.
    – David J
    Aug 16, 2020 at 21:02
  • Randomness is not possible, but unpredictable is possible, to a point. An off chain source would have to inject a decision and that would mean at least one block before the players are organized into tables. You could consider using the hash of the future block as a factor based on the idea that no one other than a miner can know it or cheat.
    – Rob Hitchens
    Aug 17, 2020 at 1:04
  • For example, if the players are all committed and the "start" function is called by someone, then the seating is determined by a function of that blockhash. A caution item is that miners will be able to influence the outcome if they want to. Increasing the difficulty on-chain is worthwhile, otherwise you would have a third party paying for gas and not necessarily convincing the players that it's fair.
    – Rob Hitchens
    Aug 17, 2020 at 1:09
  • third-party oracles can a source of randomness. Check out Provable.
    – Rob Hitchens
    Aug 17, 2020 at 1:10
  • I've been able to implement most of your suggestions. I think that unpredictability was good enough for my applications. To achieve this, I used the hash of all of the committed addresses and used that to determine seating. I think this is enough to ensure that, as long as a player does not have control of a large portion of the pool (in which case they have already won), they cannot reliably manipulate seating.
    – David J
    Aug 27, 2020 at 16:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.