Игровая разработка

Привет! Меня зовут Кирилл, я руководитель отдела серверной разработки в Pixonic. Здесь я работаю уже более 5 лет. Долгое время Pixonic была компанией одной игры War Robots. Но однажды к нам пришло осознание, что так больше продолжаться не может, и мы начали работу над созданием новых проектов.

Поначалу мы взялись за это дело по старинке, используя традиционные для нас подходы: писали клиент на Unity 3D, бэкенд разрабатывали на Java. Это было привычно, понятно, но имело ряд серьезных недостатков. Проекты разрабатывались медленнее, чем нам бы хотелось. Для выполнения любой задачи необходимо было задействовать как минимум двух разработчиков. Однако, когда в разработке участвуют два и более человека, неизбежно возникают ошибки в духе: то один не так понял другого, то второй работает быстрее, чем первый. Такие ситуации приводят к тому, что кому-то из разработчиков в дальнейшем приходится возвращаться к задаче, которую он, казалось, уже давно закончил, а ведь у него и других дел полно. Так мы начали думать над тем, как разрешить эту проблему.

Еще нас огорчало, что каждый раз так или иначе приходилось сталкиваться с инфраструктурными вопросами: разработка и поддержание API и схем баз данных, написание DTOшек, их преобразование из и в модели на клиенте и сервере. Эта рутина многим привычна, они ее даже не замечают, однако она отнимает время, которое можно было бы использовать с большей пользой. Эту проблему, казалось бы, можно решить клонированием предыдущего проекта но все оказывается сложнее, когда дело доходит до взаимодействия с геймдизайнерами. Они постоянно придумывают что-то новое, и даже если поначалу кажется, что у проектов много общего возьми да скопируй, то по факту оказывается, что это совсем не так. В итоге от клонированного проекта остается только набор библиотек и каркас la bootstrap.

После долгих размышлений наши желания оформились в следующие требования:

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

На момент начала разработки фреймворка на рынке уже было несколько предложений, частично удовлетворяющих нашим требованиям, PlayFab и GameSparks. Это отличные решения, построенные по модели LiveOps, но имеющие ряд критических для нас недостатков:

• Код пишется на JavaScript, что не дает возможности полноценного переиспользования в Unity 3D, и в любом случае приходится преобразовывать ответы сервиса в модели клиента. Получается, что разработчик должен знать два языка программирования и выполнять дополнительную работу, которой хотелось бы избежать.
• Наша цель разработка хита, а значит речь идет о миллионах игроков в день. Стоимость работы этих сервисов на наших объемах становится значительно больше, чем стоимость самостоятельного владения подобным решением.

Итак, у нас получился следующий набор необходимых технологий и методов:

• C# (.net core для сервера и клиента, .net 3.5, 4.X для клиента). Мы хотим, чтобы разработчик мог разрабатывать как клиентскую, так и серверную часть задачи. Уйти от Unity 3D мы не можем, а вот написать сервер на C# вполне.
• Orleans фреймворк для построения распределенных, отказоустойчивых и масштабируемых систем в модели акторов от Microsoft (использовался в Halo). Использование этого фреймворка обусловлено тем, что с нашими задачами рано или поздно придется масштабироваться к тому же, хочется, чтобы решение было отказоустойчивым.
• GRPC для общения сервисов между собой, так как в системе, кроме сервиса игроков, построенного на Orleans, существуют и другие: авторизация, загрузка каталогов и прочее в том числе и сервисы, которые ранее были написаны на Java и оказались по-настоящему автономны и независимы от того проекта, в котором используются.
• Postgres для хранения данных игроков. Для масштабирования базы данных мы используем шардирование.
• Docker с ним удобно разворачивать окружение локально и в тестовой среде. Таким образом, геймдизайнеры и разработчики могут работать с метой так, чтобы никому не мешать. Можно у себя ее локально поднять, проверить, что все работает, как нужно, и запушить уже измененный код в репозиторий.
• Prometheus для мониторинга.
• Event Sourcing парадигма, которую мы используем для хранения данных игроков. Она часто используется в банках. Подход здесь такой: когда мы работаем через Event Sourcing, все, что мы делаем, представлено в виде потока событий. Как упоминалось ранее, хотелось бы постоянно иметь историю, которая сохраняется в базе данных. Этот поток событий и есть наша история, по которой мы можем отслеживать, что происходило. Если что-то пошло не так, мы можем посмотреть интересующее нас событие в прошлом и полностью восстановить состояние игрока.

