Парсер Хабра: Кроссплатформенный мультиплеер на Godot без боли

суббота, 30 января 2021 г.

Кроссплатформенный мультиплеер на Godot без боли

Что хотим сделать?

Синхронизацию действий игроков в игре с клиент-серверной архитектурой. Должна быть возможность играть из браузера.

Для примера реализуем простую чат-комнату:

При соединении:
1. Клиент получает уникальный ID;
2. Клиент получает информацию о всех остальных игроках (ID + имя);
3. Все остальные игроки получают информацию о новом игроке (ID + имя по умолчанию);
4. В консоли появляется сообщение о входе.
При потере соединения:
1. Все остальные игроки получают информацию о выходе игрока с сервера (ID);
2. В консоли появляется сообщение о выходе.
При изменении имени:
1. Если имя уже занято - игрок получает ошибку;
2. Все игроки уведомляются об изменении имени;
3. В консоли появляется сообщение.
При отправке сообщения в чат:
1. Все игроки видят сообщение в логе/консоли.

Примечание: ничего не мешает реализовать более сложный нетворкинг (например, передвижения игроков, какие-то другие действия) - но это выходит за рамки этой статьи и само по себе является достаточно сложной темой. Чат - это самый простой пример для демонстрации того, что такой подход для передачи данных, в принципе, работает - и цель моей статьи как раз в этом.

Что получилось?

Готовый проект можно изучить здесь: https://github.com/ktori/godobuf-over-websocket-demo

Скриншоты можно посмотреть в конце статьи.

Что будем использовать?

Godot - free and open source кроссплатформенный игровой движок;
Protobuf - механизм для эффективной сериализации/десериализации данных;
Godobuf - плагин для Godot, позволяющий генерировать .gd (GDScript) файлы из .proto;
Ktor - фреймворк для создания асинхронных сервисов Kotlin (в этой статье я буду использовать Kotlin - но бэкэнд может быть написан на любом другом языке, главное - иметь в фреймворке возможность принимать вебсокет-соединения и желательно - генератор кода из Protobuf, эти генераторы существуют для множества языков).

Плюсы этого подхода

Все сообщения, которыми обмениваются клиент и сервер, описываются в одном месте:
- Из этих файлов можно сразу сгенерировать код и для сервера и для клиента;
- В них же можно вести документацию, оставляя комментарии;
- Описание протокола можно легко хранить в любой VCS, т.к. по сути это просто текстовые файлы;
- Можно точно знать что обе стороны будут сериализовывать и десериализовывать сообщения одинаково - генерация кода обеспечит отсутствие забытых полей и каких-либо других ошибок свойственных при ручном чтении/записи.
Protobuf - бинарный формат, и в отличие от, например, JSON - будет использоваться меньший объем трафика для передачи одного и того же объема данных;
Protobuf позволяет добавлять новые поля, не ломая совместимость со старыми клиентами.

Минусы этого подхода

Совсем явных минусов я назвать не могу - но:

Сериализация/десериализация в protobuf будет проходить медленнее, чем, например, прямая запись в буфер в собственном формате;
Код, который генерируется из protobuf часто получается довольно громоздким и, соответственно, имеет определенную стоимость в рантайме.

Описание протокола

Готовый протофайл можно посмотреть здесь: game.proto

Создадим пустой .proto-файл, например - game.proto. В этом файле нужно описывать все сообщения, которыми будут обмениваться сервер и клиент (если сообщений будет много - можно выносить их в отдельные файлы и импортировать из основного).

В этот файл следует сразу прописать опции для парсера и кодогенератора:

syntax = "proto3";

// Название пакета
option java_package = "me.ktori.game.proto";
// Название класса в котором будут находиться подклассы сообщений
option java_outer_classname = "GameProto";

А теперь определимся, какие сообщения нам вообще нужны:

Сообщения клиент-сервер

