4. Game Process

Dummy websocket server

TODO: Introduction to Websocket with dummy eco streams

Exercise 14:

⚠️ Before tackling this exercise: Check out this commit 72a193066497b60c871fa8a26bea67a01d1de8e8

TODO: Exposition of the exercise 14

Compacted topics + Consumer

TODO: Introduction to compacted Topics and Consumers

Exercise 15:

⚠️ Before tackling this exercise: Check out this commit d8796708155223c2066ae5640b8d8f62d1e75f2e

TODO: Exposition of the exercise 15

EventHandler

TODO: Introduction to the eventHandler

Exercise 16:

TODO: Exposition of the exercise 16

Serders + WaitingStream

TODO: Introduction to Serders and the new waiting stream

Exercise 17:

⚠️ Before tackling this exercise: Check out this commit 25d0cff4dc01b379c586127aafd165a9e58c1ae5

TODO: Exposition of the exercise 17

Websocket connection in client

As we did with the Login process, now it is convenient to analyze how the client expects to communicate with the server and what the parties involved in the Game process are.

Exercise 18:

⚠️ Before tackling this exercise: Check out this commit XXXXXX Commit 26 here

The server already has the WebSocket endpoint ready for use by the client app, so let's work to define:

• The possible states necessary to open a WebSocket connection, create a new game, join an existing one, receive a WS error, etc.
• What changes does the Model demand to represent these new states
• What events (Msg) do we need to include in order to trigger those new states
• How the Tyrian app will react to the new events (Msg)
• What views will show the new state of the app
• How can we interact with a Tyrian WebSocket via a set of Cmds

Let's continue with the same approach of divide up the exercise into smaller pieces.

Part 0: What are the new states?

First thing first. What are the new states of the app?

State	What is happening?
Before joining a game	The user has not clicked the "Join Game" button, and the WebSocket connection is not even started
Waiting a game and opening WS	The user has already pressed the "Join Game" button, but the WS Connection client/serve not ready
Waiting a game but WS is open	The user has already pressed the "Join Game" button, and the WS Connection client/serve is stablished
WebSocket error received	The server has responded with an error. We don't have any game yet
Game received through the WS	The server has responded with a registered game.

Part 1: The Model

If we recap, the current shape of the Model includes nickname, player, and errors, which don't seem to be enough to describe completely all the new states. We propose to add the properties:

• contest: Contest which will include a eventual game. We used Contest as a synonymous of Game but avoiding two classes with the same name.
• ws: Option[WebSocket] which will potentially contain WS connection once is established.

The model might evolve like:

State	Nickname	Player	Errors	Contest	WS
Before joining a game	Non empty	Player.Registered	Empty	Contest.Empty	None
Waiting a game and opening WS	Non empty	Player.Registered	Empty	Contest.InProgress	None
Waiting a game but WS is open	Non empty	Player.Registered	Empty	Contest.InProgress	Some(ws)
WebSocket error received	Non empty	Player.Registered	Non empty	Contest.Empty	Some(ws)
Game received through the WS	Non empty	Player.Registered	Empty	Contest.Registered	Some(ws)

• Edit the file Model.scala to:
  • Describe these changes in the case class Model
  • Update the init Model.

Part 2: The Msg

Reminder: The event LoginSuccess(playerId: PlayerId) would bring the Model to the state "Before joining a game", right?

Let's check what other events (Msg) we need to add to trigger all the new states:

State	Triggered by the Msg:
Before joining a game	LoginSuccess(playerId: PlayerId) (existing)
Waiting a game and opening WS	WebSocketStatus(Connecting(playerId)) (new)
Waiting a game but WS is open	WebSocketStatus(Connected(ws)) (new)
WebSocket error received	WebSocketStatus(ConnectionError(error)) (new)
Game received through the WS	GameUpdate(game) (new)

• Edit the file Messages.scala to add these events.

Part 3: Update

Well, now we have new events to which we must react with model evolutions, as follows:

Msg:	Model	Cmd
WebSocketStatus(Connecting(playerId))	contest = Contest.InProgress	client.connect(playerId)
WebSocketStatus(Connected(ws))	ws = ws	Cmd.None
WebSocketStatus(ConnectionError(error))	errors = List(error)	Cmd.None
GameUpdate(game)	contest = Contest.Registered(game)	Cmd.None

• Edit the file Update.scala to react to these events as described above.

ℹ️ INFO: When the user pushes the Join Game button, the app establishes a WS connection with the server, so the Cmd client.connect(playerId) will be implemented in the part 5

Part 4: Views

As you might expect, we now need to define a view for each possible state the app can adopt. Here are some ideas:

Before joining a game

Waiting a game and opening WS | Waiting a game but WS is open | WebSocket error received

Game received through the WS (if it's the user's turn)

Game received through the WS (if it's the opponent's turn)

Magic monitoring: StartGame in the input topic

TODO: Introduction to how monitoring new messages in the input topic

Exercise 19:

TODO: Exposition of the exercise 19 (StartGame in the input topic)

GameStream: matchStream

TODO: Introduction to the new MatchStream

Exercise 20:

⚠️ Before tackling this exercise: Check out this commit XXXXXX Commit 28 here

TODO: Exposition of the exercise 20

Receive Game in client

TODO: Introduction to the new Msg we are receiving from the websocket

Exercise 21:

⚠️ Before tackling this exercise: Check out this commit XXXXXX Commit 30 here

TODO: Exposition of the exercise 21