Это вторая статья путеводителя по разработке многопользовательских игр, где я пытаюсь последовательно и в одном месте собрать знания, которые потребуются для осознанной разработки мультиплеерного проекта.
В прошлой статье я поделился своими наблюдениями и взглядами на направление мультиплеерной разработки. Время начинать постепенное погружение вглубь темы. В этой статье я хочу обсудить, что отличает синглплеер от мультиплеера, и где эти отличия находятся.
- -> Синглплеер и Мультиплеер
• Что считать мультиплеером
• Отличия от синглплеера
• Классификации мультиплеера
• Локальный и сетевой мультиплеер
• Дополнительный контент - ...
Следить за выходом новых статей и другого контента можно в моём блоге на 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, когда для каждого игрока выделен свой кусочек экрана.
При таком режиме отличий от синглплеера в техническом плане практически нет. Есть несколько источников ввода: они или обрабатываются одновременно, или поочерёдно. Аналогично есть несколько режимов вывода. Грубо говоря, локальный мультиплеер вносит лишь незначительные корректировки в слой представления приложения.
Наибольший интерес и сложность представляет сетевой мультиплеер. Здесь каждый игрок использует своё отдельное устройство, и игроки объединяются в одну игру за счёт использования сетевого соединения. Чаще всего это Интернет. Для того, чтобы все игроки играли в одну и ту же игру, необходимо обеспечивать одинаковое игровое состояние на всех устройствах в каждый момент времени.
Если в локальном варианте существовало единое общее игровое состояние, и нужно было перекладывать информацию в пределах одной и той же быстрой оперативной памяти, то в сетевой реализации каждое устройство имеет свою копию игрового состояния, и приходится для синхронизации постоянно обмениваться данными между устройствами, которые находятся на огромном расстоянии друг от друга.
Такие условия априори вносят больше хрупкости и значительно бóльшие временные задержки в процесс обновления данных. Ситуация усложняется ещё и тем, что все игроки находятся в разных условиях: у кого-то соединение быстрее, у кого-то слабее. С такими вводными сложно обеспечивать одинаковое игровое состояние на всех устройствах и координировать действия игроков между собой.
Для решения подобных проблем требуется применение определённых подходов при проектировании игрового приложения. Перенос практик из синглплеерной разработки будет иметь успех в редких случаях: пожалуй только в проектах с очень медленным или вовсе асинхронным геймплеем. Чем быстрее геймплей, тем больше «наворотов» и усложнений требуется вносить в программный код для учитывания и компенсации возникающих задержек.
Именно сетевой мультиплеер и будем рассматривать дальше и детальнее разбираться с тем, что приходится учитывать и делать для его реализации.
В следующих статьях конкретнее разберём проблему синхронизации данных, способы реализации взаимодействия, варианты организации проекта и обсудим, с каких проектов проще начинать мультиплеерную разработку.
——————————————————
Контент
——————————————————
#unity #gamedev #development #multiplayer #singleplayer #games #статья #геймдев #разработка #мультиплеер #синглплеер #игры #aks2dio