Synchronous Messages: Visual Tutorial
Until now, Synchronous Messages (SM) has been poorly documented. In this guide, I hope to demonstrate this feature.
In this story, my acquaintance, Tester, has challenged me to a game of rock-paper-scissors. The game depends on players simultaneously revealing their actions; otherwise someone could change their action when they saw the other player's move. Typically, you would need either a third person (both players would send their moves to him, and he would reveal the moves publicly), or a dedicated RPS game that would do the same thing. You'll see how SM allows us to avoid both of these.
Since it is my feature, I tell Tester to drop by the SM system and to use the batch code I will offer him. Since I'm already logged into my SooperGrape account, and there are only two of us, the only thing I need to change is the text. I fill it in with my move, "Paper", and submit.
Since I provided no batch code, the system created a new batch, 8fc11eb8d9f68aba. I send this code to Tester and wait for his reply. I can view my current message, "Paper", on the right side, but Tester cannot. After a few moments, I click "Submit Query". Since I didn't put any new text in, it will just refresh the page. If Tester's submitted anything, it'll show up.
Tester apparently couldn't be bothered to log in, since he shows up as "Guest #1". This means that his activity in this batch is tied to his IP address. He can only access it as long as he has that IP. This tends to be reliable for desktops, but is a poor choice for mobile devices. Names that are registered SooperGrape accounts are underlined; names that are registered for this batch are regular text, and guests (who are authenticated by IPs) are italicized.
His move, paper, means that it's a draw. We'll have to move again. I like paper, so I decide to move it again.
Unfortunately, at this point, Tester informs me that the system isn't letting him move; he's getting the message "This batch has reached capacity and isn't accepting new registrations".
Tester's mobile device has apparently already changed its IP address. Because of that, the system thinks that he is a new player, not one of the ones who registered. The only people who can participate in a batch are the ones who originally signed up for it. Because Tester has no way of getting his old IP back, that means this batch is 'dead'. I tell him he ought to at least register a name for the next one. He agrees, and goes to create a new batch.
This shows what the form might look like on Tester's end. He'll have to provide this username and password every time he wants to send anything to this batch, or view his pending messages. The username is kept after a submission, but the password isn't.
Tester sends me the code for the batch he just started, aa71ee6aa80f2fd1. I put the batch code in, and make my preplanned move, paper.
Whether through skill or luck, I've anticipated Tester's reply! Incidentally, we can see that the system supports emojis, as the 'rock' icon he put after the word 'Rock' shows up adequately.
Tester says, 'best two out of three'. It seems to add more skill to the equation, so I agree. At first, I decide to send Scissors, and do so.
But then I reconsider. I've played Paper twice in a row and he might be expecting that. Moreover, he might not think that I'll play the same move that just lost. RPS is mathematically a game of chance, but in practice, it is influenced by psychological factors. Because my move is only pending, I decide to change it to rock.
Done! It's a good thing, though, that I moved quickly. If I waited too long, Tester might have sent his reply before I made my edit. Then my message would have been a new move, not a modification of the old one. Editing pending messages is available for emergencies, but I don't recommend you make a habit of needing it, for this reason.
After refreshing the page again, I find that Tester has played Rock. Another draw. I make my next move, Paper, only to find that Tester has played Scissors.
This is getting out of hand! With the game in the balance, I play Paper, reasoning that Tester would not expect me to make the same move again after a loss. He wasn't, but only played Paper, for another draw. I play Scissors. It is predictable, but sometimes the predictable move is the most unpredictable one.
Sometimes, but apparently not in this case. Tester has now won a second round, and thus two-out-of-three. That's the way it goes sometimes. But who knows - maybe I'll get the series extended to the best 3-of-5!
Although many browsers nowadays don't show it well, the "Messages" box is scrollable, so you can view old messages again.
This concludes the tutorial for Synchronous Messages. With this demonstration, I feel you should now be able to use this feature competently. If you have unanswered questions, send a message to my email address.