RFC protocol

R-Type game network communication protocol

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

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). 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

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

10. Acknowledgments

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

Last updated