Это вторая статья путеводителя по разработке мультиплеерных игр. В прошлой статье я поделился своими наблюдениями и взглядами на направление мультиплеерной разработки. Время начинать постепенное погружение вглубь темы. В этой статье я хочу обсудить, что отличает синглплеер от мультиплеера, и где эти отличия находятся.
→ Синглплеер и Мультиплеер
...
Следить за выходом новых статей и другого контента можно в моём блоге на VK / Telegram / Dtf.
Что считать мультиплеером
Для начала нужно определить, что далее будет пониматься под словом «мультиплеер». Зафиксируем:
Мультиплеер — взаимодействие между собой множества игроков, которые непосредственно воздействуют друг на друга.
т. е. какой‑нибудь абстрактный лидерборд не будем считать мультиплеером, т.к. игроки друг с другом не взаимодействуют и не оказывают друг на друга прямого влияния. Они всего лишь меряются своими результатами, полученными обособленно друг от друга.
Аналогично кланы, чаты, друзья и прочие социальные механики не будут попадать под приведённое определение мультиплеера.
Клиент‑серверное взаимодействие, всяческий LiveOps и облачные механики тоже не делают игру мультиплеерной — это используют и многие сервисные игры, которые могут быть полностью синглплеерными.
Где отличия от синглплеера
Разница между мультиплеерным и синглплеерным проектами, если говорить про кодовую базу, не носит глобального характера. Чтобы понять, на что обращать внимание для определения типа проекта, следует обозначить какие‑то составные части.
Среднестатистический игровой проект, в т. ч. и мультиплеерный, с технической точки зрения можно представить в виде комбинации следующих крупных блоков:
CoreGame: основной игровой процесс, главные игровые механики, которые формируют целевой игровой опыт и определяют жанр.
Примеры: механика управления автомобилем, логика гоночного процесса, работа ИИ противников, система разрушаемости и пр.MetaGame: более широкий контекст, который вносит новые возможности и механики, не направленные напрямую на достижение основной цели игры в рамках CoreGame. Обычно они направлены на увеличение степени вовлечения игрока, разнообразие взаимодействия и мотивацию продолжать играть и возвращаться в игру.
Примеры: тюнинг авто, прокачка, дополнительные задания, внутриигровая экономика, мини‑игры, социальные механики и пр.Infrastructure: технические «обвесы» и подключаемые модули.
Примеры: звуковой движок, физика, работа с удалёнными узлами для социального взаимодействия и хранения данных, системы мониторинга и аналитики и пр.Runtime: общая архитектура проекта, «клей» для всех блоков.
Внутри эти блоки могут делиться на другие более мелкие произвольные части, меняющиеся от проекта к проекту.
Ключевое отличие мультиплеерного проекта от синглплеерного, как правило, кроется в области CoreGame.
Здесь чаще всего игроки и получают возможность для непосредственного воздействия друг на друга. Многие мультиплеерные игры, когда не могут найти достаточное кол-во игроков для новой игровой сессии, превращаются в этом месте в синглплеерные: игрок в одиночестве или в сопровождении ботов болтается в основном игровом цикле.
Здесь проявляются знаковые отличия в реализация для обеспечения многопользовательского режима. Если потребуется синглплеерный проект превратить в мультиплеерный (и наоборот), то править придётся преимущественно CoreGame.
Другие блоки тоже могут быть задеты. Например, в MetaGame могут потребоваться лобби, поиск игроков или выбор сервера. А в Infrastructure может появиться больше сервисов, систем и удалённых вычислительных узлов, которые будут требовать координации. Но об этом позже.
Классификации мультиплеера
Для дальнейшего раскрытия отличительных особенностей мультиплеера и для общей насмотренности предлагаю рассмотреть наиболее часто встречающиеся классификации мультиплеерных проектов.
По взаимодействию:
Соревновательные / PvP / Players versus Players: игроки соревнуются друг с другом, командами или поодиночке.
Кооперативные / PvE / Players versus Environment: игроки объединяют усилия для борьбы с врагами, управляемыми компьютером.
По балансу:
Симметричные: все участники имеют примерно равные возможности и цели.
Асимметричные: предлагаются разные возможности и цели для разных сторон.
По времени жизни мира:
Массовые многопользовательские онлайн-игры / MMO / Massively Multiplayer Online Games: тысячи игроков взаимодействуют одновременно в одном постоянно существующем виртуальном мире.
Сессионные: небольшое число игроков взаимодействуют в одном матче или сессии, которые каждый раз начинаются заново.
По процессу:
Синхронные / Realtime: все игроки единовременно вовлечены в единый игровой процесс и взаимодействуют друг с другом в одном и том же виртуальном мире.
Асинхронные: игроки взаимодействуют друг с другом не в реальном времени, а по очереди.
По технической реализации:
Локальные.
Сетевые.
Локальный и сетевой мультиплеер
Суть локального мультиплеера в том, что игроки играют на одном и том же устройстве, локально.
В асинхронных играх используется режим hotseat, когда игра передаёт всё управление конкретному игроку в его ход.
В синхронных играх всем игрокам сразу отдаётся управление, и игроки наблюдают за своим геймплеем на общем экране или через Splitscreen, когда для каждого игрока выделен свой кусочек экрана.
При таком режиме отличий от синглплеера в техническом плане практически нет. Есть несколько источников ввода: они или обрабатываются одновременно, или поочерёдно. Аналогично есть несколько режимов вывода. Грубо говоря, локальный мультиплеер вносит лишь незначительные корректировки в слой представления приложения.
Наибольший интерес и сложность представляет сетевой мультиплеер. Здесь каждый игрок использует своё отдельное устройство, и игроки объединяются в одну игру за счёт использования сетевого соединения. Чаще всего это Интернет. Для того, чтобы все игроки играли в одну и ту же игру, необходимо обеспечивать одинаковое игровое состояние на всех устройствах в каждый момент времени.
Если в локальном варианте существовало единое общее игровое состояние, и нужно было перекладывать информацию в пределах одной и той же быстрой оперативной памяти, то в сетевой реализации каждое устройство имеет свою копию игрового состояния, и приходится для синхронизации постоянно обмениваться данными между устройствами, которые находятся на огромном расстоянии друг от друга.
Такие условия априори вносят больше хрупкости и значительно бóльшие временные задержки в процесс обновления данных. Ситуация усложняется ещё и тем, что все игроки находятся в разных условиях: у кого-то соединение быстрее, у кого-то слабее. С такими вводными сложно обеспечивать одинаковое игровое состояние на всех устройствах и координировать действия игроков между собой.
Для решения подобных проблем требуется применение определённых подходов при проектировании игрового приложения. Перенос практик из синглплеерной разработки будет иметь успех в редких случаях: пожалуй только в проектах с очень медленным или вовсе асинхронным геймплеем. Чем быстрее геймплей, тем больше «наворотов» и усложнений требуется вносить в программный код для учитывания и компенсации возникающих задержек.
Именно сетевой мультиплеер и будем рассматривать дальше и детальнее разбираться с тем, что приходится учитывать и делать для его реализации. В следующих статьях конкретнее разберём проблему синхронизации данных, способы реализации взаимодействия, варианты организации проекта и обсудим, с каких проектов проще начинать мультиплеерную разработку.
Контент
Полгода разработки мобильного PvP: Habr
Multiplayer resource roundup: Unity
Unity Multiplayer in 3 minutes: YouTube
Как устроен мультиплеер: YouTube.Cyberstars
