Как процедурная генерация помогает создавать открытые миры

Современные открытые миры в играх — это огромные пространства с реалистичными лесами и полями, городами и деревнями, тропинками и многополосными шоссе. Зачастую они выглядят настолько впечатляюще, что игроки всерьёз любуются виртуальными пространствами и делают десятки скриншотов. Фотографируя очередную поляну в рассветных лучах, игрок может и не догадываться, что она была сгенерирована автоматически.

Мы изучили доклады и презентации специалистов по генерации открытых миров, а также пообщались с программистом AAA-игр Александром Балакшиным, и теперь рассказываем, как работают эти алгоритмы, кому они могут пригодиться, и как их использовали в разработке The Witcher 3: Wild Hunt, Horizon Zero Dawn, The Sinking City и Spider-Man 2018-года.

Автор: Юрий Кулагин

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

А разработчики The Elder Scrolls II: Daggerfall в 1996 году использовали процедурную генерацию, чтобы собрать из заготовленных частей пять тысяч городов. Разработчики доказали, что автоматизировать создание локаций возможно, — правда результат может получиться довольно однообразным.

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

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

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

Художники не останутся без работы ещё и потому, что в открытых мирах отлично работает принцип Парето — игрок активно изучает только 20% локации, а оставшиеся 80% служат фоном. Так что логичным шагом будет отдать проработку и заполнение этого фона на откуп алгоритмам, и дать художникам больше времени на проработку того, на что игрок обратит внимание.

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

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

Для The Witcher 3 разработчикам из CD Projekt RED нужно было создать мир, который в 35 раз превышал бы размер локаций второго «Ведьмака». Людей с опытом работы над полностью открытым миром не хватало, а приступить к созданию локаций нужно было как можно скорее.

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

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

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

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

При этом в «Ведьмаке» процедурно сгенерированная трава не перекрывает детали исходной текстуры, а подчёркивает их. Для этого программу научили выделять на текстуре только те места, где что-то может расти. Например, если на вымощенной булыжником старой дороге местами проступает текстура земли, то трава вырастает только на этих участках.

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

Для создания деревьев и кустарников художники CDPR использовали другой инструмент — кисти с набором растительности. Их можно было настраивать под конкретную локацию, указывая насыщенность местности водой, освещённость и даже направление, в котором могут распространятся семена.

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

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

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

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

Работая над Horizon Zero Dawn, программисты Guerrilla Games тоже использовали процедурную генерацию. Художники студии привыкли контролировать каждую деталь на локации ещё во времена работы над серией Killzone. Поэтому и в новой игре они хотели иметь возможность поменять результат генерации — например, передвинуть гору, которую алгоритм поставил неправильно

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

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

Чтобы сгенерированные локации не просто работали, но и выглядели разнообразно, художникам студии потребовалось создать множество ассетов и шаблонов растительности, — но это всё равно оказалось быстрее и выгоднее, чем ручная проработка мира. Три человека в Guerrilla Games нарисовали 500 типов растений, а шаблонами занимался один технический художник.

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

Чтобы модели растительности не мешали друг другу, для каждой указывался footprint — отпечаток, задающий минимальное расстояние между объектами одного типа. А чтобы результат не выглядел искусственно, художники настраивали отдельный параметр, который хаотично разбрасывал цифры и менял логику размещения. Зачастую локацию потом отдавали художникам, чтобы те могли вручную её отредактировать.

В Horizon: Zero Dawn игрок исследует множество разных биомов, — от среднеевропейских лесов до заснеженной тундры. Сами разработчики называли их «экотопами»: с точки зрения инструмента генерации это были просто наборы настроек для создания локации.

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

Система работала и с геймплейными элементами. Например, при помощи отдельного инструмента художники могли размещать на локации специальный «стелс-кустарник», в котором игрок прятался от врагов. Его расстановка и логика тоже подчинялись общим правилам — в воде или на дороге кусты не генерировались.

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

Чтобы построить большой и реалистичный город в The Sinking City, студия Frogwares создала инструмент процедурной генерации для Unreal Engine 4. По словам Константина Якушенко, который возглавляет в компании команду tools-инженеров, разработчики вдохновлялись конструктором Ubisoft, с помощью которого создавали здания и улицы в Assassin's Creed Unity и Syndicate.

Процедурная генерация в города в The Sinking City начиналась с ручной работы. Художники создавали «сетку», — макет основных улиц и ориентиров — и указывали, какие типы домов могут находиться в том или ином районе. А ландшафт, рельеф и ширина улиц определялись лишь предварительно.

Только когда «сетка» была завершена, в дело вступала процедурная генерация. Инструмент расставлял вдоль улиц объекты архитектуры, собирая их из созданных художникам ассетов. Ассеты делились на категории: конкретные окна могли относиться только к богатому или, наоборот, бедному дому, а материал стен — к целому или разрушенному. Алгоритм брал за основу данные о улицах, которые задавали художники, и создавал постройки на их основе.

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

Когда все правки были внесены, редактор объединял детали здания в четыре фасада, которые сохранял по отдельности. Фрагментированное хранение зданий потом помогло разработчикам оптимизировать игру.

