Игровая индустрия: Чужой язык: как мы говорим про процедурную генерацию

Это перевод вот этой статьи. Автор — Майкл Кук.
Спасибо Атрону за наводку.


Процедурная генерация существует не первый день. Мы приближаемся к 40-летию Rogue, Elite уже отпраздновала 30-й День рождения, и даже бодрый Spelunky скоро начнёт считать возраст двузначными числами. Мы десятилетиями видели, как старые идеи переделываются и полируются, а с новыми экспериментируют и проверяют их на прочность. Однако одна вещь всегда оставалась прежней и пряталась от глаз всякий раз, когда приносила проблемы, в надежде, что потом о ней все забудут. С выходом No Man's Sky я считаю, что игнорировать это уже нельзя. Нам надо поговорить о том, как мы говорим о процедурной генерации.


Игровая индустрия: Чужой язык: как мы говорим про процедурную генерацию

Первый трейлер NMS вызвал большую шумиху, показав вибрирующие красками планеты с разнообразной живностью, заманивая всевозможными космическими приключениями. В трейлере я заметил несколько интересных фраз, которые выделил для себя. «Каждый атом процедурно сгенерирован, каждая планета уникальна.» Сам по себе такой язык не является чем-то уникальным в игровом маркетинге. Например страница игры The Binding of Isaac в Стиме обещает вам «Вы никогда не будете играть в одну и ту же игру дважды», но никто же и бровью не поведёт, внезапно осознав, что он раз за разом играет во всё одну и ту же The Binding of Isaac. Только одно было удивительно с трейлером NMS — с какой поразительной доверчивостью многие купились на все эти обещания ещё до того, как стали известны хоть какие-то подробности об игре, ещё даже до того, как сами разработчики отчётливо понимали что же они на самом деле создают.

Игровая индустрия: Чужой язык: как мы говорим про процедурную генерацию

Процедурная генерация говорит языком, в словаре которого есть много знакомых слов: разведывать, уникальный, бесконечный, вечно, переигрывать. Он пользуется числами со степенями десяти, а больше — значит лучше. Необязательно эти слова используются неверно, но намеренно или нет, они вводят людей в заблуждение просто потому, что их можно интерпретировать совершенно разными способами. «Каждая планета уникальна» можно понимать как если бы она обладала сложной фантастической предысторией, готовой для двухсерийного эпизода Стар Трек. Либо же, математически говоря, это может значить, что где-то на этой планете есть камень, непохожий на любой другой камень во вселенной. Уникальность почти всегда используется в слабейшем своём, однако наиболее технически правильном смысле. Как метко заметила Кейт Комптон в своём посте о процедурной генерации:

Каждая тарелка каши — уникальна

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

Игровая индустрия: Чужой язык: как мы говорим про процедурную генерацию

Может ли быть лучше? Когда мы пользуемся радикальными значениями слов при разговоре о процедурной генерации (или любой другой технологии), мы поощряем людей воображать радикальные же выводы. Возможно нам нужен другой подход, тот, который уходит от грандиозных заявлений и больших чисел. В последнее время я задаюсь вопросом, не было бы лучше, если бы процедурная генерация сосредоточилась на прямо противоположном — взять отдельный кусочек контента и объяснить, как он устроен. Вот мой генератор решает, куда спрятать плюшки. Вот так он рисует нужным оттенком закат. Вот откуда взялось это шуточное имя корпорации. Мы можем подключить людей к пониманию того, как работают наши генераторы, чтобы снять с них фантастический ореол невообразимой сложности.

Я не говорю, что каждый должен встать на этот путь. Некоторые генераторы извлекают пользу из своей необъятности, как например мистически нескончаемое поле для гольфа в Desert Golfing, где речь о его масштабе помогает донести нужные ощущения. Другим играм полезно совсем не говорить о своих «внутренностях». Мне не нужно знать как создаётся остров в Proteus, и я бы предпочёл это так и оставить. Наверное для многих генераторов вы бы нашли объяснение их работы немного… скучным? И вы были бы правы. Большинство из них и правда ужасно скучны, это одна из причин, почему мы скрываем эту правду за гигантскими цифрами и грандиозными заявлениями. Вместо этого мы, как дизайнеры и художники, должны уверенно понимать, что используем их для создания задуманного эффекта. И раз оно не стоит того, чтобы углубляться в детали, то и не надо его упоминать вовсе. У вас в игре, может, есть ещё шейдеры и физика, они тоже стоят упоминания как часть игры.

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

Игровая индустрия: Чужой язык: как мы говорим про процедурную генерацию

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

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

Игровая индустрия: Чужой язык: как мы говорим про процедурную генерацию

102 комментария

avatar
Когда впервые услышал о NMS, первое что пришло в голову: «Планетарий на процедурной генерации? Да это же Space Engine».
Когда знакомые начали рассказывать об анонсе NMS, я их спросил: «Что же там такого нового?» и получил в ответ множество фантазий об игре, в которой можно делать все. Верилось с трудом, но за отсутствием вменяемой информации только это и оставалось.
И вот релиз и множество восторженных отзывов не от геймплейной составляющей, а именно о технологии, которой якобы раньше не было. И либо разработчики NMS действительно сделали какой-то идеологический прорыв, либо просто это печальный пример того насколько важны пиар и реклама.
Вот ссылка на вики с описанием Space Engine, если кто-то о нем не слышал ru.m.wikipedia.org/wiki/Space_Engine. Уточню: бесплатного проекта от питерского разработчика с теми самыми квинтилионами сгенерированных звезд и планет, которые движутся по орбитам и физическим законам в сгенерированных вселенных.
  • +5