Кроме технической составляющей, есть еще логическая. Ни один проект, который мы делаем, не может существовать в вакууме: он должен постоянно конфигурироваться, настраиваться, и желательно, чтобы это проходило не в режиме, когда мы что-то уже сделали, скомпилировали и выпустили. Хотелось бы не обновлять клиент каждый раз, как мы выполняем перенастройку параметров бизнес-логики (цена предметов, скидки, запас здоровья у аватаров, урон от оружия и т.д.).

Обычно настройками параметров игры занимаются геймдизайнеры. Они уже давно работают в таблицах Excel или Google Sheets, поскольку в них удобно производить расчеты, задавать формулы, строить графики. Поэтому мы решили, что хорошей идеей будет эти же таблицы использовать не только для расчетов, но и для хранения параметров игры. Единственное, чего нам не хватало формализации правил хранения данных, чтобы парсер знал, откуда эти данные брать. В итоге мы сделали несколько вариантов шаблонов вкладок под наши нужды:

• вкладки конфигурирования игровых предметов;
• вкладки настройки экспериментов (A/B тестов);
• вкладки настройки лутбоксов;
• вкладки настройки игровых валют;
• вкладки для хранения простых настроек, заданных в виде ключ-значение.

Пример конфигурирования предмета

На примере выше показана вкладка, содержащая конфигурации предметов. Они имеют несколько стандартных колонок: ID, теги и цена. Эти значения обрабатываются особым образом. По ID и тегам, например, производится индексирование, так что по ним легко осуществлять поиск. Остальные колонки задаются свободно, и их может быть сколько угодно. Из кода такие данные получить очень просто:

// Находим в каталоге предмет с идентификатором 'Reaver_1':ItemBlueprint itemBlueprint = catalog.GetItemBlueprint(ItemBlueprint.ValueOf("Reaver_1")); // Получаем проверенное значение из колонки с названием 'grade'. // Если поле отсутствует или имеет неверный тип, далее этот результат будет передан // в админку, где будет выведена информация о месте нахождения ошибки:Validated<int> grade = itemBlueprint.ShouldHasIntAttr("grade");

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

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

1. Обладающие индивидуальностью и состоянием. Таким предметам можно задавать проектно специфичные параметры. Так, например, у брони может отслеживаться состояние ее износа.
2. Не обладающие индивидуальностью. Обычно это потребляемые предметы. В таком случае хранится только счетчик их количества. Пример таких предметов бутылки с целебным зельем.

• Лутбоксы. Сейчас без них немыслима ни одна free-to-play игра. Наше решение позволяет задавать различные варианты генерации контента для выдачи: от 100% гарантированного в этом случае лутбоксы можно использовать как обычные контейнеры, до полностью случайного.

Помимо этих базовых примитивов, на которых строится большая часть мета-геймплея в играх, фреймворк также предоставляет механизмы работы с A/B тестами, авторизацией, обработкой платежей сторов, выполнения отложенных задач, обезличивания данных и многие другие.

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

// Описываем команду, представляющую из себя обычную DTO,// которая может быть сериализована в Json:public class DemoCommand : ICommand{    public string BlueprintId;    public int Value;} // Описываем обработчик команды:public class DemoHandler : HandlerBase, ICommandHandler<DemoCommand>{    public void Handle(ICommandContext context, DemoCommand command)    {        // Inventory  объявлен в HandlerBase.        // Создаем новый предмет по образцу из каталога:        var demoItem = Inventory.GrantItem(ItemBlueprintId.ValueOf(command.BlueprintId));         // Задаем предмету значение атрибута 'demo_value':        demoItem.Attributes["demo_value"] = command.Value;     }}

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

Ниже приведен пример того, как происходит выполнение команды и обработка ее результата на клиенте:

