Goldeneye 007 — одна из самых важных игр в истории. Она определила дальнейшее развитие целого поколения консольных игр и проложила шутерам от первого лица дорогу на рынок консолей. Перенесёмся более чем на 20 лет назад, чтобы узнать, как одной из самых популярных на Nintendo 64 игр удалось реализовать ИИ врагов и друзей, у которого можно чему-то научиться даже сегодня.
Об игре
После своего выпуска в 1997 году GoldenEye 007 не только определил судьбу поколения, но и превзошёл все ожидания. В эту игру мало верила сама Rare, Nintendo и даже владелица прав на франшизу Бонда — компания MGM. Выпущенная спустя два года после выхода фильма и спустя год после появления консоли на рынке, она казалась обречённой на провал, но стала третьей по продажам (восемь миллионов копий) за весь срок жизни платформы, уступив только Super Mario 64 и Mario Kart 64. Не говоря уже о том, что в 1998 году она заработала компании Rare награду BAFTA и звание разработчика года.
Эта игра оставила нам огромное наследие: она задала стандарты того, что нужно ожидать от следующих поколений шутеров от первого лица, особенно в поведении ИИ: персонажи с паттернами патрулирования, враги, запрашивающие подкрепление, убегающие в страхе мирные жители, плавная навигация и поиск пути, богатый набор анимаций, динамические свойства, возникающие в процессе игры, и многое другое. Она не только задала стандарты поколения, но и повлияла на игры, которые её превзошли — Half Life, Crysis, Far Cry и многие другие.
Меня интересует не просто то, как работал искусственный интеллект, но и как, чёрт побери, разработчикам удалось заставить его работать. Я рассказывал о многих техниках создания ИИ, в том числе о конечных автоматах, навигационных мешах, деревьях поведений, технологиях планирования и машинном обучении, но на момент выпуска GoldenEye они ещё не были устоявшимися практиками в индустрии игр. Кроме того, Nintendo 64 исполнилось уже почти 25 лет, и по сравнению с современными машинами она имеет минимальные ресурсы процессора и памяти. Как можно создать ИИ и геймплейные системы, которые будут эффективно работать на «железе» с такими серьёзными ограничениями?
Чтобы выяснить правду, я связался с самым лучшим тайным осведомителем: доктором Дэвидом Доуком. Дэвид играл важную роль в команде разработки и GoldenEye 007 и её духовного последователя Perfect Dark. Во время интервью мы обсудили интеллект NPC, поведения при тревоге, системы датчиков, инструменты навигации, балансировку производительности и многое другое. Так что давайте начнём разбираться, как всё это было устроено.
Построение архитектуры
В основном GoldenEye стал тем, чем он стал, благодаря двум людям: продюсеру и директору игры Мартину Холлису и программисту геймплея и движка Марку Эдмондсу. Изначально Холлис вдохновлялся играми наподобие Virtua Cop, где враги вбегали в кадр камеры, стреляли по игроку, а затем убегали, прятались, или динамически реагировали на попадания игрока. Однако Холлис стремился к созданию более увлекательного и реактивного ИИ, превосходящего стандарт, заданный в 1993 году DOOM.
«Нам было важно показать игроку ИИ. Нет никакого смысла в сложном искусственном интеллекте, если игрок его не замечает. Ваш NPC может вдохновенно рассуждать о смысле жизни, но игрок этого не заметит, если в игре ему будет достаточно высунуться из-за угла и накормить врагов свинцом. То есть интеллект должен быть очевиден. ИИ должна демонстрировать игровая механика. ИИ должна показывать структура уровней. И всё это действительно должно вносить что-то новое в сам геймплей»
[Мартин Холлис, European Developers Forum, 2004 год.]
Такой подход привёл к появлению охранников и патрулей, заставляющих игрока более тактически относиться к прохождению. Были задействованы датчики зрения и слуха, позволявшие ИИ реагировать на поведение игрока или не замечать его, если он прокрадывался скрытно. Кроме того, дружественные и гражданские персонажи реагировали на присутствие игрока, помогая ему или убегая.
Когда в проект пришёл Дэвид Доук, большая часть базовых компонентов движка для 3D-движения, рендеринга и простых поведений ИИ уже была создана Эдмондсом. Однако на протяжении последних двух лет развития проекта появилась основная часть поведений ИИ и другие базовые системы геймплея. Игра стала менее сосредоточенной на игроке, у ИИ появились паттерны патрулирования, переход в состояние тревоги, возможность использования терминалов управления, туалетов и многое другое.
Чтобы добиться этого, Марк Эдмондс создал внутри написанной на C кодовой базы целую систему скриптов, которая постоянно дополнялась и обновлялась, пока Доук и другие члены команды экспериментировали с идеями. Довольно часто новая идея предлагалась Эдмондсу, который оценивал возможность её реализации и в течении суток добавлял её в движок. Эта скриптовая система позволяла разработчикам связывать множество заранее созданных действий в последовательности интеллектуального поведения, зависящих от очень конкретного контекста. Эти поведения вызывали собственные потоки для выполнения и как можно быстрее освобождали ресурсы, как только начинало выполняться следующее «атомарное» поведение, а затем проверяли, можно ли снова выполнить обновление. Такие скриптовые поведения использовались не только для дружественных и вражеских персонажей, но и для систем наподобие открывающихся по времени дверей и ворот, а также кинематографических заставок в начале и конце каждого уровня, управлявших игроком и другими персонажами в мире.
В редакторе GoldenEye Editor, изначально разработанном моддером Митчеллом «SubDrag» Клейманом, был выполнен реверс-инжиниринг этих поведений ИИ. Они превратились в редактируемые «блоки действий», из которых можно создавать собственные поведения. Вражеские охранники могут реагировать на широкий диапазон сенсорных сигналов: на попадание в них выстрела, на то, что они заметили врага, на убитого в поле их зрения другого охранника, а также на услышанные поблизости выстрелы. Кроме того, NPC могли решить сдаться, это зависело от вероятности, но гораздо больше от того, целится ли в них игрок. Причём если ИИ знал, что игрок больше в него не целится, его поведение менялось. Как будет объяснено ниже, проверки зрения и слуха, необходимые для таких поведений, выполнялись в очень ограниченных и урезанных процессах, тем не менее, создавая на слабом «железе» N64 впечатляющие результаты.
В зависимости от условий охранники могли выполнять множество различных поведений, в том числе шаги вбок, перекатывание в стороны, огонь в приседе, на ходу, на бегу, и даже броски гранат. Эти действия сильно зависели от относительного расположения игрока и их текущего поведения.
По сути это был достаточно простой конечный автомат (Finite State Machine), в котором ИИ находился в определённом состоянии выполнения поведения, пока внутриигровые события не заставляли его перейти к следующему. Тот же самый принцип позже был использован в Half-Life, который вышел через год после GoldenEye (в 1998 году), и разработчики из Rare знали о том, какое влияние их игра оказала на получивший огромную популярность шутер Valve:
«Больше всего мне запомнилась встреча с ребятами из Valve на британской отраслевой выставке ECTS в 1998 году. Они шутили, что GoldenEye заставил их переделать в Half-Life кучу всего. Они решили сделать всё правильно».
Дэвид Доук, GamesRadar, 2018 год.
Выполнение ИИ
Двумя самыми важными элементами движка Goldeneye для управления ИИ были камера и нечто под названием «система STAN». Для упрощения рендеринга уровни, даже такие большие и открытые, как Severnaya surface, разбивались на «комнаты» — блоки меньшего размера. Это помогало сохранять нужный уровень производительности, ведь рендерить можно было только комнаты в пирамиде видимости камеры. Но из-за этого ИИ обычно не выполнял свои основные поведения, пока персонажи не были отрендерены камерой. Это помогало снижать вычислительные затраты, и в то же время обеспечивало интересные возможности, о которых я скажу ниже.
Но самой важной системой, связанной с комнатами и поведением рендеринга, были STAN (что является простым сокращением от Stand). Объекты STAN, разработанные Мартином Холлисом — это полигональные меши для отдельной комнаты, помеченные для использования в качестве STAN. Все эти объекты «знали», в какой комнате или коридоре они расположены. Если персонаж ИИ стоял поверх определённого STAN, то он мог видеть игрока, только если STAN, в котором тот находится, расположен в текущей или соседней комнате. Система выполняла простую проверку того, могут ли два STAN «видеть» друг друга. Это позволяло проводить менее затратные тесты видимости вместо трёхмерной трассировки лучей, которые бы требовали от оборудования гораздо больше ресурсов. Система работала на удивление хорошо, но в некоторых конкретных случаях «ломалась». Примером этого могут служить охранники на дамбе, которые не могли видеть игрока, пока он не приблизится к их пути движения: STAN на вершине лестницы могли видеть только STAN у её низа, то есть игрок мог выполнять поблизости любые действия и оставаться незамеченным. В качестве второго примера можно привести спиральный путь в пещерах, где NPC видят путь перед собой, но не с другой стороны пропасти.
Разместив по всем картам STAN, можно было построить на основе их полигонов систему навигации. Как я рассказывал ранее в AI 101, в современных играх обычно используются навигационные меши, создающие полную полигональную поверхность, определяющую места, в которые может перемещаться персонаж на карте. В своём современном виде навигационные меши появились только в 1997 году, поэтому для GoldenEye разработчики взяли систему STAN и добавили поверх неё объекты под названием PAD. PAD располагались на STAN, но в то же время были связаны друг с другом, по сути создавая граф навигации по мешу. Персонажи знали, в какой комнате они находятся, и могли выполнять поиск PAD комнаты назначения, если они реагировали на переполох поблизости, или двигались по STAN в пределах текущей комнаты к интересующей их точке.
Всё это дополнялось датчиками слуха. Они выполняли простую проверку близости персонажей в пределах определённого радиуса от источника звука. Также в них учитывался тип оружия и темп его стрельбы. PP7 с глушителем не привлекал внимания, стандартный PP7 был громким, KF7 Soviet — ещё громче, а стрельба очередями приводила к увеличению радиуса до максимального уровня, громче которого считались только ракетница и танковая пушка.
Адаптивные изменения
Все эти инструменты и системы ИИ сильно впечатляют, они показывают, как разработчики намеренно искали умные и эффективные способы создания конкретных элементов, которые они хотели видеть в игре. Но существует и множество других элементов, при помощи которых GoldenEye создавал отдельные поведения ИИ, изготавливаемые почти индивидуально для каждого уровня. NPC не прятались за препятствиями, поэтому на таких уровнях, как Silo и Train были необходимы уникальные скрипты, чтобы персонажи стояли рядом с определёнными PAD и реагировали в зависимости от того, находятся ли они в приседе, или стоят в полный рост.
NPC не знали, где находятся другие персонажи на карте, поэтому на уровнях, где игроку нужно защищать Наталью Симонову, нужно было не только обеспечить ещё перемещение, но и создать специальные поведения, чтобы враги стреляли не только по ней, но и целились в игрока. Для реализации таких персонажей, как учёные, замирающие на месте при наведении на них оружия, или Бориса Гришенко, который действовал так, как ему приказывал игрок, пока тот не упускал его из прицела, требовались другие поведения, работающие в более специфическом контексте. Многим основным сюжетным персонажам приходилось писать собственные поведения ИИ для каждого уровня. Например, Алек Тревельян имеет различные поведения на каждом из шести уровней с его участием: Facility, Statue, Train, Control, Caverns и Cradle.
Кроме того, необходимо было решить проблемы с дизайном уровней и темпом игры. Уровни Severnaya exterior оказались трудными в плане балансировки расположения ИИ-персонажей, поэтому разработчики написали скрипты уровней, создающие врагов за пределами радиуса тумана и бегущих прямо к игроку. Но если враги оказывались слишком далеко, то просто отключались и могли повторно активироваться в дальнейшем.
Моя любимая особенность GoldenEye заключается в том, как было реализовано наказание игрока за громкое и агрессивное обращение с оружием, если он не проходил уровень достаточно быстро. Помните, я говорил, что NPC не активируют своё ИИ-поведение, если пока ещё не были отрендерены? В случае, если NPC услышал звук, но пока ещё не был отрендерен, он создаёт собственного клона, чтобы тот пошёл проверить источник звука, и продолжал создавать клонов, или пока не уляжется волнение, или камера не отрендерит персонажа. Это особенно заметно на уровнях наподобие Archives, где игрок может запросто попасть в ловушку в комнате для допросов в начале уровня из-за постоянно создаваемых клонов.
Чтобы улучшить темп игрового процесса в целом, а также адаптировать управление под недостаточную точность контроллера Nintendo 64, переходы и длительность анимаций были благодаря тестированию тщательно настроены, давая игрокам больше шансов определить приоритеты врагов или при помощи механик автоматического или точного прицеливания.
В заключение
После выхода GoldenEye его тулчейн рендеринга и ИИ послужил хорошую службу последовавшим за ним играм. В духовном наследнике Perfect Dark компании Rare использовались те же системы, частично дополненные нововведениями. Как сказано выше, NPC в GoldenEye могут прятаться за укрытия только при помощи специально прописанного поведения, но в Perfect Dark враги уже способны вычислять позиции для укрытий, в том числе и динамические, создаваемые антигравитационными предметами. Кроме того, благодаря экспериментам с освещением, вычисляемым затенением вершин, датчики зрения могли иметь пониженное видение. Тот же самый процесс позже использовала Free Radical Design для своей франшизы Timesplitters, ведь эта студия была основана несколькими членами команды разработчиков GoldenEye. В этой серии игр система STAN/PAD была дополнена для лучшей поддержки вертикальной архитектуры уровней.
Несмотря на своё двадцатилетие, GoldenEye установил стандарты, которые были использованы в Half-Life а сегодня их стремятся воспроизвести и создатели многих других франшиз шутеров. Надеюсь, что после прочтения этой статьи вы по достоинству оценили всю глубину использованных в игре систем и тот уровень приверженности и мастерства, который потребовался для создания проекта, в конечном итоге оказавшего столь большое влияние.
Автор: PatientZero
