Рады снова опубликовать очередную порцию материала по разработке игры Galaxy Boom mini. С момента последней публикации мы много работали над системой сетевого обмена данными. Стоит сказать, что изначально это была простая сетевая библиотека, написанная еще задолго до старта разработки, когда мы собирали сведения по некоторым областям, с которыми нам придется столкнуться в процессе написания игры. Это были области графики (движок Perfect Engine 3), общей структуры (система ECS, парсинг JSON-файлов и RTTI-сериализация) и несколько других областей, в число которых входила область работы с сетью.

Тогда мы узнали основные понятия: TCP/UDP, сокеты, потоки…, а также, выбрали наиболее подходящую для наших целей библиотеку, реализующую базовый набор функций для сетевой разработки.

Изначально была реализована простая сетевая библиотека, которая довольно неплохо справлялась с задачей обмена сообщениями и поддерживала самые необходимые события: подключение и отключение клиента, отключение при потере связи с сервером и обмен сообщениями в целом.

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

Новый набор событий позволяет полностью контролировать поведение клиентов и сервера в плане подключения, отключения, неожиданной потери соединения, смены клиентских параметров, отслеживания заполненности сервера (и вообще, запрета на подключение с передачей клиенту информации о причине запрета). Есть, также, заготовка для синхронизации и сброса времени; временная метка добавлена и в заголовок сообщения.

Библиотека состоит из трех уровней:

1. Непосредственная реализация сокета и клинетского класса, которые используются как в реализации клиента, так и в реализации сервера (список клиентов).
2. Системная реализация клиента и сервера (два разных модуля) с поддержкой общих возможностей, не привязанных к конкретной программе.
3. Пользовательская надстройка над классами клиента и сервера для реализации возможностей, связанных с текущей программой. Здесь могут быть описаны обработчики дополнительных сообщений, и сюда же планируется в дальнейшем внедрение базовых механизмов работы с хронологиями.

Сетевая библиотека основана на потоках, что значительно усложняет ее структуру и процесс отладки, особенно, учитывая, что это наша первая серьезная работа с потоками. Сейчас мы работаем над тестовой программой и надеемся, что процесс не слишком затянется, и вскоре мы сможем поделиться ею со своим безмолвным читателем. А в планах на ближайшее будущее — синхронизация времени с использованием алгоритма Беркли и тестирование хронологической модели в боевых условиях.

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

Мы перевели статью, о которой писали ранее, и начали думать над реализацией хронологического метода программирования в Delphi. Для этого нам понадобилось разработать свой метод хранения значений хронологических типов данных. Согласно статье, хронология представляет собой набор элементов — состояний, каждое из которых содержит значение и временную метку. Временная метка для всех хронологических типов данных представлена как целое число — время с момента запуска программы в мс. А значения для каждого хронологического типа могут быть разными, от простых целых чисел, до сложных структур.

Поэтому мы сделали запись типа TTimelineState — состояние хронологического значения, — содержащую два поля: «value: TValue» и «time: Cardinal». Тип данных TValue дал возможность хранить в этом поле значения любого типа, что обеспечило нам реализацию любых хронологических типов. Далее нужно было решить, как структурировать хранимые значения — все состояния должны храниться в каком-то массиве или списке. Выбор варианта хранения во многом зависел от требований доступа к этим данным. Согласно описанным в статье принципам, эти требования можно сформулировать так:

• Запись значений по абсолютному времени
• Считывание значений по относительному времени (текущее время со смещением)
• Считывание ближайших предыдущих и ближайших следующих значений по абсолютному времени

Приветствую тебя, мой безмолвный читатель. Рад сообщить, что процесс разработки игры доведен до первой обозначенной нами контрольной точки. Прошло каких-то несколько месяцев, и вот уже мы имеем возможность двигать по экрану первый квадратик. Это, несомненно, успех. Такого результата можно было бы достичь намного раньше, если бы перед нами не встала необходимость разработки крупных модулей UI, ECS и Perfect Engine, работу над которыми мы планировали проводить значительно позднее. Однако, их наличие необходимо для реализации заготовки крупного проекта, чем на данный момент и является наша тестовая программа.

В этом сообщении я опишу структуру проекта, а ниже, по традиции, выложу ссылку на саму программу.

Состав игры

Графический движок Perfect Engine

Основные моменты, касающиеся новой версии графического движка Perfect Engine, уже были описаны в одном из сообщений выше. Конечно, за это время в нем произошло много структурных изменений (например, было введено понятие «Слой»), но здесь я коснусь этого вопроса поверхностно, надеясь в будущем посвятить описанию движка отдельное сообщение.

Основным персонажем вселенной Galaxy Boom, несомненно, всегда являлся Луч — маленький робот, по воле случая ставший центром большой войны, чье предназначение раскрывается по ходу глобального сюжета, и чей вклад в финал общей истории, поистине, неоценим.

Теперь же мы рады представить новую историю — второстепенную, но не менее важную для мира Galaxy Boom — историю нашего нового персонажа, Позитрона, повествующую о защите космических платформ от первых нападений войск Бета. Позитрон — робот, пытающийся найти свое предназначение, определить, кем он является и как может послужить силам Альфа в борьбе с общим врагом. Неизгладимое впечатление на этого персонажа произвела его краткая встреча с Лучом во время одной битвы, благодаря которой ему стали открываться некоторые необычные свойства окружающих его предметов.

Подробнее о персонаже и об иллюстрации

Со времени последнего сообщения прошло довольно много времени, в течение которого работа над проектом не прекращалась. В систему графического интерфейса за этот период было внесено много изменений, а некоторые основополагающие моменты и вовсе были полностью переосмыслены. В основном, все изменения коснулись библиотеки графического интерфейса, именно над ней и велась работка в последние месяцы.

Серьезному структурному изменению подвергся механизм работы со сценами. Если раньше существовали такие понятия как «Текущая сцена» и «Главная сцена», то теперь они упразднены, и на смену им пришел механизм состояний. Состояние — это набор сцен, которые включаются при его активации. Необходимость реализации такого подхода обусловлена недостаточностью вывода единовременно только одной сцены для реализации всех игровых ситуаций. Например, когда надо одновременно вывести на экран игровой интерфейс и интерфейс меню паузы — при старом подходе с одной активной сценой при активации меню паузы пропадут все элементы интерфейса с игровой сцены.