// Выполняем команду на сервере:var command = new DemoCommand { BlueprintId = "Reaver_1", Value = 777 };var commandResult = connection.Execute(command); // Из ответа получаем обновленный инвентарь игрока:var inventory = commandResult.Player.Inventory; // Получаем последний созданный предмет:var demoItem = inventory.FindItemsByBlueprint(ItemBlueprintId.ValueOf("Reaver_1")).Last(); // Выводим установленное значение:Console.WriteLine(demoItem.Attributes["demo_value"]);

Так при чем здесь Event Sourcing?

Как видно из предыдущего примера, мы пишем код в классическом императивном стиле. Здесь нет работы с базой данных. Метод обработки команды не возвращает никаких результатов. Так как же это работает?

Никакой магии тут нет. На вызове метода инвентаря GarntItem и при операции присвоения фреймворк генерирует события, сохраняемые в контексте выполнения. После совершения операции эти события заносятся в базу данных. Они же уходят на клиент, где применяются к текущему состоянию игрока.

Ниже приведена упрощенная диаграмма того, что происходит при взаимодействии клиента и сервера:



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

Ниже приведен пример отображения транзакций игрока из реального проекта. Здесь мы видим две прошедших транзакции. Одна из них создание нового игрока, вторая принятие пользовательского соглашения с определенной версией.


Пример лога транзакций из реального проекта

В настоящее время фреймворк используется в трех проектах студии. Один из них уже около полугода находится в продакшене. В разработке этого проекта команда серверных разработчиков принимала непосредственное участие, чтобы понять, насколько удобно пользоваться нашим решением. Почему? Потому что мета была еще достаточно молодой. И на проекте мы приводили ее в порядок: упрощали API, что-то выкидывали за ненадобностью, где-то, напротив, добавляли разнообразия в наиболее часто повторяющихся паттернах.

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

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

Вчера состоялся релиз сиквела The Last of Us игры, уже семь лет являющейся одним из наиболее узнаваемых эксклюзивов PlayStation. Это кинематографическая история о человеческих жизнях в бесчеловечной реальности мира, разрушенного современной чумой. В то время, когда игроки берут на себя управление циничным и озлобленным главным героем Джоэлом, искусственный интеллект разыгрывает других персонажей, будь то союзник, враг или зараженный.

На фоне выхода второй части игры рассказываем о том, почему игрокам так понравился оригинал. В этой переводной статье поговорим о философии дизайна The Last of Us, касающейся всех аспектов искусственного интеллекта.



Предупреждение: речь в статье идет только об оригинальной игре 2013 года.

Об игре

The Last of Us игра от третьего лица в жанре action-adventure с фокусом на механиках стелса и динамической системе укрытий. В мире постапокалиптической Америки игроки вынуждены противостоять двум типам противников: охотникам людям, контролирующим и патрулирующим отдельные территории по всей стране, и зараженным существам, в которых превращаются люди, заболевшие грибковой чумой.

Когда мы только начинали создавать прототипы ИИ в случае, когда врагом является человек, первый вопрос, которым мы задались, был следующий: как заставить игрока поверить в реальность своих противников, чтобы ему не хотелось их убивать? Ответ на этот вопрос и стал основой дизайна вражеского ИИ. Для ответа на него потребовалось нечто большее, чем просто нанять лучших актеров озвучки, лучших 3D-художников и аниматоров, хотя все это тоже было немаловажным. Прежде всего нам требовалось решить проблему самого искусственного интеллекта. Потому что, если мы не сможем заставить игрока поверить, будто эти отряды выживших мыслят и взаимодействуют, как настоящие люди, никакие передовые мокапы не удержат игрока в потоке.

Трэвис Макинтош, Вражеский ИИ в The Last of Us, Game AI Pro, том 2, глава 34, 2015

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

И не стоит забывать про Элли девочку-подростка, которую Джоэлу предстоит провести через всю страну, чтобы та попала к группировке революцинеров, называющих себя Цикадами. Элли во многих отношениях является аватаром игрока в этой истории. В отличие от Джоэла, который слишком осведомлен об ужасах внешнего мира, Элли понятия не имеет, что ждет ее за стенами карантинной зоны Бостона. Она непрестанно задает вопросы о прежней реальности, которую она никогда не знала, и бурно реагирует на ужасы, которые им с ее попутчиком приходится переживать. Было очень важно, чтобы игроки развивали отношения с ней почти так же, как это делал Джоэл.

