Protocol Definition

[fendor]

Protocol Definition

We would need a formal definition what kind of messages can be sent between a client and the server.

So far we need this messages for sure:

For Setup:

• Client connects -> Server responds ACK! if there are enough free slots, otherwise drop the connection.
• Client defines personal info (e.g. Username, Rogue, Catcher) -> Server assigns unique number which can be used for a reconnect
• Client sends its unique number -> Server reconnects client : should be possible during playing the game
• Server announces that the game has begun if there are enough players registered.

For Game Playing:

• Server informs all clients who is playing -> Open for Discussion: should a client send an ACK! or is it assumed that he got the message?
• Client who is currently playing announces move -> Server validates move and sends feedback.
  Possible Feedback:
  • The move was invalid (with reason: e.g. no such cards, unreachable, other players are on the position)
  • It is not your turn
  • You have found the rogue core
  • Your move was valid and you have been moved together with a changed map and your current state
• Server announces that rogue core has won -> No reaction required
• Server announces that catchers found rogue core -> No reaction required.

After the game has finished:

• Client disconnects -> Server clears the slot.

Discussion: Should the server offer to restart the game?

Messages by Client and Server

Client

Client Connect

This is not an explicit message

Personal Information

{ 
    "username": "string",
    "preferredColor":  "string",
    "wantsToBeRogue": true
}

Reconnect

{
    "reconnectId": 1234
}

Disconnect

This should be explicit to determine if the disconnecting player wants to reconnect later. To be discussed: Should it really be this way? Most clients probably won't send this message, but on the other hand, if a player completly disconnects, the game is probably over anyways.

For now: some temporal message

{
     "willComeBack": true
}

Client sends move

{
    "color": "green",
    "nodeId": 1234
}

Server

ACK! new client

Implicit ACK!. This is handled by the websocket and does not require an own message

Assign unique identification number

{
   "reconnectId": 1234,
   "clientId": 1234
}

reconnectId and clientId do not have to be distinct.

Start the game

After this message, no new player can connect.

{
   "newGame": true,
   "roguePlayer": 1234,
   "players": [1, 2, ...]
}

Inform clients of who is next

{
   "nextPlayer": 1234
}

Feedback about commited request

This needs more discussion regarding if this should be several different messages and what would be the best representation of an error in json.

{
   "invalid": true
}

The game has ended:

{
   "rogueVictory": true
}

Further possible messages

• Text message which can be seen by other players
  • includes different chat rooms for rogue, catchers and whole group
• Announce where you wish to go next
• Share your expectation where the rogue player should be
• Lobby System for games

[Samuel Pilz]

Collaborating document on HackMd for further discussion.

@fendor The connection mechanism is not the best fit for The Elm Architecture.

• Ack! is not a goot choice for Response. This should be done by an elm-bridge Object with a better name (referencing the type of request).

• Using Websockets as-is does not detect reconnection

  • Only the server can send an information
  • Disconnection can be detected in elm if a certain amount of time has passed and the server has not responded.
  • Therefore: The server has to notify the client that the connection has been reestablished. (With current use of WS in elm)

• Reconnection-token is not the best solution since it does not allow reconnection between reloads (e.g. when frontend changes and gets hot-realoaded)