avatar
«НоНеймМенСкай», просто — хорошо разрекламированный продукт.
А я забыл спросить, может кто знает?! Если вылететь с планеты, ВЫЙТИ ИЗ ИГРЫ, потом сесть на другую, потом вернутся на старую, она останется такой же как и раньше?
Комментарий отредактирован 2016-08-30 03:41:25 пользователем Ieliar
  • 0
avatar
Ну если я правильно понимаю процедурную генерацию, то должна. А если нормально сделаны сейв файлы, то и ваши действия тоже могут остаться.
Там по сути планета это число, которое загружается в процедурный генератор, когда вы на нее садитесь. И если там нет лишнего рандома, то планета генерируется по нему, каждый раз одинаково.
Если есть, то это уже не процедурная генерация, а случайная. Что намного проще и гораздо старше.
  • 0
avatar
Детерминированный рандом старше «случайного», да и проще тоже)

Плюс некоторые изменения таки сохраняются. Например, нельзя 2 раза собрать один монолит.
  • 0
avatar
Ну на мой взгляд детерминированный рандом это по сути и есть процедурная генерация. /вспоминает 255 галактик в Элите/
Изменения сохраняются скорее всего через сейв (т.е. после генерации идет дополнительная корректировка результатами деятельности игрока)
  • 0
avatar
Сейв это и есть зерно плюс разница. Чем больше наизменял — тем тяжелее сейв.
  • 0
avatar
Насчет истории не уверен, но чем случайная генерация проще процедурной? Для случайной нужно то же, что и для процедурной плюс как-то получать seed.
  • 0
avatar
Случайная это /random. Процедурная предполагает наличие более сложных и комплексных функций. То, что ты хочешь сказать описывается словом «детерминизм». То есть детерминированно сгенерированный мир будет создаваться одинаково раз за разом в том числе на разных устройствах и клиентах (что предполагает мультиплеер). Недетерминированный мир всякий раз будет разным.

Хоть сложный процедурный, хоть простой рандом может быть как детерминированным, так и нет.
Комментарий отредактирован 2016-08-30 14:44:28 пользователем hitzu
  • +4
avatar
Процедурная генерация — это просто антоним к «созданная человеком». Случайная генерация — это лишь одна из разновидностей процедурной.
  • +1
avatar
Случайная генерация — это лишь одна из разновидностей процедурной.
Конечно. Любая генерация строится на каком-либо случайном шуме. Даже если в основе генерации лежат фракталы, например L-system, то чтоб они не выглядели математически идеально, их искажают с помощью шумов.
  • 0
avatar
А существует ли вообще пример полностью рандомной генерации? Ведь ахинея полная получилась бы. Даже максимально свободная система все равно должна быть ограничена каким-то алгоритмом, чтобы результатом генерации стало то, что нужно в рамках игры, а не сюрреалистический ремейк черного квадрата.
  • 0
avatar
А существует ли вообще пример полностью рандомной генерации?
Корейский рандом же. Забыл? :)
  • 0
avatar
Ну с генерацией цифр все понятно. Речь же идет о генерации локаций или я что-то упустил?
  • 0
avatar
Процедурно можно генерировать хоть музыку, хоть квесты, хоть диалоги, хоть крафтовые рецепты, хоть лут.
  • 0
avatar
И во всех известных случаях получается либо китайский рандом, либо что-то равномерно-посредственное.
  • 0
avatar
Ну как и ландшафт во всех известных генераторах в играх выдаёт картинку не сильно лучше простого Перлин нойза.
  • 0
avatar
Собственно проблема всех генераторов ландшафта как раз в этом, ты не находишь? Они все выдают слишком усредненный ландшафт, обычно это какие-то равнино-холмы без запоминающихся деталей.
В таких случаях вот это чувство «я здесь уже был», оно возникает уже минут через десять, тогда как в реальности можно час идти по лесу и такого чувства не возникает, конечно если не блукать кругами.
Аналогичная проблема однообразности/заезженности возникала и в процедурно-сгенерированных лабиринтах. Diablo, Hellgate London, Torchlight, PoE. Они используют генерацию и ограниченную библиотеку примитивов, в итоге шансы наткнуться на что-то уникальное есть только первые разы. И ни у кого не получилось подружить этот подход с китайским рандомом так, чтобы он не выдавал не жизнеспособных вариантов.
  • 0
avatar
Ну смотри, можно легко пояснить на таком примере:

Вот мы решили делать процедурный лес. Нам нужны деревья. Мы можем заготовить 10 ассетов с деревьями и расставить их в определённых местах, покрутить и немного поиграть с размерами. И наверное игрок даже не заметит ограниченности, но мы хотим больше. А что если сделать несколько ассетов для стволов и несколько ассетов для ветвей, и внутри функции размещения деревьев написать функцию сборки деревьев из этих деталей. Тут можно тоже поиграть с размерами деталей, их густотой или цветом. Можно даже поизгибать их немного в разных местах, а можно подстраивать форму дерева под окружение, например убирать, укорачивать или изгибать ветви, растущие в сторону стены. А можно пойти дальше и внутри функции сборки деревьев вставить функцию сборки ветвей, которая точно делает каждое дерево точно уникальным. И чем больше таких вложенных итераций будет в генераторе, тем сложнее будет человеку найти паттерны и повторения, но и тем затратнее будет всё это генерировать и хранить, конечно.
  • +1
avatar
Дык вроде это в NMS и делают?) уж деревья-то у них не повторяются)
  • 0
avatar
Не думаю, что генератор деревьев сколько-нибудь значительно сложнее генератора животных. Это скорее деформация восприятия самого человека. Практика показывает, и в этом несложно убедиться, что мы с трудом различаем те самые 10 ассетов деревьев, если их расставлять в случайном порядке с разбросом по вращению и размерам. Нам действительно будет казаться с первого (и со второго) взгляда, что это всё разные модели.

