И о том, сколько времени заняла разработка, что должен уметь игровой движок, чтобы поддерживать подобную систему, а также причины, по которым, возможно, этого нет в Старфилде.
Когда в декабре 2013 года анонсировали No Man’s Sky, бесшовный переход с поверхности планеты в открытый космос все еще казался диковинкой, несмотря на то, что уже был реализован в Kerbal Space Program, Space Engine, Star Citizen, а также в нескольких трехмерных астрономических или исследовательских программах, вроде Celestia или Proland. В наши дни игроков сложнее удивить подобным, более того наличие этой функции ожидают ото всех серьезных космических симуляторов.
Но насколько сложна реализация подобного перехода в космос? Этим вопросом я задался в 2018 году, когда начал разработку своего космического симулятора. Для тех, кому интересно чуть глубже изучить данный вопрос, я написал две статьи, об исследовании предметной области и техническую статью о том, как приступить к генерации планет. Здесь же я буду рассматривать, что конкретно требуется от игрового движка, чтобы эту функцию на нем можно было бы реализовать.
Рендеринг атмосферы и рассеяние света частицами
Физически корректная атмосфера невероятно важна для космических симуляторов. Мало того, что она задает тон и настроение планете, так еще позволяет почувствовать ее масштаб. Из-за того, что атмосфера рассеивает и поглощает проходящие через нее лучи, цвет далеко расположенных объектов меняется и создает так называемую воздушную перспективу. В случае с Землей, цвета приобретают все более голубой оттенок, постепенно переходящий в белый на горизонте. Есть множество планет, спутников и астероидов, у которых атмосфера отсутствует, но это будут безжизненные ледяные ночью, и обжигающе жаркие днем пустыни. Их тоже можно сделать интересными и красивыми, но гораздо сложнее.
Стоит также отметить, что для бесшовного перехода атмосфера должна быть сферической, так как вы можете подлететь к планете с любого направления и улететь в любую сторону. Тогда как большинство современных игр и движков поддерживают отрисовку физически корректных атмосфер с рассеиванием света, в большинстве своем они «плоские». То есть предполагается, что у системы координат есть фиксированное направление «вверх», а камера будет всегда находиться у поверхности планеты. Это позволяет сократить количество вычислений и сэкономить немного времени на рендеринге кадра, но абсолютно не подходит для бесшовного перехода.
Генерация планеты с динамическим уровнем детализации
Отрисовать планету в виде сферы с наложенной на нее текстурой может абсолютно любая игра. Однако, если делать возможность посадки на нее без загрузок, нужно будет реализовывать генерацию поверхности на лету. Чем ближе игрок приближается к поверхности, тем более детализированной она должна быть. Чтобы компьютеры игроков не плавились от нагрузки, выдавая при этом 15 фпс и периодически вылетая на рабочий стол с ошибкой «out of memory», нужно генерировать и отрисовывать только ту часть планеты, которая в данный момент видна в камере. Соответственно в память загружается только необходимые данному участку ресурсы, в виде карт высот, текстур и объектов поверхности. Всего того, что находится вне камеры, не должно существовать. То есть игровой движок должен поддерживать стриминг ресурсов хоть в каком-то виде. Сами же алгоритмы генерации, динамического LOD и прочих вещей хорошо описаны в десятках научных работ, и после небольшого исследования поддадутся реализации большинству программистов со стажем работы в несколько лет.
Отсутствие фиксированной системы координат и статических объектов
Я уже упомянул в разделе с атмосферой, что в описываемых симуляторах с бесшовным переходом в космос не может быть единой системы координат с фиксированным направлением «вверх». Все объекты будут находиться на поверхности планеты, которая вращается вокруг своей оси. При этом планета будет вращаться вокруг звезды, да и сама звезда может перемещаться относительно центра галактики. Поэтому, в любой момент времени помимо системы координат, должна быть задана система отсчета. Приведу, конкретный пример в случае с академией джедаев на Татуине.
В обычных играх загружается сцена tatuin.scene. На ней в координатах (x: 54.32, y: 0, z: 122) стоит здание академии. Когда бы вы не загрузили эту сцену, здание будет всегда там стоять, независимо от того, была ли реализована смена дня и ночи, или нет. Это статичность позволяет уже на стадии создания игрового билда рассчитать множество данных, которые можно будет использовать в игре для ускорения вычислений. Например, навигационную сетку, коллизии, глобальное освещение, occlusion culling и много еще чего.
В случае космического симулятора академия будет находиться по координатам 44°25′ с. ш. и 38°12′ в. д. Далее необходимо знать позицию планеты в звездной системе, и текущее время. Используя эти данные, мы можем рассчитать координаты здания на поверхности относительно центра планеты (с учетом текущего ее вращения). И далее преобразовать в координаты относительно игровой камеры. Только после этого здание можно отрисовать. Как можно понять из описания, координаты здания будут разными и зависеть от текущего времени. В результате количество расчетов, которые можно провести заранее сильно уменьшается. Все это придется считать в рантайме, отбирая ресурсы у геймплея или рендеринга.
Также перестают работать любые системы, которые полагаются на фиксированное направление вверх. Например, в Unity в последних версиях добавили красивые объемные облака и океан. Но их невозможно использовать в космических симуляторах, так как из-за упрощенных внутренних вычислений они не рассчитаны на динамическую систему координат.
Floating origin
Чем дальше объект находится от центра координат, тем больше ошибок накапливается во время вычислений, тем все больше артефактов появится на финальном кадре. Все это происходит из-за ограниченной точности чисел с плавающей запятой. Есть отличное видео демонстрирующее эту проблему:
Артефакты уже начинают проявляться на расстоянии в 10 км от центра координат. Масштабы космоса и размеры планет в десятки тысяч раз превышают это значение. Чтобы рендеринг и другие системы не ломались, необходимо, чтобы камера всегда находилась недалеко от начала координат. Грубо говоря, как только персонаж игрока отдаляется от центра на 10 км, необходимо сдвинуть персонажа и весь мир вокруг него на 10 км назад. Из-за того, что смещается сразу все, игрок ничего не заметит. Но это добавляет вычислений и отсекает возможность использовать еще одну пачку систем, которые в своей работе не рассчитаны на это.
И много чего еще
Статья уже получается большой, поэтому я вскользь упомяну, что нелишним будут орбитальные механики, параллельная симуляция физики в нескольких мирах, хранение большинства данных в числах двойной точности, реализация сферического океана, процедурное текстурирование и ландшафт. Все эти системы желательно иметь в наличии, но в том или ином виде без этого можно обойтись, в зависимости от задачи.
Цена разработки
Движок Unity, на котором я работаю, в принципе не рассчитан на большие миры и космические симуляторы. Все что в нем имеется из описанного, это только сферическая атмосфера, которая появилась там в 2020 году. Все остальное пришлось реализовывать самостоятельно. Разработка всех основных описанных систем заняла примерно год фулл тайма работы в одиночку.
Так что там со Старфилдом
Можно ли было реализовать бесшовную посадку из космоса на поверхность планеты на движке Тодда Говарда? При наличии стриминга ресурсов, уверен, что да. Даже если у них отсутствует стриминг, его имплементация командной разработчиков не заняла бы много времени. В профессионализме и компетенции разработчиков, работающих над Старфилдом, я тоже не сомневаюсь, несмотря на все проблемы и баги, которые есть у этой игры.
Но есть одно но.
Bethesda активно переиспользует наработанные за многие годы игровые системы. Как отмечают многие, Старфилд построен по той же формуле, что и Фаллаут, а Фаллаут по тем же лекалам, что и серия свитков. Всем этим играм достаточно плоской сцены с фиксированными координатами и кучей заранее рассчитанных данных. Со всем этим гораздо проще работать, расставлять постройки, двигать персонажей и раскидывать лут. И весь код, который был написан за многие годы, заточен именно под это. Добавление бесшовного перехода потребовало бы совершенного другого подхода к построению игрового мира, новый набор инструментов разработки, а также примерно полное переписывания всех систем, которые готовы и использовались ранее. Судя по всему, Тодд и его команда не были готовы пойти на такое.
Однако, я считаю, что даже при текущем подходе к построению мира, переходы между сценами можно было бы сделать элегантнее и без гигантских затрат, создав иллюзию бесшовного мира.
Эта статья не ставит перед собой целью защищать или осуждать Старфилд. Я надеюсь у тех, кто прочитал ее до конца, прибавилась немного знаний о рассматриваемом предмете, что позволит более аргументированно отстаивать свою позицию в спорах и комментариях на просторах этого сайта.
Спонсор этой статьи – игра «Rocket Science», доступная в Стиме. Спасибо за внимание.