Это сообщения, которые клиент отправляет серверу - часто они будут по сути RPC вызовами с ответом в сообщении Cl**Result от сервера. Здесь был бы очень кстати gRPC - возможно в будущем с помощью godobuf можно будет делать и gRPC-сервисы. Но пока:

//
// Сообщения клиент-сервер
//

// Запрос на изменение имени
message ClSetName {
  string name = 1;
}

// Отправка сообщения в чат
message ClSendChatMessage {
  string text = 1;
}

// Объединение всех сообщений, отсылаемых клиентом
message ClMessage {
  // Только одно из этих полей может быть заполнено, таким образом сервер
  // может быстро определить, что именно хочет сделать клиент
  oneof data {
    ClSetName set_name = 1;
    ClSendChatMessage send_chat_message = 2;
  }
}

Сообщения сервер-клиент

//
// Сообщения сервер-клиент
//

// Результат выполнения команды ClSetName
message ClSetNameResult {
  // Удалось ли изменить имя - имя нельзя изменить на уже занятое
  bool success = 1;
}

// Отсылается сервером - объединение всех возможных результатов выполнения команды от клиента
message ClMessageResult {
  oneof result {
    ClSetNameResult set_name = 1;
  }
}

// Отсылается клиенту один раз при соединении
// Получатель этого сообщения сохраняет у себя полученный ID и выданное сервером имя
message SvConnected {
  int32 id = 1;
  string name = 2;
}

// Уведомление о подключении нового клиента
// Получатель должен сохранить имя клиента по ID
message SvClientConnected {
  int32 id = 1;
  string name = 2;
}

// Уведомление об отключении клиента
// Получатель может удалить у себя информацию о клиенте по ID
message SvClientDisconnected {
  int32 id = 1;
}

// Уведомление об изменении имени
// Получатель должен изменить имя клиента по ID на новое
message SvNameChanged {
  int32 id = 1;
  string name = 2;
}

// Сообщение в чате
message SvChatMessage {
  int32 from = 1;
  string text = 2;
}

// Объединение всех сообщений которые сервер посылает клиенту
message SvMessage {
  // Только одно из этих полей будет заполнено в одном SvMessage
  oneof data {
    ClMessageResult result = 1;
    SvConnected connected = 2;
    SvClientConnected client_connected = 3;
    SvClientDisconnected client_disconnected = 4;
    SvNameChanged name_changed = 5;
    SvChatMessage chat_message = 6;
  }
}

Таким образом получаем следующую структуру:

Все возможные сообщения от клиента обернуты в ClMessage;
Все возможные сообщения от сервера обернуты в SvMessage;
- Ответы на вызовы клиента обернуты в поле result - сообщение ClMessageResult.

Лично для себя я определилась с такой naming convention:

ClFooBar для сообщений, которые шлёт клиент серверу;
SvFooBar для сообщений, которые шлёт сервер клиенту, за исключением:
ClFooBarResult для передачи результата обработки ClFooBar.

Создание клиентской части на Godot

Для начала нужно создать проект и основную сцену (обычную пустую 2D сцену).

Добавление плагина Godobuf

Плагин можно скачать здесь: https://github.com/oniksan/godobuf, инструкция по установке есть в README репозитория - нужно распаковать себе в проект папку addons.

Открытие соединения

Для соединения с сервером используется класс WebSocketClient (документация по WebSocketClient). Работать с ним просто: устанавливаем обработчики событий, а затем указываем URL сервера для соединения.

Создадим скрипт, который будет открывать соединение на корневой ноде сцены - там же будут заготовки для функций обработки событий от вебсокета:

extends Node2D

var ws: WebSocketClient

# Вызывается при загрузке сцены
func _ready():
    # Создаем WebSocketClient и подключаем обработчики событий
    ws = WebSocketClient.new()
    ws.connect("connection_established", self, "_on_ws_connection_established")
    ws.connect("data_received", self, "_on_ws_data_received")
    # Подключаемся к локалхосту по порту 8080
    ws.connect_to_url("ws://127.0.0.1:8080")