А с животными видимо наш мозг приспособлен работать лучше и равный по сложности генератор для них нам будет казаться гораздо проще и закономерности мы будем находить чаще.
  • 0
avatar
1. Для дерева не нужна сложная анимация, поэтому можно сделать больше разнообразия.
2. Кривое дерево — это норма. Кривое животное — это нежизнеспособный урод.

Поэтому генераторы ладшафта и деревьев получаются неплохие, а генераторы животных рождают чудовищ.
  • 0
avatar
То я и говорю. Генераторы животных должны быть сложнее.

А осевую или центральную симметрию сгенерировать несложно. Я не понял к чему аргумент про кривизну.
  • 0
avatar
Они все выдают слишком усредненный ландшафт, обычно это какие-то равнино-холмы без запоминающихся деталей.
Что прописали в процедуре — то и выдает. Видимо, забыли что-то вроде «особые ситуации, которые создавать только изредка».
Комментарий отредактирован 2016-09-02 23:50:23 пользователем Agrikk
  • +1
avatar
Процедурно можно генерировать хоть музыку, хоть квесты, хоть диалоги, хоть крафтовые рецепты, хоть лут.
Ну… как бы да. И из всего этого рандомно можно сгенерить только цифры/буквы/символы, в общем простые объекты и значения. Все остальное требует определенных алгоритмов и ограничений (по крайней мере для получения осмысленного результата).
  • 0
avatar
При процедурной генерации нужно писать весь объект сразу, а при рандомной можно дробить код более смело. Рандом в общем случае проще в разработке.
  • 0
avatar
Дробить код — это делать несколько маленьких процедур, которые из рандомного числа делают что-то свое? Тогда для процедурной генерации достаточно побитно выделить из большого числа несколько мелких и подать на вход этих процедур.
  • 0
avatar
При чисто рандомной генерации можно сделать цикл в котором по случайному выбору выполнять один из шаблонов.
В процедурной такого цикла не сделать без сопутствующих вычислений. Которые или будут достаточно сложными или приведут к тому же псевдослучайному генератору (как например в достаточно большом количестве языков программирования rnd(n) всегда будет выдавать одинаковую псевдослучайную последовательность для конкретного n (поэтому я Элиту и вспомнил с ее 256 галактиками — там похоже именно такой рандомайзер и стоял))
  • 0
avatar
Хватит придумывать какие-то свои термины, да еще и в таком посте.

In computing, procedural generation is a method of creating data algorithmically as opposed to manually. In computer graphics, it is also called random generation and is commonly used to create textures and 3D models.
en.wikipedia.org/wiki/Procedural_generation
  • +1
avatar
Чуть ниже вспомнил про нее.
Возможно.
Хотя я бы все таки разделил рандом и процедуры. Чисто по принципу построения кода.
  • 0
avatar
Есть процедуры, они генерируют контент. Можно подавать на вход процедуры случайные данные, но при подаче одних и тех же данных они все равно будут давать одинаковый результат.
Даже если внутри процедуры есть 10 вызовов функции rand(), их можно (и даже нужно) заменить на входные параметры.
  • 0
avatar
Даже если внутри процедуры есть 10 вызовов функции rand(), их можно (и даже нужно) заменить на входные параметры.
А если их не 10, а допустим 10000(00) (заполняем карту с планетами или поле с травами)?
То что укладывается в количество до 1000 элементов естественно лучше генерировать вручную без лишнего рандома.
  • 0
avatar
А если их не 10, а допустим 10000(00) (заполняем карту с планетами или поле с травами)?

Формально любое количество вызовов rand() можно свести к входным параметрам функции. Пусть у нас на вход подается массив из миллиона чисел, а генератор на основании этих чисел расставляет миллион травинок.
Как заполнить этот массив перед вызовом генератора?
Можно вызвать 1000000 раз настоящий рандом и заполнить.
А можно взять хороший генератор псевдослучайных чисел, проходящий все известные тесты, скормить ему одно 64-битное число в качестве сида, и заполнить им.
Да, формальная мощность второго генератора (жалких 18 квентиллионов) намного меньше, чем первого. Но для человека это не имеет значения.
  • +1
avatar
Ну это как раз и будет рандом по реализации.
генератору можно внутренний таймер тогда скармливать для простоты и надежности.
  • 0
avatar
Это не имеет отношения к реализации, это внешний фактор, представление входных данных.
Что на этих входных данных будет реализовано — банальная комбинаторика или крутой генетический алгоритм? Зависит от разработчика генератора.
  • 0
avatar
Если рандомная генерация — это цикл, в котором по случайному выбору выполняют один из шаблонов, то что мешает сделать процедурную генерацию с циклом, в котором аргумент последовательно сдвигают вправо, выделяют младшие биты и выполняют шаблон с этим номером. Таким образом все случайные выборы описываются одним числом, которое можно подать на вход, а можно сгенерировать?

Если ты сам говоришь, что они приведут к тому же псевдослучайному генератору, то в чем смысл выделения «случайной генерации»?

Пример не понял. Я не большой знаток языков, во всех, что знаю, можно задать seed псевдослучайной последовательности. А то, что при одинаковом seed'е последовательность одинакова, это же ее тривиальное свойство, поэтому ее и называют псевдослучайной.
И почему нельзя сказать, что в Элите была процедурная генерация, я тоже не понимаю.
  • 0
avatar
В Элите была как раз процедурная генерация, в смысле построения графики, но при этом рандомная по эффекту восприятия.
  • 0
avatar
И этого я тоже не понимаю.
Чуть выше ты говорил «по принципу построения кода». Ты это на глаз видишь?
  • 0
avatar
Ну например в «Цивилизациях» отличаются же карты случайные от пользовательских?
Вот в Элите они сильно были похожи именно на случайные.
Это разве не видно. Тогда возможно тоже мой глюк.
  • 0
