We will first describe some simple JSON values. We will use them later in more complicated
objects with the Syntax `"filedName" : <name>`. We will write standard JSON types in the same
way. (For example `<Number>` for a correct JSON number). If there are multiple allowed values we will
write it with a `|`, for example `"fieldName" : <Number>|<String>` if `"filedName"` may contain a
`<Number>` or a `<String>`.

For optional fields we write the corresponding value as `<Maybe name>`. Optional fields
may contain `null` instead of their value type, or may be completely omitted.

## DataTypes

### Tuples
wi will write tuples types as `<(A,B)>` for a Tuple containing something of `A` and
something of `B`. We will encode this as a JSON Array of length n, where n is the
length of the tuple.
For example a Value of `<(Number,String)>` might be `[5,"Hello World!"]`

### Lists
we will write `[A]` for the type of Lists containing stuff of type `A`. These are
encoded by Arrrays of arbitrary length.

### Tick
#### TickType
A TickType is one of the following Strings:
`"Abwarten"`,`"Bereithalten"`,`"Tick"`
#### Tick
A Tick is an Object of the following form:
```
{
"TickType" : <TickType>
"TickValue" : <Number>
}
```
The TickValue field is only requiered if the "TickType" field contains the Value "Tick"

### Player
#### UUID
we encode UUID as Strings of the following form:
"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
Where every x represents a character between 0 and f.

#### Player
A Player is either an UnknownPlayer or a KnownPlayer. Aka `<Player>`
is a synonym for `<KnownPlayer> | <UnknownPlayer>`. As a client you
will never generate UUIDs for Player. This is always the job of the Server.

##### KnownPlayer
```
{
"PlayerUUID" : <UUID>
"PlayerName" : <Maybe String>
}
```

If `"PlayerName"` is set, the Player has a new Name. The Server will always use KnownPlayer. If
you don't know that Player you should add it.

##### UnknownPlayer
```
{
"PlayerUUID" : <Maybe null>
"PlayerName" : <String>
}
```
Remark: `<Maybe null>` allows you to optionaly include this field with a `null` value. But
you might omit it.

UnknownPlayer are used to introduce new Player to the Server.

### TickLeiste
As every Session has exactly one TickLeiste attached to it, we never need to communicate an ID
for a TickLeiste. But we still have to versions of TickLeiste.

#### KnownTickLieste

```
[(<Tick>,[<KnownPlayer>])]
```
These are mainly used to communicate existing TickLeisten from the server to the client

#### UnknownTickLeiste
```
[(<Tick>,[<UnknownPlayer>])]
```
These are mainly used so the client can initialize a TickLeiste.

## Requests
a client is allowed to make the following Requests

### RequestType
Every Request has a field `"RequestType" : <RequestType>`. For
the allowed values of `<RequestType>` and the implication for the rest of
the corresponding fields, look at the documentation of the specific requests.

### SetPlayerTickR
This request is used to set a player to a specific Tick. If the Player is an
`UnknownPlayer` it will be added.
```
{
"RequestType" : "SetPlayerTickR",
"Player" : <Player>
"Tick" : <Tick>
}
```

### InitializeTickLeisteR

Initialize a new TickLeiste, either one saved on the client side,
to get a new empty one just set `"TickLeiste": []`

```
{
"RequestType" : "InitializeTickLeisteR",
"TickLeiste" : <UnknownTickLeiste>
}
```

### TickLeisteR
Request the current TickLeiste
```
{
"RequestType" : "TickLeisteR",
}
```
This is used to get the current TickLeiste from server. The server on its own will only
send incremental updates.


### ChangeNameR
This is used to change the name of a Player without moving them.
```
{
"RequestType" : "ChangeNameR",
"Player" : <KnownPlayer>
}
```
If you don't set the name in KnownPlayer no namechange will occur.

## Events
A Server might Send the following Events to a client.

### SetPlayerTickE
```
{
"EventType" : "SetPlayerTickE",
"Player" : <KnownPlayer>
"Tick" : <Tick>
}
```

### InitializeTickLeisteE
```
{
"EventType" : "InitializeTickLeisteE",
"TickLeiste" : <KnownTickLieste>
}
```