Многопользовательские игровые приложения.
Большим шагом в многопользовательских играх стало реализацией модели «клиент-сервер», которая пришла на смену модели «точка-точка».
При работе с «клиент-серверной» моделью все игроки подключаются к центральному серверу, когда в модели «точка-точка» каждому игроку необходимо связаться со всеми остальными игроками.
Получается, что при использовании модели «точка-точка» нам необходима пропускная способность равная О(n²), то есть она должна расти в квадратичной прогрессии при увеличении количества игроков. Из этого можно сделать вывод что данная модель не подходит для многопользовательских игр.
В свою очередь модель «клиент-сервер» использует постоянную величину скорости соединения для каждого клиента, но при этом сервер должен иметь пропускную способность равную O(n).
Рассмотрим как-же устроена модель «клиент-сервер» на примере игры «Tribes».
Все сетевые операции были разбиты на несколько уровней.
Модуль обслуживания пакетов.
В модели модуль обслуживания пакетов образует самый нижний уровень. Этот уровень служит оберткой для стандартного API сокетов, с помощью которого происходит передача пакетов различных форматов.
Диспетчер соединений.
Задачей диспетчера соединений является прием данных от уровня диспетчера потоков и передавать их на уровень ниже – модуль обслуживания пакетов.
Диспетчер соединений не гарантирует доставку пакета, но гарантирует возврат уведомления о доставке, т.е. дает возможность проверить состояние запроса, переданного диспетчеру соединений. Это дает возможность уровню диспетчеру потоков узнать, были ли доставлены отправленные им данные.
Диспетчер потоков.
Задачей диспетчера потоков является передача данных диспетчеру соединений. Одной из важнейших подзадач является определение максимальной скорости передачи данных. Она непосредственно зависит от скорости подключения к интернету. Информация о соединении с клиентом необходима серверу, чтобы гарантировать, что сервер не завалит клиента большим объемом передаваемых данных. Диспетчер потоков также отвечает за ранжирование запросов по приоритетам. Информация от диспетчеров перемещений, событий и фантомов получает наивысший приоритет.
Так как размер пакетов и интервал следования ограничен, диспетчер потоков может поместить в один пакет различные данные. Например, один пакет может в себе содержать информацию от диспетчера перемещений, событий и фантомов.
Диспетчер событий.
Диспетчер событий, обрабатывает очередь событий, генерируемых уровнем моли игры.
Когда игрок производит выстрел диспетчеру событий передается информация об этом событии. Затем это событие отправляется на сервер где проверяется его корректность, после чего оно выполнятеся.
Диспетчер фантомов.
Задачей диспетчера фантомов является хранение дубликатов динамических объектов, которые необходимы для каждого конкретного клиента. Так сервер посылает каждому клиенту информацию о тех динамических объектах о которых по мнению сервера клиент должен знать на текущий момент. Определением о каких объектах должен знать игрок определяет уровень модели игры. Перед передачей фантомных записей объекты упорядочиваются по изменению состояния, и по уровню приоритета. После того как диспетчер фантомов определит какие объекты должны передаваться их данные добавляют в пакет.
Диспетчер перемещений.
Задачей диспетчера перемещений является быстрая передача информации о перемещении игроков. Если информация о позиции игрока будет передаваться медленно, то другие участники игры могут пытаться стрелять в то место, где игрок был совсем недавно. Из-за этого могут складываться ошибочные представления об обстановке в игре.
В динамических играх диспетчер перемещений имеет наивысший приоритет, так как частота обновления информации о перемещении должна отправляться 30 раз в секунду. Т.е. игра должна каждую 1/30 секунды отправлять информацию о перемещении. По этой причине данные от диспетчера перемещений добавляются в пакет в первую очередь. После чего пакеты отправляются на сервер где они используются в уровень модели игры, после чего клиенту отправляется подтверждение приема сведений.
Остальные системы.
Существуют и другие системы которые могут отвечать за обслуживание статических игровых объектов. Таких как пулеметная установка, которая не может перемещаться, но при этом может взаимодействовать с игроком.
Другие многопользовательские игры могут использовать другую модель, но принцип работы у всех примерно одинаков.
Из всего выше сказанного можно сделать следующие выводы.
Первое, при проектировании разработке многопользовательских игр необходимо учитывать много параметров.
Второе, все происходящие в игровом мире события должны быть поделены по важности и приоритетам.
Третье, экономия передаваемых данных путем определения важности изменения объектов для каждого игрока.
Стоит заметить, что данная модель может быть не актуально для пошаговых игр, где игровой процесс протекает не так стремительно как в многопользовательских экшен играх.
Написать данную статью меня вдохновила книга «Multiplayer Game Programming» Joshua Glazer, Sanjay Madhav, которая и стала источником для этой статьи.
Данная книга издана на русском языке, издательский дом «Питер«, «Многопользовательские игры. Разработка сетевых приложений«.