Архитектура ИИ

Начнем с объяснения основ архитектуры искусственного интеллекта различных персонажей в игре и того, почему Naughty Dog построили ее именно таким образом.

ИИ в The Last of Us строится на использовании конечных автоматов (КА) давно устоявшегося подхода к созданию искусственного интеллекта. Популяризовала его Half-Life еще в 1998 году. Его суть состоит в том, что персонаж может иметь несколько сменяющих друг друга состояний: к примеру, он будет атаковать цель либо искать ее местоположение до тех пор, пока не произойдет событие-триггер, которое переведет его из одного состояния в другое.


Простой КА с двумя состояниями

ИИ в The Last of Us построен на идее поведений и навыков. Навыки это то, что персонаж может сделать. Например, охотник может начать выяснять, что за шорохи он слышит или что за движение видит, спрятаться за укрытием или обойти игрока. В случае зараженных этот список будет иной: например, в него будут входить хаотическое блуждание по карте и преследование противника. В любом из вариантов используются более мелкие специфические действия, такие как перемещение по локациям, взаимодействие с объектами в мире или реагирование на них. Здесь и вступает в силу поведение.

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

Каждый навык, представляющий собой состояние внутри конечного автомата, и сам, в свою очередь, является конечным автоматом, состоящим из поведений. Такой иерархический КА хорошо отработанный метод управления поведением ИИ. Но самое важное здесь то, что навыки и поведения сами по себе тоже являются модульными.



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

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

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

Марк Ботта, ИИ зараженных в The Last of Us, Game AI Pro, том 2, глава 33, 2015

Но даже наличие хорошего набора уже доступных инструментов не означает, что не возникнет нужды в дальнейших экспериментах. Для того, чтобы достичь своего замысла, Naughty Dog радикально поменяли и пересмотрели множество элементов дружественного и вражеского ИИ. Некоторые вражеские архетипы и даже система поведения Элли приняли свой финальный вид только в последние пять месяцев до релиза игры.

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

Охотники

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

В первую очередь поговорим о том, как охотники и другие человеческие ИИ могут обнаружить игрока.

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

Прежде всего стоит поговорить о зрении. NPC используют различные поля обзора для обнаружения игрока в пространстве.

Изначально в The Last of Us они были такими же, как в другой серии игр Naughty Dog Uncharted. Но со своей функцией они справлялись плохо: игрока слишком быстро замечали как на близком, так и на дальнем расстоянии. Они не соответствовали темпу игры, а потому были видоизменены и имели уже не конусообразную форму. Теперь поле зрения NPC стало напоминать контур замочной скважины, тем самым обеспечивая более широкое периферическое зрение и более узкий обзор на расстоянии.


Поле зрения NPC в Uncharted


Поле зрения NPC в The Last of Us

Вдобавок к этому, игрока нельзя обнаружить мгновенно: ему нужно оставаться на виду у противника хотя бы пару секунд, чтобы быть замеченным. Быстрее это происходит в режиме боя, когда враг уже начеку и имеет повышенную концентрацию на поиске противника. Кроме того, любой NPC, в поле зрения которого находится игрок, выполняет дополнительный тест и запускает рейкаст луч из камеры от своей точки до позиции Джоэла для того, чтобы понять, блокирует ли что-то его видимость. Изначально таким образом проверялся каждый сустав в модели Джоэла, но этот вариант оказался не слишком рабочим. В результате остановились на проверке двух условий: попадает ли рейкаст в его грудь либо верхнюю часть головы. Это реализовать оказалось довольно просто, но в то же время эффективно.

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



У охотников есть множество навыков. Как мы видим, большинство из них строится вокруг боя: ближнего, дальнего, при прямом наступлении или подходе с фланга. Большинство последовательностей боевых действий в The Last of Us начинается с того, что игрок, пребывавший в невидимом режиме, оказывается обнаружен. Поэтому сейчас мы сосредоточимся на двух навыках, наиболее критических в режиме стелса: на расследовании и поиске.

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