avatar
В цивилизациях никогда не пользовался пользовательскими картами. В героях да.

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

А вопрос похожести на пользовательские — это не вопрос отличий процедурной генерации от «рандомной», а вопрос реализации процедурной генерации.
  • 0
avatar
Там наверняка (точно сейчас не вспомню) был один аргумент, по которому карта строилась.
Там были несколько шаблонов плюс процедура с рандомной вариацией этих шаблонов.

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

Там по сути планета это число, которое загружается в процедурный генератор, когда вы на нее садитесь. И если там нет лишнего рандома, то планета генерируется по нему, каждый раз одинаково.
Если есть, то это уже не процедурная генерация, а случайная. Что намного проще и гораздо старше.

На мой взгляд, во втором случае, когда есть рандом, планета генерируется не только в зависимости от вышеупомянутого числа, но и от выпавшего случайного числа. Таким образом, если взять два аргумента (или один, можно ведь преобразовать их к одному), то ими (им) планета полностью описывается. Разница только в том, откуда берется аргумент, полностью определяющий планету. Так что я не вижу особенной необходимости вводить два отдельных термина.
  • +1
avatar
Таким образом, если взять два аргумента (или один, можно ведь преобразовать их к одному)
Вообще то нет. если второй аргумент переменная. которая будет меняться случайно, то их привести будет сложно если вообще возможно.

Но вообще походу я тоже немного не в ту степь ушел.
Процедурная генерация (еще в одном смысле) раньше противопоставлялась хранению данных. Т.е. планета не лежит у вас на диске в виде кучи рисунков. скелетов и текстур, а рисуется программой по числу или массиву, без участия кучи графических файлов. Что позволяло писать хорошие графические вещи размером в килобайты когда то. Даже конкурсы были. Может в этом смысле была процедурная генерация?
  • 0
avatar
Вообще то нет. если второй аргумент переменная. которая будет меняться случайно, то их привести будет сложно если вообще возможно.

Я, может, попозже смогу как-то переформулировать, но пока как-то то же самое получается.

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

Два аргумента можно заменить одним побитово объединив их — из двух аргументов размером n и m бит получается один n+m бит.

Процедурная генерация, которая противопоставлялась хранению данных, не вижу чем отличается от процедурной генерации в NMS. По-моему это одно и то же.
  • 0
avatar
Два аргумента можно заменить одним побитово объединив их — из двух аргументов размером n и m бит получается один n+m бит.
так можно но по сути замены нет. Просто есть сложение обоих переменных в один кусок памяти. Если пишем не на ассемблере удобнее будет оставить 2 аргумента. ;-)

Процедурная генерация, которая противопоставлялась хранению данных, не вижу чем отличается от процедурной генерации в NMS.
разработчики скорее всего ее и имели в виду. Меня слегка занесло. Профдеформация — я все таки логику пишу по работе, а не графику вот мысль и свернула сразу в логические отличия. А про процедурную генерацию графики вспомнил сильно не сразу. %-)
  • 0
avatar
так можно но по сути замены нет. Просто есть сложение обоих переменных в один кусок памяти. Если пишем не на ассемблере удобнее будет оставить 2 аргумента. ;-)

Почему замены нет? Было две переменные, стала одна.
На C тоже вполне удобно было.

я все таки логику пишу по работе, а не графику вот мысль и свернула сразу в логические отличия.

Вот и интересно, где здесь логические отличия.
  • 0
avatar
Вот и интересно, где здесь логические отличия.
Долго объяснять.
Ну скажем так чистая процедура по числу или даже массиву в параметрах и случайная генерация у меня бы отличались в разы по объему кода.
даже с учетом ограничения на рандом.
Код рандомной генерации очень хорошо сжимается и структурируется без потери качества. Рандомную енерацию намного проще писать. И.т.д.

Почему замены нет? Было две переменные, стала одна.
Потому что работать мы все равно будем с ними как с двумя переменными. с дополнительной проблемой по вытаскиванию и пониманию кода впоследствии(что после возвращения к коду через пару месяцев очень даже играет).
Передавать тогда можно хоть сотню переменных в строке через запятую, но от этого они не будут снова одной переменной. Строку придется разворачивать внутри функции обратно.
  • 0
avatar
Долго объяснять.

Но интересно ;-)

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

И кстати, можно задавать переменную, которая станет seed'ом псевдослучайной последовательности, которая используется дальше. И это тоже будет процедурной генерацией.
  • 0
avatar
На мой взгляд все все эти отличия не логические. Это, скорее, вопросы реализации.
Опять долго объяснять (тут без блоксхем и примеров трудно объяснить) — логика меняется при проектировании этих двух способов.

Если кто-то на ассемблере будет писать — кода много — это же не значит, что метод другой.
На ассемблере надо реально немного по другому думать.
оффтоп но. Логика меняется в зависимости от типа языка.
Функциональные, объектно ориентированные, еще какие то тысячи их не помню сейчас всю теорию… каждый подразумевает свою логику и принципы реализации задачи.
  • 0
avatar
Значит мы про разную логику говорим. Гениальная мысль всего за два часа обсуждений, да ;-)
  • 0
avatar
Огромное спасибо за перевод! Очень круто!
  • +1
avatar
А игрокам по большей части не нужны описания как оно там генерится.
Вот игрок смотрит трейлер в стиме на страничке игры (обещания, были или не были, об этом не будем) и, по идее, это результат работы генератора.
Это только одна планета (та что с динозавриками на водопое), а их там 18 в 18 степени — бегу исследовать!
И вот по мере исследования появляются сильные сомнения, что в ролике, пусть даже редкая, но планета сгенерированная текущим генератором игры.

Мое скромное мнение, что основная проблема генератора в NMS — малая вариативность, в большинстве случаев.
Достаточно разнообразны, пожалуй, только животные и в чуть меньшей степени растительные формы.
Вторая проблема это равномерность распределения.

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

