Чтобы вкратце ответить на ваш главный вопрос, основные преимущества процедурного игрового мира заключаются в следующем:
Мир может быть огромным , гораздо большим, чем любой игровой мир, созданный вручную.
Мир (или, по крайней мере, его части) можно регенерировать для каждой игры, потенциально увеличивая ценность повторов, поскольку у игрока всегда будет что-то новое для открытия.
И наоборот, основными недостатками процедурной генерации являются:
В зависимости от используемых методов генерации может быть трудно убедиться, что мир всегда можно воспроизвести, то есть игрок не может застрять без возможности продолжить только потому, что ему не повезло с поколением мира.
Даже если вы можете избежать создания совершенно неиграбельных миров, генерация случайных миров может привести к очень изменчивому уровню сложности: иногда игрок может найти все, что ему нужно, просто удобно выстроившись для взятия, иногда он может идти долго, не находя ничего полезного ,
В течение длительных периодов такие случайные колебания имеют тенденцию к усреднению, но если сложность игры, например, сильно загружена вперед (типично для игр на выживание), плохой старт может испортить игру, а очень удачный старт может лишить ее всех проблем.
Плохо выполненная процедурная генерация может сделать мир монотонным и скучным: после того, как вы увидели дюжину случайно сгенерированных лабиринтов, все они начинают выглядеть одинаково, даже если они различаются в деталях.
Кроме того, если игровой мир полностью регенерируется для каждой игры, не будет фиксированных местоположений или функций, которые игрок мог бы узнать из предыдущих игр. Такое отсутствие знакомства может затруднить игроку участие в игре на эмоциональном уровне или обмен опытом с другими игроками.
Есть также одна вещь, которую вы могли бы посчитать в любом списке: в игре, где мир случайным образом восстанавливается для каждой игры, не может быть такого понятия, как «пошаговое руководство», поскольку каждое прохождение игры будет отличаться.
(Эта неповторимость также может быть проблемой для тестирования и отладки, хотя ее можно по крайней мере частично избежать, если разрешить указание начального числа RNG, по крайней мере, в режиме отладки, и / или путем предоставления команды "cheat", которую можно использовать для перемотка вперед на разные этапы.)
Однако, если вы посмотрите на список недостатков, вы увидите, что он в основном описывает недостатки чисто процедурной генерации; многих из них можно избежать, смешивая вручную и процедурно сгенерированный контент .
Например, игрок всегда может начать игру в фиксированном, спроектированном вручную городе, возможно, в окружении более широкого или менее фиксированного домашнего региона, но места, расположенные подальше от города, могут генерироваться случайным образом, чтобы игрок всегда мог исследовать незнакомые регионы.
Также могут быть другие города или другие локации, созданные вручную (более или менее) случайным образом в мире, так что игроку придется их найти, но он будет знать, чего ожидать, когда попадет туда. И наоборот, выдающиеся объекты, такие как горы, могут быть размещены вручную (по крайней мере, вблизи фиксированного начального местоположения), но детали их местности могут быть рандомизированы.
Что касается случайного размещения, вызывающего взаимные блокировки и изменение сложности, то это можно устранить путем реализации различных проверок согласованности и баланса поверх вашего процедурного алгоритма генерации мира. Например, если игроку нужен какой-то конкретный предмет, чтобы иметь возможность пересечь воду, вы могли бы включить некоторый код, обеспечивающий размещение хотя бы одного такого предмета, чтобы игрок мог добраться до него, не пересекая воду.
Точно так же вы можете также настроить свои правила размещения предметов так, чтобы жезлы с нарушением баланса не помещались до того, как игрок достигнет уровня x , и, возможно, чтобы убедиться, что хотя бы один находится в фиксированном месте, где игрок может достичь это прежде, чем добраться до стадии, на которой им это понадобится, чтобы выжить.
Кстати, общий способ сделать процедурную и вручную сгенерированную сетку контента более или менее плавным - это запустить процесс генерации вручную, используя генератор процедурного мира (может быть соответствующим образом настроен, например, чтобы создать деревню или горную вершину там, где вы этого хотите). ), чтобы инициализировать проектируемый регион, а затем вручную настроить его, чтобы добавить и настроить нужные детали. (Это также может позволить очень компактное хранение уровня, сохраняя только ручные изменения и начальное число генератора и используемые параметры.)
Другие способы объединения ручного и процедурного контента включают в себя оставление пустых мест на ваших уровнях, созданных вручную, для заполнения случайным контентом (например, замок может включать в себя случайно сгенерированный лабиринт в подземельях с фиксированными только очертаниями и выходами), или Ручной дизайн может указывать только общую схему некоторых частей уровня (например, размещение домов в городе) и оставлять детали (например, точный внешний вид каждого дома) случайным образом.
На самом деле, даже во многих играх, в которых полностью зафиксирован игровой мир, используется некоторая форма процедурной генерации как часть процесса проектирования уровней, поскольку существуют некоторые аспекты генерации мира (например, создание естественного ландшафта или размещение отдельных деревьев в лесу). которые трудно и / или утомительно делать вручную, но относительно легко автоматизировать.
И наоборот, большинство процедурных мировых генераторов будут использовать по крайней мере некоторые созданные вручную объекты и элементы для построения мира. Можно даже легко иметь несколько уровней вложенной случайной / ручной генерации: например, мир, созданный процедурным способом, может включать в себя созданный вручную город, окруженный процедурно созданными лесами с нарисованным вручную контуром, с процедурно сгенерированными деревьями, имеющими листья, спроектированные вручную.
Также обратите внимание, что процедурная генерация контента не обязательно несовместима с фиксированным миром: вы можете просто выбрать фиксированное начальное число ГСЧ и использовать его для генерации своего мира. Это может быть полезно, если вы хотите, чтобы игроки могли исследовать огромный мир, но хотите, чтобы он был одинаковым для каждой игры и каждого игрока.
Обратите внимание, что если вы сделаете это (или, возможно, даже если вы этого не сделаете), вам действительно следует спроектировать генератор мира, чтобы он работал иерархически, используя несколько экземпляров RNG, например, чтобы общий генератор карт содержал один экземпляр RNG. что он будет использовать для генерации субрегионов, назначая каждому субрегиону различное начальное значение, которое генератор области затем будет использовать для инициации отдельного экземпляра ГСЧ, который он будет использовать для генерации региона, и так далее. Это сделано для того, чтобы избежать «эффекта бабочки», когда изменение даже мельчайших деталей самой малой части карты может привести к потере синхронизации ГСЧ и к тому, что все остальное в мире будет совершенно другим.
Еще один важный способ избежать эффекта бабочки, особенно если вы генерируете мир «на лету» во время его изучения игроком, - полностью избегать обычных ГСЧ (за исключением процессов, которые происходят «мгновенно» с точки зрения игрока, например, генерация). новый уровень, когда игрок входит в него) и вместо этого использовать методы генерации случайных чисел, которые не хранят никакого внутреннего состояния. Например, при выборе начального числа для субрегиона, в который собирается войти игрок, генератор общего мира может взять координаты субрегиона (и его собственное общее начальное число) и передать их в хеш-функцию для генерации начального числа субрегиона. Таким образом, каждый регион всегда будет выглядеть одинаково, независимо от того, в каком порядке игрок вводит их.
Ps. После всего этого отступления позвольте мне кратко остановиться на вашем последнем вопросе о реальном коде, используемом для процедурной генерации. Увы, я не думаю, что это действительно ответственно в каком-либо значимом смысле без гораздо большего количества деталей, чем вы предоставили, поскольку существует буквально столько же разных способов сделать процедурное генерирование мира, сколько есть игр, использующих их.
Например, прадедушка всех процедурно-сгенерированных игр- разведчиков , вероятно, является Роугом , чей алгоритм генерации уровней просто состоял из случайного размещения группы прямоугольных комнат на большем прямоугольном уровне и соединения этих комнат с проходами (и размещения лестницы для следующий уровень в одном из них). Его разнообразные преемники , от Nethack до серии Diablo , разработали эту систему многими способами, но большинство из них сохранили основную идею об отдельных уровнях, состоящих из комнат, темниц и лабиринтов, более или менее случайно расположенных на карте сетки.
И наоборот, для игр с открытыми наружными настройками вы, вероятно, захотите начать с какого-то фрактального алгоритма генерации рельефа и строить другие функции (реки, леса, города и т. Д.) Поверх этого. Или вы можете сделать что-то наподобие того, что делает Minecraft , и сгенерировать случайную трехмерную процедурную текстуру, определяющую, какие части вашего ландшафта являются земными и воздушными соответственно (масштабированными и смещенными так, чтобы более низкие блоки были с большей вероятностью заземлены), а затем наложить такие элементы, как вода , почва / скала, растительность и т. д. сверху.
Конечно, ни один из вышеперечисленных не применяется , если вы, скажем, писать игру космической разведки , в этом случае вам просто нужно создать набор случайно расположенных звездных систем в соответствии с некоторой функцией плотности, а затем генерировать случайные множество звезд и планет в каждой из них. Или, может быть, вы предлагаете своим игрокам исследовать неевклидовый ландшафт , и в этом случае вы столкнетесь с совершенно иным набором проблем (например, тот факт, что объем в пределах данного радиуса растет в геометрической прогрессии, а не полиномиально, что делает его очень сложно держать большую карту в памяти).