• Боевая система координирования, определяющая роль и соответствующее поведение для каждого персонажа;
• Карта навигации, показывающая самый быстрый способ перемещения в пространстве в непосредственной близости от персонажа;
• Карта экспозиции, показывающая, что NPC может увидеть с текущей позиции;
• И, наконец, система очков укрытий, которая определяет не только хорошие укрытия для боя, но и точки старта определенных анимаций и режимов поведения.

Давайте рассмотрим, как эти системы запускают в работу режимы поиска и расследования.

Когда Охотнику нужно запустить режим расследования, отправляется запрос координатору боя на роль следователя. Система ограничивает количество персонажей в этой роли, поэтому не случится такого, что бросок кирпича пойдут проверять все пять услышавших его противников. Пока один персонаж проверяет внешний раздражитель, другие могут просто стоять или действовать в обычном режиме. Затем NPC в режиме расследования обращается к системе укрытий для проверки так называемого открытого поста места возле точки интереса, соответствующего определенным критериям. В данном случае это подходящее место для запуска анимаций расследования.

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

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

Карта навигации позволяет быстро и недорого рассчитать, существует ли путь к нужной локации в непосредственной близости от NPC, а карта экспозиции показывает, что он при этом будет видеть. Используя эти данные, система создает карту поиска, которая показывает области карты экспозиции, которые не видны с данной точки, их но можно будет увидеть с другой в пешей доступности от нее. Так NPC вычисляет, какие области нужно проверить из тех, что он не видит в данный момент. На данном этапе система координирования отправляет NPC для поиска игрока в обозначенных местах, будь то территория за углом или за укрытием. Следовательно, если игрок останется на том месте, где и был, охотники его выследят.


Часть территории не видно, но ее можно проверить

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

Прежде всего, врагам может понадобиться укрытие. Как они узнают, где лучше спрятаться? В данном случае снова используется система очков укрытий, но уже с другими критериями. Нам уже не нужны открытые посты, теперь нам нужна защита для юнита. Игра выполняет подсчет 20 ближайших точек для укрытия на карте в пределах радиуса NPC, а затем запускает 4 рейкаста на каждый фрагмент укрытия, чтобы оценить, сможет ли игрок убить врага в перестрелке с этой позиции. Если система решает, что место безопасно, оно оценивается по степени удобства достижения и тому, не нужно ли ИИ при этом перемещаться перед игроком. Укрытия ранжируются по этим критериям, после чего персонаж выбирает пост, набравший наибольшее количество очков. При этом стоит учитывать, что наиболее предпочтительная позиция в данный момент может потерять свою актуальность уже спустя 5 секунд, стоит лишь игроку переместиться в другую точку, и тогда последующие расчеты других наилучших мест могут повлиять на темп битвы.


Выбор наилучшего укрытия с учетом позиции игрока

Теперь, когда подходящее укрытие выбрано, как охотникам лучше скоординировать свою атаку?

Перво-наперво в этот момент игра создает ссылку на местоположение игрока. Генерируется пакет данных с его координатами и соответствующей временной меткой. Ее полезно знать для того, чтобы засечь, сколько времени прошло с тех пор, когда игрока было видно в последний раз. Если Джоэла заметит другой NPC, будет сгенерирован новый пакет данных. Всякий раз, когда это происходит, сгенерированные данные совместно используются и другими NPC, находящимися поблизости. Охотники будут продвигаться к локации игрока: одни используя укрытия, чтобы застать его врасплох, другие напролом. Роли между NPC распределяет боевой координатор. Среди них: фланкер, передовой, сопутствующий стрелок, выжидающий наводчик.

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

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

Зараженные

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

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

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

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

Давайте посмотрим на то, как работает звук в игре.

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


Радиус распространения звука

Эти логические звуковые события генерируются для подавляющего большинства внутриигровых событий, в особенности для движения и боя либо для работы таких предметов, как генераторы или транспорт. Тем не менее, еще существуют такие невидимые события, которые генерируют звуки, но игрок их не слышит. Например, к ним относится звук дыхания Джоэла. Мы его не слышим, но он помогает NPC найти игрока, если тот прячется где-то поблизости.

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



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

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



Учитывая, что противостояние зараженным во многом основано на скрытности, как щелкун и бегун будут искать игрока, если услышат что-то подозрительное?

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

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

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

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

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

Элли