Вот, например источники железа выглядят по разному на планетах, что мешало применить это правило ко всем ресурсам? Сделать генерируемые минералы из которых можно добыть, пусть одни и те же на всю вселенную, элементы для рецептов. Уже лучше, чем одни и те же «кристалы».
Маловато элементов… ну не надо всю таблицу Менделеева, но хотя бы 30-40.
Тоже самое и с рецептами. Ландшафтом. Мало разновидностей.
Почему так мало вариаций строений, которые, вроде как, одни и те же у разных рас, что за унификация?
Более того — всего три расы на галактику…
Да ладно, пусть три. В старкрафте 20 лет назад тоже было три, но у них ВСЁ различалось.

Вот если бы все это генерировалось в огромном числе вариаций…

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

И вот тут еще по генерации животных/растений:
Температура, токсичность, радиация — отличаются только цветом полоски, минимально влияя на генерацию.
На радиактивных планетах можно было бы генерировать более нелепых обитателей.
На низкотемпературных живность с длинной шерстью. И Все в таком духе.
На благоприятных планетах более гармоничную живность.
Да как угодно, но по правилам — процедурно, а не случайно с ровным распределением.

В роликах игроков (не беру в расчет тех, кому «не завезли мультиплеер и обещания») одна и та же история. В первых роликах — восторг.
Но быстро все начинает повторятся и восторг сменяется скукой.
Комментарий отредактирован 2016-08-30 16:30:50 пользователем ixes
  • +6
avatar
А игрокам по большей части не нужны описания как оно там генерится.
Выходит так, что нужны. А то они в своём воображении строят совершенно нереалистичные картины возможностей процедурной генерации, думая что они как по волшебству сделают также, как оно делается ручками, только квинтиллион раз.
  • 0
avatar
А то они в своём воображении строят совершенно нереалистичные картины возможностей процедурной генерации
Оставим в покое воображение на секунду и посмотрим официальный ролик на странице игры в стиме.

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

они как по волшебству сделают также, как оно делается ручками, только квинтиллион раз
Касательно процедурной генерации космоса — SpaceEngine, выглядит и правда волшебно.
  • 0
avatar
Касательно процедурной генерации космоса — SpaceEngine, выглядит и правда волшебно.
Но там нет и половины того, что есть в НМС. Есть другая добрая часть того, чего нет в НМС, но Спейс Энджин ещё меньше игра, чем НМС.

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

Эдакая Uncanny Valley для планет, хехехе
  • +3
avatar
Но там нет и половины того, что есть в НМС. Есть другая добрая часть того, чего нет в НМС, но Спейс Энджин ещё меньше игра, чем НМС.
Я их и не сравниваю, а отвечаю, на Вашу фразу.
Можно сделать квинтилион раз процедурно и получится красиво, разнообразно, правдоподобно и это не волшебство.
А то, так можно Вас понять — глупые наивные игроки ждали чего-то невозможного.
Да и НМС не так уж плоха, хотя немного больше разнообразия бы точно не помешало.

А чем больше разнообразие, тем меньше потенциальных ситуаций:
иначе придёт какой-нибудь придирчивый игрок и скажет...
Они конечно придут, но их десятки придирчивых реплик просто потонут среди десятков тысяч реплик восхищенных.
Комментарий отредактирован 2016-08-31 21:52:44 пользователем ixes
  • 0
avatar
Мы уже прошли этот путь с шутерами, и ничего же.
Когда был двухмерный плоский Вольф, хотелось третьего измерения, чтобы прыгать еще. И чтобы рубиться с товарищами. В Думе уже можно прыгать, и с товарищами рубиться, но ток по локалке, и графика вся спрайтовая, кривая. В Кваче графика уже объёмная, но все еще кривая. В Халфе кортинка вроде стала получше, но физика еще печальная, и анимация вообще печаль.
И так по нарастающей. Становится более-менее реалистичной физика, начинает хотеться больше детализации, чтобы больше объектов этой физике подчинялось. Становится лучше графика, более похожими на человеческие лица персонажей — начинает хотеться более сложной лицевой анимации. Появиалсь скелетная анимация регдола, хочется более сложный регдол, и потому сейчас только в низкобюджетных совсем уж проектах анимируют модели вручную, а в основном моушн кепчер используется.
Чем больше есть, тем больше хочется, и это нормально.
  • 0
avatar
Здравая мысль, но она не оправдывает промахи NMS.

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

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

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

Грубо говоря, разработчики нагоняли хайп обещая в игре эти условные «50 переменных», а выдали продукт только с 10.
Комментарий отредактирован 2016-09-01 11:47:37 пользователем Gelinger
  • +3
avatar
Процедурная генерация сама по себе не может быть основной «фишкой» игры, фундаментом геймплея, она является инструментом, не больше ни меньше.
Не то чтобы я когда-либо утверждал обратное. Скорее наоборот. :)

NMS предлагает нам геймплей основанный на исследовании
Да нет же. Основной геймплей, как верно заметил Ascend, заключается лишь в расширении инвентаря.

Грубо говоря, разработчики нагоняли хайп обещая в игре эти условные «50 переменных», а выдали продукт только с 10.
Собственно это я и имел ввиду.
  • 0
avatar
То что разработчики запороли эту идею, не значит что это сделать было невозможно.

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

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

Идея довольно банальная, но почему-то её игнорируют. Чтобы игра была похожа на реальность, нужно выявить законы, которые определяют реальность. Особенно это касается процедурной генерации.
Комментарий отредактирован 2016-08-30 21:59:29 пользователем Precursor
  • +8
