Interesting project. I've been thinking about a turn-based game protocol to be used over xmpp. You could even have incomplete information through hashing. Does Saito have this?
Thanks for the comment. What exactly do you mean about incomplete information through hashing? Saito comes with a lot of backend cryptographic tools so it should be possible to do almost anything. One current feature that uses hashing is when players pick cards simultaneously -- they share their picks in hashed format before revealing the secret that prove their picks were made independently of the other player's -- not sure if this is the sort of thing you mean or you are thinking of something different.
The underlying game engine handles data transfers, abstracts away the complicated cryptographic data exchanges and makes sure that the game "stack" is the same. Once a new move is broadcast all of the players/observers add the received move to their local stack and then execute the instructions step by step until more input is required, at which point the game halts while everyone waits for the active player to provide input by "playing their turn".
In terms of game features, right now the core engine focuses on things like provably fair deck shuffling and card dealing and random number generation. Other features we hope to add which should benefit from the blockchain layer include things like decentralized leaderboards (everyone can see who won / lost public games so we can have distributed rankings), the ability for players to stake other cryptocurrencies on games (if people want they can even pay for games move-by-move), and the fact that game modules will be genuinely decentralized, which avoids the problems with distribution channels like Steam and/or the App Store, etc.
XMPP integration is a really interesting idea. What exactly did you have in mind with it?
With incomplete data I meant that you know your own hand cards but not the hand cards of the enemy. Sounds like you have some things in there that work similiar to how I envisioned them.
I don't think XMPP integration for this project in particular would be a great fit (interested in being proven wrong though). I just meant that it reminded me of a similar idea I had before, with xmpp instead of blockchain.
Yeah, that's it exactly. Interestingly, the technique was invented by the creators of RSA public key encryption, although they considered it impractical as it required the exchange of too much information back in the 1970s (all of the cards needs to be double-encrypted with separate keys after a XOR-powered shuffle).
It's exactly the sort of thing we want the underlying Saito game engine to handle, because implementing the cryptographic techniques is a huge pain. Right now the underlying engine simplifies the who process to pushing a new deck onto the stack and dealing from it. The development work is reduced to generating the "associative array" object that defines what the cards are.
Thanks for the comment anyway -- and reach out anytime if you have ideas for XMPP integration or thoughts on the project. You can also find us on the Saito dReddit btw: https://apps.saito.network/r/
4 comments
[ 2.8 ms ] story [ 18.9 ms ] threadThanks for the comment. What exactly do you mean about incomplete information through hashing? Saito comes with a lot of backend cryptographic tools so it should be possible to do almost anything. One current feature that uses hashing is when players pick cards simultaneously -- they share their picks in hashed format before revealing the secret that prove their picks were made independently of the other player's -- not sure if this is the sort of thing you mean or you are thinking of something different.
The underlying game engine handles data transfers, abstracts away the complicated cryptographic data exchanges and makes sure that the game "stack" is the same. Once a new move is broadcast all of the players/observers add the received move to their local stack and then execute the instructions step by step until more input is required, at which point the game halts while everyone waits for the active player to provide input by "playing their turn".
In terms of game features, right now the core engine focuses on things like provably fair deck shuffling and card dealing and random number generation. Other features we hope to add which should benefit from the blockchain layer include things like decentralized leaderboards (everyone can see who won / lost public games so we can have distributed rankings), the ability for players to stake other cryptocurrencies on games (if people want they can even pay for games move-by-move), and the fact that game modules will be genuinely decentralized, which avoids the problems with distribution channels like Steam and/or the App Store, etc.
XMPP integration is a really interesting idea. What exactly did you have in mind with it?
I don't think XMPP integration for this project in particular would be a great fit (interested in being proven wrong though). I just meant that it reminded me of a similar idea I had before, with xmpp instead of blockchain.
It's exactly the sort of thing we want the underlying Saito game engine to handle, because implementing the cryptographic techniques is a huge pain. Right now the underlying engine simplifies the who process to pushing a new deck onto the stack and dealing from it. The development work is reduced to generating the "associative array" object that defines what the cards are.
Thanks for the comment anyway -- and reach out anytime if you have ideas for XMPP integration or thoughts on the project. You can also find us on the Saito dReddit btw: https://apps.saito.network/r/