Теперь, когда мы изучили философию искусственного интеллекта противника, осталась еще одна неохваченная тема: ИИ союзника и, в частности, Элли.

Одна из первых демонстраций игры в январе 2013 года показывала то, как игроки покидают карантинную зону Бостона. Тэсс и Элли под предводительством Джоэла пробирались сквозь небоскреб, переполненный бегунами и щелкунами. В этом демо персонажи-компаньоны должны были держаться поодаль от места чистки от зараженных, но в то время их ИИ был еще сырым и не соответствовал задуманному Naughty Dog.

Итак, давайте поговорим о приоритетах ИИ в случае с Элли:

• Убедиться, что она никогда не отстает от Джоэла, и найти точки в пространстве, позволяющие этого придерживаться;
• Давать ей шанс оказаться полезной, будь то указание на близость врага или нападение на него;
• Сделать Элли интересным персонажем со специальными анимациями и аудиодиалогами;
• И напоследок обеспечить достоверность ее опыта, предотвращая читерство с ее стороны, но в разумных пределах.

Наиболее важно было правильно прописать, где должна находиться Элли. Если она будет стоять слишком близко, то помешает свободе передвижения игрока. Если слишком далеко это будет мешать необходимости ее защищать и развитию взаимоотношений между персонажами. Таким образом, вне боя Элли обычно идет в ногу с Джоэлом или позади него, в то время как в стелс-режиме старается оставаться рядом с ним в одном и том же укрытии.

Чтобы Элли могла следовать за Джоэлом, игра создает область вокруг игрока, которой также стараются придерживаться Тэсс, Билл, Генри и Сэм хотя обычно они держатся на большем расстоянии от Джоэла, нежели Элли. Как только эта область выстроена, игра отправляет рейкасты параллельно навигационной сетке в целью поиска подходящих позиций для размещения компаньонов. Как и в случае системы очков укрытий, каждая позиция оценивается по таким параметрам, как расстояние до врагов и союзников, угол относительно позиции игрока, не блокирует ли геометрия взгляд на Джоэла или движение вперед. Решить эту проблему правильно невероятно трудно и все же, пусть система неидеальна, гораздо чаще ей удается разместить персонажа правильно, чем не удается.


Определение допустимых позиций для Элли на основе положения Джоэла в случае, когда они прячутся за укрытием

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

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

Система работала хорошо, пока не выяснилось, что в данном случае Элли будет всегда находиться рядом с Джоэлом. Тогда была добавлена модификация, которая позволила создавать пакеты действий в той точке укрытия, где стоит игрок. В сочетании с новой анимацией это позволяет Джоэлу защитить тело Элли от угроз, пока он находится в укрытии, и тем самым помогает укрепить отношения между персонажами.


Режим следования в укрытии


Режим защиты в укрытии

По мере прохождения игры персонажи все чаще оказываются в ситуациях, когда они оба участвуют в бою. При этом Элли постепенно приобретает все большую свободу действий и большее разнообразие оружия, чтобы защитить и себя, и Джоэла. Одной из первых ее способностей становится умение бросать во врагов кирпичи и бутылки. На самом деле, эта способность является немного читерством, поскольку в момент действия Элли подключается к системам восприятия врага, чтобы проверить, собирается ли он обнаружить Джоэла. Если ответ положительный, она производит бросок. Обратите внимание, что для этого ей не нужно брать бутылку или кирпич.

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

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

И остается еще один немаловажный приоритет.

ИИ Элли читерит в пользу игрока в очень специфических ситуациях, но как часто случается в играх делает это для того, чтобы свести к минимуму разочарование игрока и улучшить общее впечатление от прохождения игры. Так, Элли телепортируется к Джоэлу, если его удерживает противник, чтобы помочь тому избавиться от угрозы. В бою точность стрельбы девочки будет варьироваться в зависимости от того, находится ли ее противник в поле зрения игрока или вне его. За экраном Элли не причинит противнику никакого вреда, но часто поворачивается для того, чтобы выстрелить в кого-то, кого Джоэл может видеть. Отчасти это сделано для поддержки игрока, но также и для того, чтобы показать, что она не просто привязанный к игроку NPC, но действительно вовлечена в конфликт.

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

Заключение

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