Щоб коротко відповісти на ваше головне запитання, головними перевагами процесуально створеного ігрового світу є:
Світ може бути величезним , набагато більшим, ніж будь-який світ, створений вручну.
Світ (або принаймні його частини) можна відновити для кожної гри, потенційно збільшуючи значення відтворення, оскільки гравцеві завжди буде щось нове для відкриття.
І навпаки, основними недоліками процесуального породження є:
Залежно від використовуваних методів генерації, може бути важко переконатися, що світ завжди відтворюється, тобто гравець не може застрягти, не маючи можливості продовжуватись лише тому, що їм не пощастило світове покоління.
Навіть якщо ви можете уникнути генерування абсолютно неспроможних світів, генерування випадкових світ може призвести до дуже різного рівня складності: іноді гравець може знайти все необхідне, просто зручно вишикувавшись для зйомки, іноді вони можуть тривати довгий час, не знаходячи нічого корисного .
Протягом тривалих періодів такі випадкові коливання мають тенденцію до середнього, але якщо ігрові труднощі є, наприклад, сильно завантаженими з фронтом (типовими для ігор на виживання), поганий старт може зіпсувати гру, в той час як дуже вдалий старт може позбавити її всіх проблем.
Погано виконане процедурне покоління може змусити світ почуватись монотонним та нудним: після того, як ви побачили десяток випадково генерованих лабіринтів, усі вони починають виглядати однаково, навіть якщо вони відрізняються деталями.
Крім того, якщо ігровий світ буде повністю відновлений для кожної гри, не буде фіксованих місць чи функцій, які гравця могли б розпізнати з попередніх ігор. Така відсутність знайомства може ускладнити гравця на емоційному рівні або поділитися досвідом з іншими гравцями.
Є також одне, що ви можете порахувати в будь-якому списку: у грі, де світ відтворюється випадковим чином для кожної гри, не може бути такого поняття, як «покрокове керівництво», оскільки кожне проходження буде різним.
(Ця неповторюваність також може бути проблемою для тестування та налагодження, хоча цього можна принаймні частково уникнути, дозволяючи задавати насіння RNG, принаймні в режимі налагодження, та / або надаючи команду "cheat", яку можна використовувати для швидка перемотка вперед на різні етапи.)
Однак, якщо ви подивитесь на список недоліків, ви побачите, що він переважно описує недоліки чистого процесуального покоління; багато з них можна уникнути, змішуючи вміст, створений вручну та вручну .
Наприклад, гравець завжди може стартувати у нерухомому, ручному дизайні містечку, можливо, оточеному більш широким більш-менш нерухомим домашнім регіоном, але місця, віддалені від міста, можуть бути випадковим чином створені, щоб завжди надавати незнайомі регіони гравцеві для вивчення.
Також можуть бути інші міста, розроблені вручну, або інші місця, розміщені (більш-менш) випадковим чином у світі, так що гравцеві доведеться їх знайти, але буде знати, що чекати, як тільки він туди потрапить. І навпаки, визначні риси, такі як гори, можна розмістити вручну (принаймні, в районі фіксованого початкового місця), але деталі їх рельєфу можуть бути випадковими.
Що стосується випадкового розміщення, що спричиняє тупикові місця та зміни труднощів, то це можна вирішити, застосовуючи різні перевірки узгодженості та балансу над вашим алгоритмом процесуального світового покоління. Наприклад, якщо гравцеві потрібен певний предмет, щоб він міг перетинати воду, ви можете включити якийсь код, переконавшись, що принаймні один такий предмет розміщений так, що гравцеві можна дістатись до нього, не перетинаючи воду.
Аналогічно, ви також можете налаштувати правила розміщення своїх предметів, щоб жодних паличок незбалансованої дивовижності не було розміщено до того, як гравець досяг рівня x , і, можливо, для того, щоб принаймні один розмістився у фіксованому місці, куди гравця може дістатися перед тим, як дійти до того етапу, де їм знадобиться, щоб вижити.
До речі, поширений спосіб зробити процедурну та створену вручну мережеву мережу більш-менш просто - це запустити процес генерації вручну за допомогою генератора процесуального світу (можливо, відповідним чином налаштовано, наприклад, щоб створити село чи гірську вершину там, де ви цього хочете. ) ініціалізувати створений вами регіон, а потім налаштувати його вручну, щоб додати та відкоригувати потрібні деталі. (Це також може забезпечити дуже компактний рівень зберігання, зберігаючи лише вручну зміни та використовувані генератори та параметри.)
Інші способи поєднання вмісту вручну та процедур включають залишення порожніх плям на розроблених вручну рівнях, які заповнюються рандомізованим вмістом (наприклад, замок може включати в підземеллях випадково створений лабіринт із фіксованими лише контурами та виходами) або в ручному дизайні можна було вказати лише широкий контур деяких частин рівня (наприклад, розміщення будинків у містечку) і залишити деталі (наприклад, точний вигляд кожного будинку) вибирати випадковим чином.
Насправді, навіть багато ігор, які мають цілком фіксований ігровий світ, використовують певну форму процесуального покоління як частину свого дизайнерського процесу, оскільки є деякі аспекти світового покоління (наприклад, створення природного вигляду місцевості або розміщення окремих дерев у лісі) які важко та / або виснажливо зробити вручну, але відносно легко автоматизувати.
І навпаки, більшість процедурних світових генераторів використовуватимуть принаймні деякі об'єкти та елементи, створені вручну, для побудови світу. Можна навіть легко мати декілька рівнів вкладених випадкових / ручних поколінь: наприклад, процедурно генерований світ міг би включати місто, що генерується вручну, оточене деревцями, створеними вручну, з накресленими вручну контурами, з деревцями, створеними вручну, процедурно створеними.
Також зауважте, що процедурне генерування вмісту не обов'язково несумісне з фіксованим світом: ви можете просто вибрати фіксований насіння RNG і використовувати його для створення вашого світу. Це може бути корисно, якщо ви хочете, щоб величезний світ гравців досліджував, але ви хочете, щоб він був однаковим для кожної гри та кожного гравця.
Зауважте, що якщо ви це зробите (або, можливо, навіть якщо цього не зробите), ви дійсно повинні створити свій світовий генератор, щоб він працював ієрархічно, використовуючи кілька екземплярів RNG, таким чином, наприклад, що загальний генератор карт зберігав би один екземпляр RNG що він буде використовуватись для генерації субрегіонів, присвоюючи кожному субрегіону інше значення насіння, яке потім генератор регіону використовує для висіву окремого екземпляра RNG, який він використовує для генерації регіону тощо. Це уникне «ефекту метелика», коли зміна навіть найдрібнішої деталі найдрібнішої частини карти може викинути RNG з синхронізації та призвести до того, що все інше у світі буде зовсім іншим.
Ще один важливий спосіб уникнути ефекту метелика, особливо якщо ви генеруєте світ "на льоту", коли гравець досліджує його, - уникати нормальних РНГ цілком (за винятком процесів, які відбуваються "миттєво" з точки зору гравця, наприклад генерування новий рівень, коли гравець переходить на нього) і замість цього використовують методи генерації випадкових чисел, які не зберігають внутрішнього стану. Наприклад, вибираючи насіння для субрегіону, в який збирається ввести гравець, загальний генератор світу може прийняти координати субрегіону (і власне загальне насіння) і подати їх на хеш-функцію для генерації насіння субрегіону. Таким чином, кожна область завжди буде виглядати однаково, незалежно від порядку, в якому гравець входить до них.
Пс. Після всього цього відступу дозвольте мені коротко вирішити ваше останнє запитання щодо фактичного коду, який використовується для генерації процедур. На жаль, я не думаю, що це справді відповідає в будь-якому змістовному сенсі без набагато більш детальної інформації, ніж ви надали, оскільки існує буквально стільки різних способів зробити процедурне покоління у світі, скільки є ігор з їх використанням.
Наприклад, великий правдивий батько всіх процедурно створених розвідувальних ігор, мабуть, розбійник , алгоритм генерації якого рівня просто полягав у випадковому розміщенні кути прямокутних кімнат у більшому прямокутному рівні та з'єднанні цих кімнат з проходами (і розміщенням сходів на наступний рівень в одному з них). Його різноманітні спадкоємці , від Nethack до серії Diablo , багато в чому розробляли цю систему, але більшість з них зберегли основне уявлення про різні рівні, що складаються з кімнат, підземелля та лабіринтів, більш-менш випадковим чином розміщених на карті сітки.
І навпаки, для ігор із відкритими налаштуваннями на відкритому повітрі ви, мабуть, захочете почати з якогось алгоритму генерації фрактальної місцевості та будувати над цим інші функції (річки, ліси, міста тощо). Або ви можете зробити щось на кшталт того, що робить Minecraft , і створити випадкову тривимірну процедурну текстуру, визначаючи, які частини вашого ландшафту відповідно є землею та повітрям (масштабування та упередженість, так що нижчі блоки, швидше за все, заземляються), а потім накладення функцій, як вода , ґрунт / скеля, рослинність тощо.
Звичайно, жоден з перерахованих вище не застосовується , якщо ви, скажімо, писати гру космічної розвідки , в цьому випадку вам просто потрібно створити набір випадково розташованих зоряних систем в відповідно до деякою функцією щільності, а потім генерувати випадкові набір зірок і планет у кожній з них. Або, можливо, ви налаштовуєте гравців досліджувати неевклідовий ландшафт , і в цьому випадку вам доведеться зіткнутися з зовсім іншим набором завдань (наприклад, той факт, що обсяг у заданому радіусі росте швидше в експоненціальному, а не поліноміальному відношенні). дійсно важко зберегти велику карту в пам’яті).