# Будет вызываться при установке соединения
func _on_ws_connection_established(_protocol):
    pass

# Будет вызываться при получении сообщений из вебсокета
func _on_ws_data_received():
    pass

Генерация биндингов protobuf:GDScript

Здесь всё очень просто! Во вкладке Godobuf указываем путь до нашего proto-файла и путь куда будет сохранен получившийся скрипт:

Если в прото-файле нет ошибок, то мы увидим сообщение об успешной компиляции и в папке проекта появится нужный скрипт.

Отправка сообщений

Настройка сцены

В своей сцене я сделала отдельный контейнер для сообщений и два поля - для ввода текста и имени. Сигналы pressed от кнопок Send и Rename я подключила в скрипт на корневой ноде. Также для вывода сообщений на сцену я сделала функцию show_message, она просто добавляет новый объект Label с текстом сообщения в VBoxContainer, который располагает объекты вертикально.

Отправка запросов на сервер

После создания этих полей ввода и кнопок нужно сделать так чтобы они что-то делали.

Сперва загрузим получившиеся биндинги в наш скрипт:

const GameProto = preload("res://game_proto.gd")

Теперь можно добавить код создания ClMessage при нажатии на кнопки Send/Rename:

# Изменяем имя на введенное в $Name
func _on_SetName_pressed():
    var msg = GameProto.ClMessage.new()
    var sn = msg.new_set_name()
    sn.set_name(name_input.text)
    send_msg(msg)

# Отправляем сообщение из $Message и очищаем поле
func _on_SendMessage_pressed():
    var msg = GameProto.ClMessage.new()
    var scm = msg.new_send_chat_message()
    scm.set_text(message_input.text)
    message_input.clear()
    send_msg(msg)

Самое интересное - сама отправка сообщения по вебсокету происходит в функции send_msg. Вот она:

# Отправляет ClMessage на сервер
func send_msg(msg: GameProto.ClMessage):
    # Конвертируем ClMessage в PoolByteArray и отправляем его по соединению ws
    ws.get_peer(1).put_packet(msg.to_bytes())

Функция to_bytes (как и весь класс ClMessage) сгенерированы плагином godobuf - и никаких операций с буферами руками нам делать не надо!

Обработка сообщений

Теперь наш клиент может отправлять сообщения - но он ещё не способен их принимать. Сейчас мы это исправим, добавив обработку входящих сообщений - этот блок кода будет объемнее, но по большей части код там повторяется.

Код получения и обработки сообщений

# Вызывается часто по интервалу
func _process(_delta):
    # Производит чтение из вебсокета, читает входящие сообщения
    ws.poll()

# Будет вызываться при установке соединения
func _on_ws_connection_established(_protocol):
    show_message("Connection established!")

# Будет вызываться при получении сообщений из вебсокета
func _on_ws_data_received():
    # Обработка каждого пакета в очереди
    for i in range(ws.get_peer(1).get_available_packet_count()):
        # Сырые данные из пакета
        var bytes = ws.get_peer(1).get_packet()
        var sv_msg = GameProto.SvMessage.new()
        # Превращение массива байтов в структурированное сообщение
        sv_msg.from_bytes(bytes)
        # Обрабатываем уже сконвертированное сообщение
        _on_proto_msg_received(sv_msg)

# Будет вызываться после чтения и конвертации сообщения из вебсокета
func _on_proto_msg_received(msg: GameProto.SvMessage):
    # т.к. все эти поля находятся в блоке oneof - заполнено может быть только
    # одно из них
    if msg.has_connected():
        pass
    elif msg.has_client_connected():
        pass
    elif msg.has_client_disconnected():
        pass
    elif msg.has_chat_message():
        pass
    elif msg.has_name_changed():
        pass
    elif msg.has_result():
        pass
    else:
        push_warning("Received unknown message: %s" % msg.to_string())

