Автостопом по мультиплееру. Часть 2: Синглплеер и Мультиплеер

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

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

Следить за выходом новых статей и другого контента можно в моём блоге на VK / Telegram / Dtf.

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

Т.е. какой-нибудь абстрактный лидерборд не будем считать мультиплеером, т.к. игроки друг с другом не взаимодействуют и не оказывают друг на друга прямого влияния. Они всего лишь меряются своими результатами, полученными обособленно друг от друга.

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

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

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

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

Ключевое отличие мультиплеерного проекта от синглплеерного, как правило, кроется в области 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, когда для каждого игрока выделен свой кусочек экрана.

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

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

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

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

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

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

————————————————————————

#unity #gamedev #development #multiplayer #singleplayer #games #статья #геймдев #разработка #мультиплеер #синглплеер #игры #aks2dio