avatar
Добавить широтность и высотность — и на планетах можно было бы дольше 5 минут сидеть.
Никто только никогда не задумывается об ограничениях железа.
Генерить планету в несколько проходов, сначала высчитывая карты температур\влажности.
Конечно. И по 15 минут сидеть перед каждым прилётом в новую систему, когда генерируются планеты.
  • 0
avatar
Никто только никогда не задумывается об ограничениях железа.
Хорошо что в 90-х никто не задумывался и всё прекрасно работало ;)

У них существует минимум 3 ландшафто-зависимых параметра генерации растений: градиент высоты, покрытие водными тайлами и расстояние до пещерных тайлов.

Плюс все это покрывается шумом Перлина с разным размером сетки и его амплитуда тоже идёт как дополнительный параметр.

Если кто-то возмётся утверждать, что высотность или широтность усложнит эти алгоритмы на несколько порядков — с радостью выслушаю аргументы ;)

Даже для температур и влажности наложить на высотность\широтность диаграмму Воронного от водоемов + результаты итерации с деревьями — и будет быстрое и достаточно реалистичное распределение.


В том-то и дело, что после всей их проделанной работы, такие фишки делаются на раз-два.
  • +2
avatar
Я не утверждаю, что это всё невозможно. Было бы глупо с моей стороны. Просто такие вещи это всегда трейдофф между разнообразием и бюджетом ресурсов.

Даже для температур и влажности наложить на высотность\широтность диаграмму Воронного от водоемов + результаты итерации с деревьями — и будет быстрое и достаточно реалистичное распределение.
А другие скажут нет, нереалистично. Хотим чтоб ещё реки были настоящие, и чтоб влажность распределялась по доминирующим в регионе ветрам, чтоб горы ветровую тень ещё создавали. А ещё хотим чтоб вулканы были и чтоб альбедо считалось, а северные сияния чтоб зависели от магнитного поля. И всё это в окружении красивой графики и умного ИИ. Ведь это же всё так легко и просто сделать — в игре А это было уже 20 лет назад, а вот эти фичи были в игре Б, В и Г. Главное осталось в одно это совместить, и пожалуйста, желательно побыстрее. Лучше всего — вчера.
Комментарий отредактирован 2016-08-31 17:04:25 пользователем hitzu
  • +1
avatar
Замечания интересные, но и это не проблема! ;)

Вулканы из карты литосферных плит, которая является производной генератора материков. Заодно у нас появятся нормальные горные хребты (не берусь утверждать что их в NMS нет, но я пока не видел).

Северные сияния и магнитное поле вообще проблем не составляют) свяжем их с параметрами радиоактивности и температурной опасности.

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

С ветрами согласен, это может быть тоже крутой инструмент. Алгоритм, на самом деле, очень похож на реки. Накидали температурную карту и просчитали «стекание» по ландшафту.

А если ресурсы останутся, то под конец набросили альбедо и сделали вторую итерацию расчетов)

Надо будет как-то на выходных набросать код, но уверен, что такие подготовительные этапы жрут мизерную часть ресурсов по сравнению с растительностью и животными.
  • +1
avatar
Я понимаю что всё это возможно. Я видел генератор на джаве прямо в браузере, которые делает географию на основе литосферных плит. Он даже немного атмосферу симулирует с разными поясами, ветрами и прочим. Видел алгоритм, который хорошо генерирует распределение температуры по широтности и влажность по векторному полю ветров, с ветровой же тенью от гор, в которой должны быть пустыни. Видел алгоритм, который правдоподобные реки генерирует с итерацией водной эрозии (кстати пасфайндинг обычно — самая ресурсоёмкая часть, а ещё есть проблема когда он натыкается на локальный минимум и надо создать здесь озеро), видел генератор, который наоборот от моря идёт вверх по локальным минимумам с вероятностью ветвления, видел генератор, который генерирует сначала реки по L-system, а на их основе уже создаёт правильный ландшафт (что кстати не лишено смысла).

Я только не видел никогда чтоб это всё вместе было, с быстрой генерацией, да ещё и на сфере, на которую красиво двумерную матрицу не натянешь, но в которой всё можно очень компактно хранить. Сфера вообще самая противная часть — её затайлить нельзя, а если будешь сшивать из квадратов или шести-пятиугольников, то надо как-то компенсировать возникающие при преобразовании в сферу артефакты. Ну или хранить случайный массив точек, который ещё надо придумать как сжимать для создания LOD. Бррррр короче :)
  • +3
avatar
Вот блин, всё уже есть, а я уже студию запустил! :(

Ну дык, к чему тогда вообще эти споры?) Вот я глянул их презентацию — проделана огромная работа по генераторам локального ландшафта. Причём всё модульно и можно спокойно экспериментировать с 2-д генератором первичной поверхности. (хотя куб, это просто ахтунг!)

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


Эрозия, фрактальные речные системы и побережья — это нужно локальным генераторам.

Задача первичного генератора — просто раскидать типы биомов по поверхности.
Земля уже на 100 тысячах тайлах (500х200) начинает терять некоторые важные детали ландшафта. Но планеты в NMS в тысячи раз меньше, так что вполне можно обойтись генерацией карты в 125х50 тайлов, проецировать её цилиндрической проекцией и залепливать полярными шапками.

Это секундное дело. А дальше всё разруливают их крутецкие алгоритмы локальной генерации и LOD-а.

Больше похоже на то, что у них в команде никто не увлекался географией, и никому даже в голову не пришло усложнять первичную генерацию.
  • +1
avatar
Ну дык, к чему тогда вообще эти споры?)
Да к тому, что это какой-то локальный парадокс Ферми — если всё так просто, возможно и уже даже запрототипированно, то где же все эти десятки-сотни игр на процедурной генерации, которые сэкономили разработчикам сотни нефти и человекочасов? :)

