samuelpilz / core-catcher

MIT License
3 stars 0 forks source link

Protocol Definition #16

Open fendor opened 7 years ago

fendor commented 7 years ago

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:

For Game Playing:

After the game has finished:

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

samuelpilz commented 7 years ago

Collaborating document on HackMd for further discussion.

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