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

1. Введение

2. -> Синглплеер и Мультиплеер

3. ...

Что считать мультиплеером

Для начала нужно определить, что далее будет пониматься под словом "мультиплеер". Зафиксируем:

Мультиплеер — взаимодействие между собой множества игроков, которые непосредственно воздействуют друг на друга.

Т.е. какой-нибудь абстрактный лидерборд не будем считать мультиплеером, т.к. игроки друг с другом не взаимодействуют и не оказывают друг на друга прямого влияния. Они всего лишь меряются своими результатами, полученными обособленно друг от друга.
Аналогично кланы, чаты, друзья и прочие социальные механики не будут попадать под приведённое определение мультиплеера.
Клиент-серверное взаимодействие, всяческий LiveOps и облачные механики тоже не делают игру мультиплеерной — это используют и многие сервисные игры, которые могут быть полностью синглплеерными.

Где отличия от синглплеера

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

• CoreGame: основной игровой процесс, главные игровые механики, которые формируют целевой игровой опыт и определяют жанр.
  Примеры: механика управления автомобилем, логика гоночного процесса, работа ИИ противников, система разрушаемости и пр.

• MetaGame: более широкий контекст, который вносит новые возможности и механики, не направленные напрямую на достижение основной цели игры в рамках CoreGame. Обычно они направлены на увеличение степени вовлечения игрока, разнообразие взаимодействия и мотивацию продолжать играть и возвращаться в игру.
  Примеры: тюнинг авто, прокачка, дополнительные задания, внутриигровая экономика, мини-игры, социальные механики и пр.

• Infrastructure: технические "обвесы" и подключаемые модули.
  Примеры: звуковой движок, физика, работа с удалёнными узлами для социального взаимодействия и хранения данных, системы мониторинга и аналитики и пр.

• Runtime: общая архитектура проекта, "клей" для всех блоков.

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

Ключевое отличие мультиплеерного проекта от синглплеерного, как правило, кроется в области CoreGame.
Здесь чаще всего игроки и получают возможность для непосредственного воздействия друг на друга. Многие мультиплеерные игры, когда не могут найти достаточное кол-во игроков для новой игровой сессии, превращаются в этом месте в синглплеерные: игрок в одиночестве или в сопровождении ботов болтается в основном игровом цикле.
Здесь проявляются знаковые отличия в реализация для обеспечения многопользовательского режима. Если потребуется синглплеерный проект превратить в мультиплеерный (и наоборот), то править придётся преимущественно CoreGame.

Другие блоки тоже могут быть задеты. Например, в MetaGame могут потребоваться лобби, поиск игроков или выбор сервера. А в Infrastructure может появиться больше сервисов, систем и удалённых вычислительных узлов, которые будут требовать координации. Но об этом позже.

Классификации мультиплеера

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

По взаимодействию:

1. Соревновательные / PvP / Players versus Players: игроки соревнуются друг с другом, командами или поодиночке.

2. Кооперативные / PvE / Players versus Environment: игроки объединяют усилия для борьбы с врагами, управляемыми компьютером.

По балансу:

1. Симметричные: все участники имеют примерно равные возможности и цели.

2. Асимметричные: предлагаются разные возможности и цели для разных сторон.

По времени жизни мира:

1. Массовые многопользовательские онлайн-игры / MMO / Massively Multiplayer Online Games: тысячи игроков взаимодействуют одновременно в одном постоянно существующем виртуальном мире.

2. Сессионные: небольшое число игроков взаимодействуют в одном матче или сессии, которые каждый раз начинаются заново.

По процессу:

1. Синхронные / Realtime: все игроки единовременно вовлечены в единый игровой процесс и взаимодействуют друг с другом в одном и том же виртуальном мире.

2. Асинхронные: игроки взаимодействуют друг с другом не в реальном времени, а по очереди.

По технической реализации:

1. Локальные.

2. Сетевые.

Локальный и сетевой мультиплеер

Суть локального мультиплеера в том, что игроки играют на одном и том же устройстве, локально.
В асинхронных играх используется режим hotseat, когда игра передаёт всё управление конкретному игроку в его ход.
В синхронных играх всем игрокам сразу отдаётся управление, и игроки наблюдают за своим геймплеем на общем экране или через Splitscreen, когда для каждого игрока выделен свой кусочек экрана.

При таком режиме отличий от синглплеера в техническом плане практически нет. Есть несколько источников ввода: они или обрабатываются одновременно, или поочерёдно. Аналогично есть несколько режимов вывода. Грубо говоря, локальный мультиплеер вносит лишь незначительные корректировки в слой представления приложения.

Наибольший интерес и сложность представляет сетевой мультиплеер. Здесь каждый игрок использует своё отдельное устройство, и игроки объединяются в одну игру за счёт использования сетевого соединения. Чаще всего это Интернет. Для того, чтобы все игроки играли в одну и ту же игру, необходимо обеспечивать одинаковое игровое состояние на всех устройствах в каждый момент времени.

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

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

Для решения подобных проблем требуется применение определённых подходов при проектировании игрового приложения. Перенос практик из синглплеерной разработки будет иметь успех в редких случаях: пожалуй только в проектах с очень медленным или вовсе асинхронным геймплеем. Чем быстрее геймплей, тем больше "наворотов" и усложнений требуется вносить в программный код для учитывания и компенсации возникающих задержек.

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

Статьи также доступны на площадках: VK, Dzen, Dtf.

Контент

• Полгода разработки мобильного PvP: Habr

• Multiplayer resource roundup: Unity

• Unity Multiplayer in 3 minutes: YouTube

• Как устроен мультиплеер: YouTube.Cyberstars