Больше похоже на то, что у них в команде никто не увлекался географией, и никому даже в голову не пришло усложнять первичную генерацию.
Ну вот я слышал жалобы, что летать между системами (когда генерится новая) долго, мол могли бы и побыстрее. Наверное не могли, и наверное потому планеты такие простые и однообразные, чтоб процесс их создания не затягивался.
Комментарий отредактирован 2016-08-31 22:11:09 пользователем hitzu
  • +2
avatar
где же все эти десятки-сотни игр на процедурной генерации, которые сэкономили разработчикам сотни нефти и человекочасов?
Думаю, игры с процедурной генерацией уместно сравнить с компаниями Илона Маска. В тысячелетней перспективе они спасают человечество и ускоряют прогресс. Но на момент «здесь и сейчас» они слишком рискованные и даже местами убыточные.

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

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

Многие годы игры развивались экстенсивным путем — больше деталей\карта, больше худошников\дизайнеров уровней. 2-4-8 Гб видеопамяти! 8-20-50 Гб на жестком диске! Необходимость перемен давно назревает. Но никто не хочет рисковать.

Потому что все процедурные технологии сыроваты и требуют еще много работы. Которая может никуда и не вести. Плохое вложение денег.


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

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

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

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


Это всё задачки из серии с месяц поиграться на разных билдах с разным градиентом скорости корабля от высоты и разной скоростью входа\выхода из атмосферы.
Но да, их 13 человек и 3 месяца просрочки. Да ещё и мультиплатформенность. Результат закономерный.



А вообще тут история как с Терминаторами — твердый корпус плохо, жидкий металл плохо, а средний вариант самое оно.
Надеюсь, NMS выполнил главную функцию — поднял волну чтобы студии вроде Биоваров или Беседки захотели процедурную генерацию себе.
  • +7
avatar
Мы их тут критикуем что игра не вышла. А они нас убеждают что это не техдемо. Но по сути, они как раз провели громадную работу в технологиях, но не дотянули геймплей.
Понимаешь. Это как с любыми затерянными в истории технологиями — тысячи их — которые забыты не потому, что они плохие, а потому что с ними не смогли справиться нормально, или какой-нибудь сторонний фактор помешал, или рынок не готов был, или просто конкурирующая технология была просто первой.
  • +2
avatar
И по 15 минут сидеть перед каждым прилётом в новую систему, когда генерируются планеты.

Первые пару планет можно сгенерировать во время установки игры. Остальные генерировать в фоне, пока игрок гриндит ;)
  • +1
avatar
Они этот приём и так используют) животные у меня появляются спустя пару минут после высадки)
  • 0
avatar
Когда в фоне? И какие именно? Все вокруг? А смысл генерировать все, если нужна будет только 1 из 10, занимая процессор и память, которые важнее прямо сейчас на текущий геймплей?
  • 0
avatar
Зачем все? Просто генерировать следующую звездную систему. Прилетает игрок в новую систему, а все уже готово. Неважно, как он туда прилетел =)
В текущем варианте NMS разницы между различными секторами галактики никакой, так что можно сделать и так.
  • +1
avatar
Просто генерировать следующую звездную систему.
Я к тому что если следующих систем на выбор не одна, а три, десять, сто? Все генерировать, даже если он всё равно выберет только одну?
Комментарий отредактирован 2016-08-31 18:23:51 пользователем hitzu
  • 0
avatar
Зачем генерировать все? Генерируем одну! Не полетит же игрок сразу на все 100, верно?
  • 0
avatar
Но ты же заранее не знаешь куда он захочет лететь.
  • 0
avatar
Да мне все равно, куда он полетит. Просто на место его прибытия я подсуну сгенерированную систему.
  • 0
avatar
То есть ты узнаешь куда он полетит только когда он решит уже полететь и сможешь начать генерацию только в этот момент. До того, как он решил лететь, ты не сможешь предугадать это, а значит не сможешь начать генерацию, когда он майнит на планете ресурсы например.

Конечно, если ты сделаешь линейную игру, где есть всего один выбор — вперёд, ты точно знаешь куда он полетит дальше и сможешь генерировать на бэкграунде.
  • 0
avatar
Это если он летит вперед.
А если он летает по уже разведанным планетам?
А у нас процедурная генерация, то есть сгенерированная планета не хранится (если хранится будет проблема раздувания сейвов после долгой игры)
  • 0
avatar
Аааа окей, я перечитал и понял твой трюк. Только это будет работать, если ты не даёшь никакую информацию о системе заранее, например тип звезды, наличие планет и так далее. И как правильно заметил Шкуурник, это можно провернуть только с непосещёнными системами.
Комментарий отредактирован 2016-08-31 19:29:11 пользователем hitzu
  • 0
avatar
Если генерируется быстро, то можно генерировать на лету.
Если генерируется долго, но результат весит мало (генетический алгоритм на 1кк поколений, например), то можно и хранить.
Если и весит много, и генерируется долго, то конечно ничего не сделаешь, и нечего такому алгоритму в компьютерных играх делать.
  • 0
avatar
Вот потому и приходится идти на трейдоффы, урезая функции ради производительности.
  • 0
avatar
Я не думаю, что речь в производительности, скорее в ресурсах разработчика.
Кстати, в NMS же проход через черную дыру является необратимым. В этот момент можно чистить кэш сгенерированных систем. И подобрать размер кластера систем, доступных без прыжка через черную дыру так, чтобы кэш не разрастался больше какого-то разумного значения.
  • 0
avatar
Я не думаю, что речь в производительности, скорее в ресурсах разработчика.
Это тот парадоксальный момент, когда процедурная генерация как бы должна заменить тысячи часов ручного труда, а вместо этого сама занимает примерно то же время на создание, при этом даёт гораздо менее предсказуемые результаты.
  • 0