Важно периодически вызывать poll на WebSocketClient, иначе сигналы о входящих сообщениях никогда не придут. В данном случае это происходит в _process

После этого остается только заполнить логику обработки конкретных сообщений - но сначала добавим хранилище известных клиенту имён и переменную для ID текущего клиента:

# Хранит ID этого клиента
var own_id: int
# Хранит пары ID <> Имя
var names = Dictionary()

И обработку одного из возможных сообщений с сервера:

# Внутри _on_proto_msg_received
  if msg.has_connected():
                var c = msg.get_connected()
                own_id = c.get_id()
                name_input.text = c.get_name()
                show_message("Welcome! Your ID is %d and your assigned name is '%s'." % [c.get_id(), c.get_name()])

Остальные блоки в этом if/elif примерно одинаковы. Получившийся код для каждого отдельного сообщения можно посмотреть на GitHub: Main.gd

Серверная часть

Серверная часть очень подробно разбираться не будет. Её можно написать на любом языке - и в данном случае это будет Kotlin с фреймворком Ktor. Напоминаю, что весь код этого проекта доступен на GitHub - сервер там достаточно простой. Но в двух словах выделю основные моменты моей

сервера:

Структура проекта

Основной gradle-проект состоит из двух модулей:

server - сам сервер;
proto - прото-файлы и сгенерированные из них биндинги:
- Стоит обратить внимание на плагин com.google.protobuf, зависимость com.google.protobuf:protobuf-java и их конфигурацию;
- В процессе сборки этого модуля генерируются классы, позволяющие сериализовывать/десериализовывать сообщения описанные в прото-файле.

Сам сервер работает по простому алгоритму - хранит открытые соединения, broadcast-канал для уведомлений и сообщений, принимает сообщения от клиента пока это возможно и отвечает на его запросы.

Результаты

Получившийся Godot-проект может работать как из браузера, так и с нативных сборок под Linux/Windows/Android и т.д. - всё взаимодействие клиента с сервером описывается в одном месте и в протокол легко вносить изменения.

Скриншоты

Заключение

В этой статье рассматриваются только самые основы этого метода. Помимо того что написано здесь, будет важно реализовать:

Обработку ошибок (например, передавать отдельное сообщение error в ClMessageResult);
Обработку потери/восстановления соединения;
Многое другое.

Я надеюсь эта статья оказалась полезной и помогла разобраться в Godot, вебсокетах и protobuf.

Let's block ads! (Why?)

Парсер Хабра

...

суббота, 30 января 2021 г.

Кроссплатформенный мультиплеер на Godot без боли

Что хотим сделать?

Что получилось?

Что будем использовать?

Плюсы этого подхода

Минусы этого подхода

Описание протокола

Сообщения клиент-сервер

Сообщения сервер-клиент

Создание клиентской части на Godot

Добавление плагина Godobuf

Открытие соединения

Генерация биндингов protobuf:GDScript

Отправка сообщений

Настройка сцены

Отправка запросов на сервер

Обработка сообщений

Серверная часть

Структура проекта

Результаты

Скриншоты

Заключение

Комментариев нет:

Отправить комментарий

...

суббота, 30 января 2021 г.

Кроссплатформенный мультиплеер на Godot без боли

Что хотим сделать?

Что получилось?

Что будем использовать?

Плюсы этого подхода

Минусы этого подхода

Описание протокола

Сообщения клиент-сервер

Сообщения сервер-клиент

Создание клиентской части на Godot

Добавление плагина Godobuf

Открытие соединения

Генерация биндингов protobuf:GDScript

Отправка сообщений

Настройка сцены

Отправка запросов на сервер

Обработка сообщений

Серверная часть

Структура проекта

Результаты

Скриншоты

Заключение

Комментариев нет:

Отправить комментарий

суббота, 30 января 2021 г.