HTML and CSS Reference
In-Depth Information
hand game rock-paper-scissors, also known as “roshambo.” If you're not familiar
with the game, Wikipedia provides plenty of information about it:
The Flow of the Game
Let's review the requirements and the flow of the game. The traditional way of playing the
game requires participants to call their object (rock, paper, or scissors) at exactly the same
time. To achieve this, the game is preceded by a “sync-up phase,” after which the players
shout their choice.
The beauty of playing the game in a browser is that users can be remote, which also
means that this “sync-up phase” will work slightly differently. To imitate the “sync-up
phase” in an online setting, we'll instead hide the players' selections from each other until
both players have picked their object.
Here is an overview of how the browser-based game works between two players:
1.
Player 1 (the player that moves first) selects an option (rock,
paper, or scissors). Player 1's app displays this selection.
2.
Player 2's (the slower player's) app receives Player 1's move
(but does not display the selection) and indicates that Player 1
has made a selection.
3.
Player 2 selects a move (rock, paper, or scissors).
4.
Player 1's app receives and displays Player 2's selection.
5.
Player 2's app displays the selections of both Player 1 and
Player 2.
The challenge with building this application is whether we can make it run
exclusively in the browser, without any back-end code or logic. How do we do this? With
messaging and WebSocket, of course.
First, we must consider how the apps will communicate. For the purposes of this
demonstration, we'll walk through building this game with two players, where the two
applications communicate directly with each other. You'll recall from Figure
5-2
that we
can use queues (which deliver messages to a single consumer), rather than topics (which
distribute messages to multiple consumers).
To achieve our goals, and keep our application reasonably straightforward, we build
the app with two queues, where Player 1's app publishes to one queue and Player 2's app
consumes from the same queue. Player 2's app then publishes to a second queue and
Player 1's app consumes messages from the second queue.
The queues will be identified by the players' names that we ask them to enter before
starting the game.