avatar
Была такая игра как SimEarth от MAXIS. На 20 Мгц процессоре с 640к ОЗУ эта игруля резво генерила мир о 10 тыс. блоков. С геологией, тектоникой, эволюцией (кто сказал Spore? Она самая).
  • 0
avatar
Маловато элементов… ну не надо всю таблицу Менделеева, но хотя бы 30-40.
У кого-то слишком много места в инвентаре. Мне можно и поменьше элементов сделать, и так не помещаются
  • +1
avatar
Как я и говорила — слишком короткая формула. Её можно было бы потихоньку наращивать в обновлениях, но не уверена, что это сделают.
  • +1
avatar
Весь этот хайпо-хейт возможно плоховато сказался на разработчиках.
Притянуло игроков, которые имеют совсем другие интересы, они ожидаемо вылили на игру и разработчиков свои тазики с отрицательными эмоциями.
Плюс там еще издатель, который, вероятно, торопил и вносил свои коррективы, а разрабы в итоге остались крайними.
В общем по человечески ребят жалко.
Надо иметь хорошую стойкость и волевые качества, чтобы после этого продолжать.

Вся надежда на модеров. Уже сделаны маленькие робкие шаги в этом направлении.
  • +1
avatar
Держи нас в курсе, вдруг что-то стоящее появится? У меня тоже вся надежда на моддеров.
  • 0
avatar
Ещё ко всему, существует идея процедурного «сценариста». Она тут мелькает периодически в обсуждениях.

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

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

Когда действие «провисает», можно влепить возле игрока интересное место или событие, которое потом больше никогда не встретится.

Ну и ещё важно не превращать это в аттракцион для слабоумных, как разработчики поступили с достижениями.
  • +2
avatar
Температура, токсичность, радиация — отличаются только цветом полоски, минимально влияя на генерацию.
Они как раз сильно влияют на «разновидности» растительности, на счёт животных не уверен. Правда, это всё равно сейчас вырождается в небольшое разнообразие внутри каждого из «условий»
  • +1
avatar
Они как раз сильно влияют
Спасибо за поправку, хорошо если так.

Я вот подумал, даже хорошо, с какой то стороны, что многие вещи не сразу бросаются в глаза.
  • +1
avatar
Ага, а потом начинаешь замечать, что ещё до посадки на планету можно по зарослям прикинуть, что тебя на поверхности ждёт. Токсичность, жара, или что-то другое. Разнообразия бы ещё побольше, эх :)
  • 0
avatar
Ну вот смотри. Значит их внешний вид зависит от внешних условий, и это заметил только наблюдательный ты, а все остальные не заметили и отругали игру за однообразие. Показательно.
  • 0
avatar
Я не стал в своё время это отдельно публиковать, всё-таки тема специфическая… Вот доклад, большей частью посвящённый процедурной генерации планет в NMS. С прошлогодней конференции разработчиков nucl.ai

archives.nucl.ai/recording/building-a-galaxy-procedural-generation-in-no-mans-sky/
  • +4
avatar
Хм, так значит у них генераторы проецируются сначала на куб, который преобразуется в шар. Это значит что в некоторых регионах плотность просто математически выше, чем в других. Забавный артифакт :)
  • +2
avatar
Странная статья. В духе «давайте не будем рекламировать, что у новой игры грутая графика, а лучше расскажем, как делается прорисовка и как работают шейдеры». Как оно рисуется — это сложная и скучная математика, игрокам это не интересно в большинстве случаев. Хотят как раз красивую графику.
Комментарий отредактирован 2016-08-30 18:49:29 пользователем Eley
  • 0
avatar
Какими словами можно говорить о крутой графике? Например, можно сказать, что проект делается на Unreal Engine или CryEngine. Можно сказать, что графика будет круче. В представлении игрока будут какие-то опорные точки.
А как описывать генератор? Слова вроде «18 квентиллионов планет» не говорят ни о чем. Разве что о том, что используется seed размером в 64 бита. Даже банальное «игра весит 6Гб» говорит гораздо больше.
  • +1
avatar
Но всё равно нужно ограничивать хотелки игроков.
Равно как и признавать-патчить косяки.

ИМХО, если бы авторы сразу признали косяки и назначили фич-лист «на реализацию», как тот же Жабейший, то негатива в отзывах было бы в 2-3 раза меньше.
  • +1
avatar
Надо — не врать себе, вернуть деньги и купить Elite Dangerous.
Комментарий отредактирован 2016-09-02 02:45:52 пользователем Ieliar
  • 0
avatar
Это мысли вслух или совет всем читающим?
Если для Вас лучше, просто поменяйте.

А если это совет для всех, то получается ерунда.
Это как купив аркадные гоночки, написать — «Надо не врать себе и купить гоночный симулятор».

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

А Элита это вообще космосим, тоже, кстати, не идеальный, если судить по отзывам в Стиме. Да, это тоже игра про космос, но акценты в ней совсем другие.
Комментарий отредактирован 2016-09-02 09:30:44 пользователем ixes
  • +1
avatar
Опять началось… уже всё понятно.
Я спорить не хочу, с человеком, который не играл в Elite Dangerous хотя бы 100 часов! Вот ещё совет — купи, наиграй, вникни и потом приводи мне куда больше предметов спора! Одно и тоже слышу от людей, уже надоело, если честно.
Комментарий отредактирован 2016-09-02 10:27:15 пользователем Ieliar
  • -1
avatar
Вот ещё совет — купи, наиграй, вникни и потом приводи мне куда больше предметов спора!
Не люблю симуляторы, слишком муторно.
И спора тут нет. Зачем спорить, что приятнее теплое или мягкое?
Если игра не нравится, можно просто напросто в нее не играть. Есть такая опция. Это касается и NMS и Элиты и чего угодно.

Одно и тоже слышу от людей, уже надоело, если честно.
Наверное не в первый раз предлагаете вместо аркады симулятор?
  • +1
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.