Автор: Andrew Doull
Перевод: Вивденко В.С.
Источник:
Ascii Dreams: The Death of the Level Designer: Procedural Content Generation in Games - Part One
Это первая часть цикла статей, посвященных процедурной генерации контента в играх. Продолжение вы можете найти в источнике
Процедурная генерация контента готовится перевернуть игровую индустрию. Это событие ожидалось после выхода одной из величайших игр всех времен – Diablo, и приближалось ее потомками, которые уходят своими корнями к играм жанра roguelike, таких как Angband. Но недавняя реализация генерации случайных уровней в Hellgate: London заставила усомниться в том, что этот метод хорошо подходит для создания игровых уровней. Однако он остался томиться в тени игровой индустрии, и лишь иногда дает о себе знать в таких играх как Spore. Это технология, которая, как и большинство технологий, не окажет значимого влияния в краткосрочной перспективе, но в долгосрочной – приведет к серьезным изменениям в процессе дизайна игр.
Объявление в конце прошлого года должно было взбудоражить всех, кто имеет отношение к игровой индустрии. Нет, речь не о слиянии Activision с Vivendi. Gearbox Software поначалу весьма скептически отнеслась к применению процедурной генерации контента в Borderlands, но в итоге осталась довольна. Благодаря этому теперь я вспоминаю еще одного человека с фразой «Пушки. Нам нужно много крутых пушек», предшествовавшей похожему, но более строгому высказыванию Нео, семь лет назад (фильм «Доля секунды»). Но что важнее, это означает, что когда-нибудь наступит момент, когда текущая роль дизайнера уровней будет столь же устаревшей, как перфокарты для написания компьютерных игр.
В этой статье будет рассмотрен текущий положение процедурной генерации контента, чтобы выделить, где ПГК становится на место традиционных дизайнеров уровней, и как различные дополнительные технологии облегчают создание и развертывание процедурного контента в других игровых технологиях. В обзоре будет выделено несколько тенденций, не обязательно положительных, на которые я рассчитываю, при которых генерация контента будет происходить в процессе игры, и сделано несколько выводов-предположений о том, чего ждать в ближайшие пять лет, и предложено несколько вариантов для тех, кто заинтересован в дальнейшей реализации идей, здесь изложенных.
Процедурная генерация контента (ПГК) - это программная генерация игрового контента с использованием случайного или псевдослучайного процесса, который приводит к непредсказуемому диапазону возможных игровых моментов. Я предпочитаю термин процедурной генерации контента больше, чем просто процедурная генерация: по определению в Википедии, процедурная генерация включает в себя использование динамических, а не предварительно просчитанных карт освещения, и процедурно сгенерированные текстуры, которые, будучи действительно процедурными, на самом деле не оказывают значимого влияния на игровой процесс. Идея случайности также является ключевой: ПГК должна гарантировать, что из нескольких параметров может быть сгенерировано большое количество возможных типов контента.
Это базовый пример генерации процедурного контента, о котором большинство из вас подумали, начав читать эту статью. Классическим примером является случайное размещение соединенных коридорами комнат в Rogue, что делало игру бесконечно реиграбельной и смягчало наказание за смерть. Хочется думать, что динамическая генерация случайных уровней в 2D все еще является интересной областью исследований: я много об этом писал, но все еще существуют необнаруженные алгоритмы и методы. Проблема, однако, почти что решена тем, что существует огромный выбор интересных алгоритмов, от генераторов лабиринтов до комнатных расстановщиков и обширная литература, посвященная способам их реализации.
С другой стороны, процедурная генерация контента в 3-х измерениях все еще остается малоисследованной областью. Hellgate: London - пример того, как не надо делать трехмерное пространство – цена создания достаточно интересных трехмерных объектов и текстур гарантирует, что в полученных случайных уровнях будет много повторений. Многие двухмерные концепции можно спроецировать на 3-е измерение: генерация лабиринтов в большинстве случаев расширяется в зависимости от выбранного вами алгоритма. А последние версии Dwarf Fortress показывают, что вполне реально воплотить классический roguelike дизайн в трех измерениях.
Чего сейчас не хватает, так это какой-либо серьезной попытки создать полностью трехмерные пространства, включая мосты, арки, башни и другие сильно взаимосвязанные топологии. Это во многом связано с одним из ключевых ограничений генерации динамического уровня, который заключается в обеспечении полной связи между всеми частями карты. Даже на двумерной карте это может быть сложной проблемой. В 3d любая игра, в которой есть гравитация, должна обеспечивать, что юниты, попавшие на низкие уровни, имели возможность попасть на высокие уровни, если только они не разделены намеренно, как часть игрового процесса. Кроме того, ограничения на крутизну склона, минимальный размер блока и т. д. Могут значительно усложнить связность уровня.
Tribal Trouble обходит стороной эти проблемы, генерируя достаточное количество карт и проверяя их связность, а затем используя статистическую проверку, чтобы убедиться, что достаточно большой процент карт будет пригоден для игры. Другие генераторы случайных уровней могут использовать метод проверки, который отбрасывает и перезапускает любые карты, которые могут оказаться непригодными для прохождения. Необходимо тщательно тестировать случаи вырождения, чтобы избежать бесконечных циклов или достаточно длительных задержек в генерации уровней, что даже с двумерными картами может быть значительным осложнением, часто из-за вычислительных затрат генерации случайных чисел. Карты Dwarf Fortress, даже до введения 3-го измерения, могли просчитываться на современном процессоре в течение 15 или более минут.
Несмотря на то, что проблемы генерации случайных карт могут казаться неразрешимыми, их все еще можно применять. Часто случается так, что наполнение уровня, в частности возвышенности, генерируются во время разработки, а не в процессе игры. Затем разработчик уровня берется за проверку правильности уровня или за его доработку, чтобы убедиться в его пригодности. Процедурная генерация становится способом минимизации затрат на создание контента.
Darwinia от Introversion Software - отличный пример использования процедурно сгенерированных уровней, дополненных ручным редактированием. Уровни Darwinia были изначально построены с использованием процедурного генератора, поскольку было бы невозможно разместить все вершины карты вручную. Introversion использует ту же технику для своей следующей игры Subversion: Chris Delay. Она выпускает частые обновления для разработчиков в своем блоге, которые стоит почитать. Их генератор городов выглядит достаточно мощным, чтобы использоваться в качестве динамического генератора случайных уровней на данном этапе, но, не имея законченной игры в этом нельзя быть уверенным.
На более низком уровне уже есть хорошо принятые методы для заполнения деталей уровня с использованием «процедурной генерации» и процедурной генерации контента. Главный среди них SpeedTree, промежуточный продукт, позволяющий дизайнерам уровней не беспокоиться о размещении каждого внутриигрового дерева и кустарника. SpeedTree используется в Oblivion, что очень неплохо для программы, которая изначально разрабатывалась для улучшения полей для гольфа.
Подобные методы можно использовать для автоматизации размещения текстур и надписей, поэтому разработчикам уровней не нужно беспокоиться о выравнивании текстур, и вместо этого они могут сосредоточиться на элементах дизайна более высокого уровня. Это в дополнение к процедурным текстурам, которые снова являются примером «процедурной генерации», которая может использовать случайный шум для уменьшения видимых артефактов.
Идея заключается в использовании числа-зерна (42 – популярный кандидат), которое остается постоянным. Игровое поле постепенно увеличивается, используя зерно как аргумент в генерации псевдослучайных чисел. Обычно рост происходит из нисходящего подразделения, которое хорошо подходит для методов генерации фракталов, а также для соответствия типичным реализациям уровня детализации (LOD). Карта никогда не хранится в памяти, кроме как отдельные временные сегменты для текущего отображения, и удаляется, как только ее компоненты больше не требуются: ничего сгенерированного процедурно никогда не записывается обратно на диск.
У этого есть существенные недостатки. В частности, некоторые сооружения, как правило, длинные, такие как дороги и реки, очень трудно или вообще невозможно реализовать таким образом из-за техники деления (дороги просто сложно, реки же почти невозможно из-за необходимости знать высоту прилегающей территории для расчета пути). И в настоящее время этот процесс сильно загружает ЦП, с повышением уровня детализации, обычно зависящим от алгоритма с высокой сложностью.
Такого рода карты хорошо подходят для путешествий и исследований: по сути, вы движетесь через множество возможных мест. Разработчик игры так же увлечен алгоритмом генерации процедурного контента, как и игроки. Он может манипулировать алгоритмом, чтобы попытаться сгенерировать различные типы пространств - но весь мир зависит от алгоритма, и поэтому он может в равной степени уничтожить что-то еще, что было создано. На самом деле одна игра на DOS сделала это исследование центральным элементом игры: ее особенности открывались игроками и получали от них имена, которые потом становились часть последующих версий игры.