В Spider-Man большая часть 18 квадратных километров виртуального Манхэттена создана процедурной генерацией. В Insomniac Games стремились к тому, чтобы не менее 80% работы алгоритмов попало в финальную игру, и поэтому прорабатывали систему генерации особенно тщательно.

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

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

Со зданиями алгоритм работал поэтапно. Сначала из простых форм (кубов, цилиндров) генерация расставляла простые болванки вдоль улиц, опираясь на заданные художниками этажность и размеры. Затем, используя ассеты для нужного района или типа строения, система размещала на «коробках» внешний декор — вывески, окна и лестницы.

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

С автомобильным движением генерация работала по-другому — тут у алгоритма было больше свободы. Так как художники наносили на карту только самые узнаваемые проспекты и улицы реального Нью-Йорка, создание небольших переулков ложилось на плечи системы.

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

Генерация управляла не только прокладыванием новых улиц, но и количеством машин на них. Алгоритм учитывал возможные объезды, правила парковки, фазы светофора и многое другое, чтобы создать реалистичное автомобильное движение и атмосферно гудящие пробки.

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

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

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

Тесная связь разных систем генерации оказалось и одной из проблем разработки Spider-Man, — она создавала эффект домино. На ранних этапах создания мира у геймдизайнеров был готов лишь ограниченный набор механик, а акробатика была добавлена лишь частично. Сюжет игры тоже регулярно дополняли и переписывали, из-за чего менялись важные для истории локации.

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

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

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

Чтобы сделанная вручную часть окружения не страдала от подобных изменений, её «замораживали» — после того, как художники и дизайнеры вносили все необходимые правки, алгоритму запрещали доступ к конкретному участку. Причём вместе с, например, зданием, «замораживался» и ближайший к нему тротуар и улица, — чтобы последующие изменения не создали новых конфликтов.

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

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

Если небольшой команде всё же нужно сгенерировать большое пространство, тут можно использовать несколько уловок. Систему генерации можно запускать на так называемых «ночных билдах», когда офисные компьютеры всё равно простаивают. Десяти часов хватит на создание большой локации, и к утру версия мира будет готова для тестирования. Минус этого подхода в том, что новые версии можно будет создавать не чаще, чем раз в день.

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

Студиям необязательно разрабатывать собственные инструменты для процедурной генерации с нуля. Существуют уже готовые решения, которые пользуются спросом не только в игровой, но и в киноиндустрии. Например, разработчики из Guerilla Games сначала создали рельеф мира для Horizon Zero Dawn в процедурном генераторе World Machine, после чего импортировали результат в свой движок и уже там применяли разработанные инструменты.

Стандартом в индустрии считаются World Machine и World Creator. World Machine использует только за счёт процессора, не подключая ресурсы видеокарты. World Creator считается удачным выбором для новичков, так как предлагает дружелюбный интерфейс, но страдает от нехватки глубоких настроек.

В 2019 году вышел процедурный генератор QuadSpinner Gaea, который не уступает по мощности и проработке своим аналогам, а также предлагает умные алгоритмы и инструменты. Архитектура программы позволяет удобно работать с рельефом в реальном времени, а структура похожа на привычный для многих разработчиков Unreal Engine.

Начинающим разработчикам стоит обратить внимание и на отдельные инструменты для движков. И для Unreal Engine, и для Unity есть специальные генераторы и плагины, позволяющие создавать убедительную растительность, не выходя из привычной рабочей среды. А система Houdini сразу включает в себя и 3D-редактор, и програмную среду, и генераторы рельефа и растительности.

Promethean AI — это интеллектуальная палитра и процедурный генератор, совмещённые в одной программе. Её создаёт бывший технический арт-директор Sony Interactive и Naughty Dog Андрей Максимов, а его основная цель — исключить рутину из творческого процесса художников по окружению.

В основе Promethean AI лежит распознавание типа ассетов. Система понимает, какой объект в неё добавлен, в каком стиле он выполнен и для чего используется. После чего сравнивает собранную информацию с поставленной задачей и решает, подойдёт ли элемент локации или нет. Размещением объектов тоже занимается алгоритм — он, например, следит, чтобы настольная лампа стояла на столе, а одеяло лежало на кровати.

Художник может сам «обучать» эти алгоритмы. Для этого нужно расположить несколько объектов в сцене и задать общий стиль, — а остальное пространство достроит генерация. При этом навыков программирования не требуется — система специально создаётся так, чтобы её могли использовать разработчики любых специальностей.

Promethean AI ещё находится в разработке, но ходят слухи, что им уже начинают пользоваться некоторые крупные студии. Прежде чем программа официально выйдет, её создателям нужно ещё отточить интеллект алгоритмов и обучить систему на множестве объектов — чем больше примеров узнает Promethean AI на этапе разработки, тем лучше будут его результаты после релиза.

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

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

Материал подготовлен командой XYZ Media.

Наши каналы в Telegram и на YouTube.

#xyz #gamedev #programming #gamedesign #spiderman #unrealengine #gameworld #proceduralgeneration