> For the complete documentation index, see [llms.txt](https://redboard.gitbook.io/r-type-1/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://redboard.gitbook.io/r-type-1/rfc-protocol.md).

# RFC protocol

```txt
RFC 10000: R-Type network communication protocol
Date: 2023-09-27
Author(s): Martin d'Hérouville <martin.d-herouville@epitech.eu>
Status: Standards Track
```

### Description

R-Type is a game created in 1987. It is a side-scrolling shoot-em-up game. The player controls a spaceship and must destroy enemies and bosses to finish the level. The player can also collect power-ups to upgrade his spaceship. We re-created this game in 2023 with the same gameplay, but with better graphics and sound, and with new features including a multiplayer mode. This version of the game is a network game. The player can play with other players on the same server.

### Table of contents

1. [Introduction](#1.-introduction)
2. [Motivation](#2.-motivation)
3. [Requirements and Specifications](#3.-requirements-and-specifications)
   1. [Data Format](#3.1.-data-format)
   2. [Data Types](#3.2.-data-types)
4. [Message Descriptions](#4.-message-descriptions)
   1. [Screen Progression](#4.1.-screen-progression)
   2. [Player Asking to Move](#4.2.-player-asking-to-move)
   3. [Player Position](#4.3.-player-position)
   4. [Missile Position](#4.4.-missile-position)
   5. [Player Asking to Shoot](#4.5.-player-asking-to-shoot)
   6. [Player Score](#4.6.-player-score)
   7. [Enemy Position](#4.7.-enemy-position)
   8. [Player Asking to Create a Room](#4.8.-player-asking-to-create-a-room)
   9. [Player Asking to Join a Room](#4.9.-player-asking-to-join-a-room)
   10. [Room Joined](#4.10.-room-joined)
   11. [Time Before the Game Starts](#4.11.-time-before-the-game-starts)
   12. [Client Ping](#4.12.-client-ping)
   13. [Other Player Joined Game](#4.13.-other-player-joined-game)
   14. [Other Player Left Game](#4.14.-other-player-left-game)
   15. [Missile Destroyed](#4.15.-missile-destroyed)
   16. [Enemy Died](#4.16.-enemy-died)
   17. [Game Over](#4.17.-game-over)
   18. [Player Died](#4.18.-player-died)
   19. [Current Player's Life](#4.19.-current-players-life)
   20. [Monster's Life](#4.20.-monsters-life)
   21. [Color Strobe](#4.21.-color-strobe)
   22. [Next Level Starting](#4.22.-next-level-starting)
   23. [Latency](#4.23.-latency)
   24. [Quit Current Room](#4.24.-quit-current-room)
   25. [Join Specific Room](#4.25.-join-specific-room)
   26. [Ask to List Available Rooms](#4.26.-ask-to-list-available-rooms)
   27. [Available Room List](#4.27.-available-room-list)
   28. [Bonus Position](#4.28.-bonus-position)
   29. [Bonus Destroyed](#4.29.-bonus-destroyed)
   30. [Fire Bomb](#4.30.-fire-bomb)
   31. [Bomb Position](#4.31.-bomb-position)
   32. [Bomb Destroyed](#4.32.-bomb-destroyed)
   33. [New Chat Message](#4.33.-new-chat-message)
   34. [Send Chat Message in the Room](#4.34.-send-chat-message-in-the-room)
   35. [Player Pod Level](#4.35.-player-pod-level)
5. [Communication Flow](#5.-communication-flow)
6. [Security and Error Handling](#6.-security-and-error-handling)
7. [References](#7.-references)
8. [Copyright](#8.-copyright)
9. [Authors](#9.-authors)
10. [Acknowledgments](#10.-acknowledgments)

***

### 1. Introduction

This RFC defines the communication protocol between the server and the client for the network game "R-Type". The server is the host of the game, and the client is the player.

### 2. Motivation

The protocol is designed to facilitate efficient and secure communication between the server and the client, necessary for the networking features of the game.

### 3. Requirements and Specifications

This section details the requirements and specifications of the protocol.

#### 3.1. Data Format

This protocol is designed to be used with the UDP protocol [(1)](#7.-references). The server and the client communicate with each other by sending and receiving datas. Datas are formatted using binary. Each command sent begins with one byte indicating the type of the data, followed by the data itself. Each command has a known size, this way both the server and the client can split the commands recieved.

#### 3.2. Data Types

Here is the list of the data types. The description of each data type is detailed in the next section. When a data type is sent by the server, it is prefixed by letter "s". When a data type is sent by the client, it is prefixed by the letter "c".

* s-1 = screen progression
* c-2 = player asking to move
* s-3 = player position
* s-4 = missile position
* c-5 = player asking to shoot
* s-6 = player score
* s-7 = enemy position
* c-8 = player asking to create a room
* c-9 = player asking to join a room
* s-10 = room joined
* s-11 = time before the game starts
* c-12 = client ping
* s-13 = other player joined game
* s-14 = other player left game
* s-15 = missile destroyed
* s-16 = enemy died
* s-17 = game over
* s-18 = player died
* s-19 = current player's life
* s-20 = monster's life
* s-21 = color strobe
* s-22 = next level starting
* s-23 = latency
* c-24 = quit current room
* c-25 = join specific room
* c-26 = ask to list available rooms
* s-27 = available room list
* s-28 = bonus position
* s-29 = bonus destroyed
* c-30 = fire bomb
* s-31 = bomb position
* s-32 = bomb destroyed
* s-33 = new chat message
* c-34 = send chat message in the room
* s-35 = player pod level

### 4. Message Descriptions

This section details each message type.

#### 4.1. Screen Progression

This message is sent by the server to the client to indicate the progression of the screen.

**4.1.1. Message size**

The message is 5 bytes long.

**4.1.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (1)
* 4 byte: position of the screen (int)

**4.1.3. Message Example**

```
0x01 0x00 0x00 0x00 0x01
```

#### 4.2. Player Asking to Move

This message is sent by the client to the server to indicate that the player wants to move.

**4.2.1. Message size**

The message is 3 bytes long.

**4.2.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (2)
* 1 byte: direction (char) -> 1 = up ; 2 = down ; 4 = left ; 8 = right
* 1 byte: number of times (char) -> 0-255

**4.2.3. Message Example**

```
0x02 0x01 0x01
```

#### 4.3. Player Position

This message is sent by the server to the client to indicate the position of a player. It is sent every time that a player moves.

**4.3.1. Message size**

The message is 6 bytes long.

**4.3.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (3)
* 1 byte: player id (char)
* 2 byte: position x (short)
* 2 byte: position y (short)

**4.3.3. Message Example**

```
0x03 0x01 0x00 0x01 0x00 0x01
```

#### 4.4. Missile Position

This message is sent by the server to the client to indicate the position of a missile.

**4.4.1. Message size**

The message is 10 bytes long.

**4.4.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (4)
* 4 byte: missile id (int)
* 1 byte: missile type (char) -> 1 = player ; 2 = enemy
* 2 byte: position x (short)
* 2 byte: position y (short)

**4.4.3. Message Example**

```
0x04 0x00 0x00 0x00 0x01 0x02 0x00 0x01 0x00 0x01
```

#### 4.5. Player Asking to Shoot

This message is sent by the client to the server to indicate that the player wants to shoot.

**4.5.1. Message size**

The message is 1 byte long.

**4.5.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (5)

**4.5.3. Message Example**

```
0x05
```

#### 4.6. Player Score

This message is sent by the server to the client to indicate the score of the player (the client).

**4.6.1. Message size**

The message is 5 bytes long.

**4.6.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (6)
* 4 byte: score (int)

**4.6.3. Message Example**

```
0x06 0x00 0x00 0x00 0x01
```

#### 4.7. Enemy Position

This message is sent by the server to the client to indicate the position of an enemy.

**4.7.1. Message size**

The message is 6 bytes long.

**4.7.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (7)
* 1 byte: enemy id (char)
* 2 byte: position x (short)
* 2 byte: position y (short)

**4.7.3. Message Example**

```
0x07 0x01 0x00 0x01 0x00 0x01
```

#### 4.8. Player Asking to Create a Room

This message is sent by the client to the server to indicate that the player wants to create a room.

**4.8.1. Message size**

The message is 2 bytes long.

**4.8.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (8)
* 1 byte: booleen private room (char) -> 0 = public ; 1 = private

**4.8.3. Message Example**

```
0x08 0x00
```

#### 4.9. Player Asking to Join a Room

This message is sent by the client to the server to indicate that the player wants to join a room.

**4.9.1. Message size**

The message is 1 bytes long.

**4.9.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (9)

**4.9.3. Message Example**

```
0x09
```

#### 4.10. Room Joined

This message is sent by the server to the client to indicate that he joined a room.

**4.10.1. Message size**

The message is 4 bytes long.

**4.10.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (10)
* 2 byte: room id (short)
* 1 byte: player id (char)

**4.10.3. Message Example**

```
0x0A 0x00 0x01 0x01
```

#### 4.11. Time Before the Game Starts

This message is sent by the server to the client to indicate the time before the game starts.

**4.11.1. Message size**

The message is 6 bytes long.

**4.11.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (11)
* 4 byte: time before the game starts in seconds (int)
* 1 byte: booleen game started (char) -> 0 = false ; 1 = true

**4.11.3. Message Example**

```
0x0B 0x00 0x00 0x00 0x01 0x01
```

#### 4.12. Client Ping

This message is sent by the client to the server to indicate that he is still connected.

**4.12.1. Message size**

The message is 1 bytes long.

**4.12.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (12)

**4.12.3. Message Example**

```
0x0C
```

#### 4.13. Other Player Joined Game

This message is sent by the server to the client to indicate that another player joined the game.

**4.13.1. Message size**

The message is 2 bytes long.

**4.13.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (13)
* 1 byte: player id (char)

**4.13.3. Message Example**

```
0x0D 0x01
```

#### 4.14. Other Player Left Game

This message is sent by the server to the client to indicate that another player left the game.

**4.14.1. Message size**

The message is 2 bytes long.

**4.14.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (14)
* 1 byte: player id (char)

**4.14.3. Message Example**

```
0x0E 0x01
```

#### 4.15. Missile Destroyed

This message is sent by the server to the client to indicate that a missile has been destroyed (hit an enemy or a player, or went out of the screen).

**4.15.1. Message size**

The message is 10 bytes long.

**4.15.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (15)
* 4 byte: missile id (int)
* 1 byte: missile type (char) -> 1 = player ; 2 = enemy
* 2 byte: position x (short)
* 2 byte: position y (short)

**4.15.3. Message Example**

```
0x0F 0x00 0x00 0x00 0x01 0x02 0x00 0x01 0x00 0x01
```

#### 4.16. Enemy Died

This message is sent by the server to the client to indicate that an enemy has been destroyed.

**4.16.1. Message size**

This message is 5 bytes long.

**4.16.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (16)
* 4 byte: enemy id (int)

**4.16.3. Message Example**

```
0x10 0x00 0x00 0x00 0x01
```

#### 4.17. Game Over

This message is sent by the server to the client to indicate that the game is over.

**4.17.1. Message size**

This message is 2 byte long.

**4.17.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (17)
* 1 byte: type (char)

**4.17.3. Message Example**

```
0x11 0x00
```

#### 4.18. Player Died

This message is sent by the server to the client to indicate that a player died.

**4.18.1. Message size**

This message is 5 byte long.

**4.18.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (18)
* 4 byte: player id (int)

**4.18.3. Message Example**

```
0x12 0x00 0x00 0x00 0x01
```

#### 4.19. Current Player's Life

This message is sent by the server to the client to indicate the current player's life.

**4.19.1. Message size**

This message is 5 byte long.

**4.19.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (19)
* 4 byte: player life (int)

**4.19.3. Message Example**

```
0x13 0x00 0x00 0x00 0x01
```

#### 4.20. Monster's Life

This message is sent by the server to the client to indicate the monster's life.

**4.20.1. Message size**

This message is 9 byte long.

**4.20.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (20)
* 4 byte: monster id (int)
* 4 byte: monster life (int)

**4.20.3. Message Example**

```
0x14 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x01
```

#### 4.21. Color Strobe

This message is sent by the server to the client to tell the client to display a color strobe effect on the screen.

**4.21.1. Message size**

This message is 3 byte long.

**4.21.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (21)
* 1 byte: color (char)
* 1 byte: on/off (char) -> 0 = off ; 1 = on

**4.21.3. Message Example**

```
0x15 0x01 0x01
```

#### 4.22. Next Level Starting

This message is sent by the server to the client to tell the client that the next level is starting.

**4.22.1. Message size**

This message is 7 byte long.

**4.22.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (22)
* 4 byte: time before the next level starts (int)
* 1 byte: song to play during the next level (char)
* 1 byte: bool started (char) -> 0 = false ; 1 = true

**4.22.3. Message Example**

```
0x16 0x00 0x00 0x00 0x01 0x01 0x01
```

#### 4.23. Latency

This message is sent by the server to the client to tell the client the latency between the both.

**4.23.1. Message size**

This message is 3 byte long.

**4.23.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (23)
* 2 byte: latency in milliseconds (short)

**4.23.3. Message Example**

```
0x17 0x00 0x01
```

#### 4.24. Quit Current Room

This message is sent by the client to the server to tell the server that the client wants to quit the current room.

**4.24.1. Message size**

This message is 1 byte long.

**4.24.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (24)

**4.24.3. Message Example**

```
0x18
```

#### 4.25. Join Specific Room

This message is sent by the client to the server to tell the server that the client wants to join a specific room.

**4.25.1. Message size**

This message is 5 byte long.

**4.25.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (25)
* 4 byte: room id (int)

**4.25.3. Message Example**

```
0x19 0x00 0x00 0x00 0x01
```

#### 4.26. Ask to List Available Rooms

This message is sent by the client to the server to ask a list of the available rooms.

**4.26.1. Message size**

This message is 1 byte long.

**4.26.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (26)

**4.26.3. Message Example**

```
0x1A
```

#### 4.27. Available Room List

This message is sent by the server to the client to give him the list of the available rooms. This message is sent once for each room.

**4.27.1. Message size**

This message is 8 byte long.

**4.27.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (27)
* 4 byte: room id (int)
* 1 byte: number of players in the room (char)
* 1 byte: max number of players in the room (char)
* 1 byte: bool is joinable (char) -> 0 = false ; 1 = true

**4.27.3. Message Example**

```
0x1B 0x00 0x00 0x00 0x01 0x01 0x01 0x01
```

#### 4.28. Bonus Position

This message is sent by the server to the client to indicate the position of a bonus.

**4.28.1. Message size**

The message is 10 bytes long.

**4.28.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (28)
* 4 byte: bonus id (int)
* 1 byte: bonus type (char)
* 2 byte: position x (short)
* 2 byte: position y (short)

**4.28.3. Message Example**

```
0x1C 0x00 0x00 0x00 0x01 0x01 0x00 0x01 0x00 0x01
```

#### 4.29. Bonus Destroyed

This message is sent by the server to the client to indicate that a bonus has been destroyed.

**4.29.1. Message size**

The message is 5 bytes long.

**4.29.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (29)
* 4 byte: bonus id (int)

**4.29.3. Message Example**

```
0x1D 0x00 0x00 0x00 0x01
```

#### 4.30. Fire Bomb

This message is sent by the client to the server to indicate that the player wants to fire a bomb.

**4.30.1. Message size**

The message is 1 byte long.

**4.30.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (30)

**4.30.3. Message Example**

```
0x1E
```

#### 4.31. Bomb Position

This message is sent by the server to the client to indicate the position of a bomb.

**4.31.1. Message size**

The message is 9 bytes long.

**4.31.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (31)
* 4 byte: bomb id (int)
* 2 byte: position x (short)
* 2 byte: position y (short)

**4.31.3. Message Example**

```
0x1F 0x00 0x00 0x00 0x01 0x00 0x01 0x00 0x01
```

#### 4.32. Bomb Destroyed

This message is sent by the server to the client to indicate that a bomb has been destroyed.

**4.32.1. Message size**

The message is 5 bytes long.

**4.32.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (32)
* 4 byte: bomb id (int)

**4.32.3. Message Example**

```
0x20 0x00 0x00 0x00 0x01
```

#### 4.33. New Chat Message

This message is sent by the server to the client to indicate that a new chat message has been sent by a player. The string containing the message must contain exactly 1000 characters. It begins with the message itself and it ends with many '\0' characters to fill the 1000 characters.

**4.33.1. Message size**

The message is 1005 bytes long.

**4.33.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (33)
* 4 byte: player id (int)
* 1000 byte: message (char \*)

**4.33.3. Message Example**

```
0x21 0x00 0x00 0x00 0x01 0x48 0x65 0x6C 0x6C 0x6F 0x20 0x77 0x6F 0x72 0x6C 0x64 0x21 0x00 0x00 0x00 0x00 0x00 0x00 ...
```

#### 4.34. Send Chat Message in the Room

This message is sent by the client to the server to indicate that the client wants to send a chat message in the room. The string containing the message must contain exactly 1000 characters. It begins with the message itself and it ends with many '\0' characters to fill the 1000 characters.

**4.34.1. Message size**

The message is 1001 bytes long.

**4.34.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (34)
* 1000 byte: message (char \*)

**4.34.3. Message Example**

```
0x22 0x48 0x65 0x6C 0x6C 0x6F 0x20 0x77 0x6F 0x72 0x6C 0x64 0x21 0x00 0x00 0x00 0x00 0x00 0x00 ...
```

#### 4.35. Player Pod Level

This message is sent by the server to the client to indicate the player pod level.

**4.35.1. Message size**

The message is 7 bytes long.

**4.35.2. Message Format**

The message is formatted as follows:

* 1 byte: message type (35)
* 4 byte: player id (int)
* 1 byte: pod level (char)
* 1 byte: front (char)

**4.35.3. Message Example**

```
0x23 0x00 0x00 0x00 0x01 0x01 0x01
```

### 5. Communication Flow

Each message is sent by the server to the client or by the client to the server. The server and the client can send and receive messages at any time. If the server does not receive a message from the client during 10 seconds, the client is considered disconnected.

### 6. Security and Error Handling

If a command is not recognized by the server or the client, they won't do anything.

### 7. References

\[1] UDP protocol (RFC 768):

* <https://tools.ietf.org/html/rfc768>
* <https://www.ietf.org/rfc/rfc768.txt>

### 8. Copyright

```
Copyright (c) 2023 EpitechPromo2026

Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files
(the "Software"), to deal in the Software without restriction,
including without limitation the rights to use, copy, modify, merge,
publish, distribute, sublicense, and/or sell copies of the Software,
and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
```

### 9. Authors

* Martin d'Hérouville <martin.d-herouville@epitech.eu>
* David Benistant <david.benistant@epitech.eu>
* Thomas Ott <thomas.ott@epitech.eu>
* Oscar Frank <oscar.frank@epitech.eu>
* Lucas Binder <lucas.binder@epitech.eu>

### 10. Acknowledgments

Acknowledge anyone or any organization that contributed to the development of this protocol.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://redboard.gitbook.io/r-type-1/rfc-protocol.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.