teedeezet
boosty
Итоги месяца: ноябрь 2024
🕑 Added 2024-12-01 15:58:56 +0000 UTCПривет всем спонсорам!
В ноябре дел у меня было много. Нужно было как можно больше заниматься роликом (и да, он всё ещё в работе), но не всё так просто.
Для создания сцен и футажей мне приходилось прямо на ходу разрабатывать и улучшать механики Grim Wild. Из-за таких резких нововведений сцены в видео будут выглядеть по-разному, но, к сожалению, это единственный способ закончить работу над роликом в 2024 году.
Для создания сцен и футажей мне приходилось прямо на ходу разрабатывать и улучшать механики Grim Wild. Из-за таких резких нововведений сцены в видео будут выглядеть по-разному, но, к сожалению, это единственный способ закончить работу над роликом в 2024 году.
[Grim Wild]
Поверхности: тени
С появлением в игре полноценной симуляции жидкостей возникла новая проблема. Проще всего показать её визуально:
Итак, перед вами один чанк игрового пространства, имеющий рельеф и перепады высот. Допустим, вы хотите построить здесь свою базу, причём в том месте, где её не затопит проливными дождями. А как вам понять, где именно будет застаиваться вода? Можно, конечно, включить режим просмотра мировой высоты (механика Оверлеев будет скоро реализована), но делать так постоянно - очень неудобно.
Решение тут скорее вынужденное, чем добровольное. Я обязан отрисовывать рельеф прямо на поверхностях. Вариантов сделать это есть несколько, но я выбрал такой:
Теперь ваш мозг может легко построить трёхмерную модель уровня и мгновенно понять, где здесь низина, а где возвышенность.
Итоги месяца: ноябрь 2024
Сцена из седьмого ролика. Детали симуляции жидкостей я объясню в следующей главе.Издалека уровень выглядит красиво, все проблемы проявляются только вблизи:
С одной стороны, тени значительно улучшили визуальный стиль игры. Они даже убрали так ненавидимые мной повторы текстур (хотя и без теней они были не такими явными из-за использования Texture Bombing).
Но с другой, они могли сделать графику игры уж слишком "реалистичной". О том, как это будет выглядеть в реальных "боевых условиях", я пока сам не знаю. Я использовал их только для футажей ролика, а полноценно встроены в игру они будут только в декабре.
GPU Симуляции
Самая приоритетная работа в ноябре - это GPU симуляции, техническую демонстрацию которых я показал в прошлый раз.
Во-первых, у воды появилась текстура, вы видели её выше. Внешний вид каждой клетки зависит от количества на ней воды. Глубина даёт сдвиг цветового оттенка и текстуры (UV), из-за чего все неровности сразу явно видны игроку.
Во-вторых, я продолжил эксперименты со скоростью и направлением волн, которые должны постепенно гаситься с учётом параметра вязкости (цитата из ролика). Как и обещал вам ранее, показываю результат:
Итоги месяца: ноябрь 2024
Текстура воды конкретно на этом футаже слишком размытая (на ролике из прошлой главы она новее. Там она уже резкая, а не мыльная).Что мы здесь видим? Во-первых, то, как торнадо выталкивает из себя воду, создавая те самые волны.
Но главное даже не это. Симуляции в игре привязаны к короткому тику, который сейчас выполняется 10 раз в секунду (раз в 0.1с). Скоро, возможно, он вообще будет снижен до 5 раз в секунду (раз в 0.2с).
Оставлять такой неприятный визуал я не стал. Всё-таки я стремлюсь к тому, чтобы всё в игре выглядело плавно и мягко. После изменения способа отрисовки всё стало выглядеть как надо:
Итоги месяца: ноябрь 2024
Со стороны "бэкэнда" изменений нет, разница здесь только в том, что именно рисуется на экране. В первом случае мы всегда берём за основу самую свежую информацию из последнего кадра симуляции (который мог случиться уже давно). Во втором же мы плавно переводим значения от предпоследнего кадра к последнему (выполняем линейную интерполяцию). Вот и вся магия.
***
Также в ноябре я работал над симуляцией тепла и воздуха.
Их принцип на все 100% схож с жидкостями: значения (температуры / воздуха) там пытаются равномерно распространиться по уровню, и мы при этом учитываем параметры (теплопроводности / воздухопроницаемости) у каждой клетки. Влиять на эти параметры могут только стены и их материалы.
Температура в игре просчитывается в Кельвинах (K). На интерфейс она будет выводиться с учётом конвертации в выбранную игроком единицу (°C/°F).
А воздух (как и жидкости) просчитывается в литрах, раз уж об этом зашла речь.
Проблемы симуляций и ответы на вопросы
Кратко о проблемах:
• В системе жидкостей есть пока только вода (я уже писал об этом, и с тех пор новых идей для реализации гетерогенных жидкостей не прибавилось)
• Скорость и волны сейчас создаются только при отдаче значений из клетки. Для воды и воздуха это нормально, а вот с температурой возникла сложность. Я могу создать волну горячего воздуха (которая будет перемещать тепло из себя в соседние клетки с какой-то скоростью). А вот волну холодного (относительно среды) воздуха - уже нет, потому что холодная клетка будет принимать в себя значения более горячих соседей.
• Температура и воздух на данный момент полностью изолированы друг от друга и никак не взаимодействуют. Это значит, что сейчас температура может существовать и перемещаться без проблем даже в вакууме. Хотелось бы в будущем это исправить.
Ответы на вопросы (из Дискорда и из моей головы)
– Что именно такое "воздух" в симуляциях? Это кислород?
– Что именно такое "воздух" в симуляциях? Это кислород?
В игре не будет деления воздуха на газы (кислород, CO2, дым...). Получается, что воздух - это сразу вся атмосфера. Растения этот воздух просто выделяют, а пешки - просто потребляют (то есть безвозвратно уничтожают, а не конвертируют в CO2).
– Можно ли будет создавать новые симуляции в модах?
– Можно ли будет создавать новые симуляции в модах?
Да, но их поведение меняться не сможет. То есть любая симуляция, даже добавленная модом, это просто распределение каких-то значений по уровню, где у каждой клетки есть свой параметр сопротивления (вот как раз его менять можно).
– Будет ли вода замерзать при минусовых температурах?
Нет, я отказался от такой идеи. Это создавало бы огромное количество дополнительных вычислений и передачи данных между CPU и GPU (а шина между ними всё-таки имеет ограниченную пропускную способность).
Нет, я отказался от такой идеи. Это создавало бы огромное количество дополнительных вычислений и передачи данных между CPU и GPU (а шина между ними всё-таки имеет ограниченную пропускную способность).
– Насколько симуляции в игре корректны с точки зрения физики?
На 0%. Я был бы рад сделать более реалистичные вычисления, но мне мешает специфика игры (например, тот факт, что симуляции непрерывно соединяются со всеми соседними чанками) и тот факт, что это далеко не основная механика игры.
– Будет ли температура учитывать мировую высоту клеток, чтобы в низинах было холоднее, чем на возвышенностях?
Нет, воздух и температура учитывают пока только стены. Изменится ли это, сказать не могу.
На 0%. Я был бы рад сделать более реалистичные вычисления, но мне мешает специфика игры (например, тот факт, что симуляции непрерывно соединяются со всеми соседними чанками) и тот факт, что это далеко не основная механика игры.
– Будет ли температура учитывать мировую высоту клеток, чтобы в низинах было холоднее, чем на возвышенностях?
Нет, воздух и температура учитывают пока только стены. Изменится ли это, сказать не могу.
– GPU симуляции будут существовать только на игровых уровнях? Или на всей планете тоже?
Планируется, что вся вода, температура и воздух на планете - это тоже симуляции. Единственное, что пока у меня вызывает проблемы - это жидкости (соединить их с планетой не так-то просто).
Планируется, что вся вода, температура и воздух на планете - это тоже симуляции. Единственное, что пока у меня вызывает проблемы - это жидкости (соединить их с планетой не так-то просто).
Моды: продолжение работы
Появление в игре полноценных модов становится всё ближе. В результатах работы за октябрь я писал, что занимался тогда виртуальными и сессионными ассетами, а также внедрением Steam Workshop.
Разработка системы модов в ноябре продолжается, причём теперь она идёт "по всем направлениям": начиная от самого фундаментального и заканчивая тем, с чем взаимодействует конечный пользователь (мододел).
На схеме вы можете видеть элемент "Custom Translation" - это моя собственная система для переводов игры и модов на разные языки. Да, мне пришлось писать её самому, потому что готовые решения движка мне совсем не подходят.
Своя система переводов и локализации
Встроенная система локализации Unreal Engine идеально подходит для AAA игр, где за все возможные переводы отвечают сами разработчики. Модифицировать локализацию там можно только через редактор, что полностью противоречит нуждам GW.
Об этой проблеме я знал давно, так что уже спроектировал подходящую для меня механику L10N и I18N (Localization и Internalization). В ноябре я начал её реализовывать.
Я назвал новый модуль "ETranslation" (Envision Translation), и он находится во фреймворке (то есть будет повторно использован в будущем).
Вообще, нейминг классов и модулей в коде у меня довольно простой:
Префикс E означает Envision (механики из фреймворка: ESaveGameSystem, EDebugging, ETranslation...).
Префикс G означает либо Grim, либо просто Game (я делал так на случай переименования GW во что-то совершенно другое). Например, GAssetManager, GGameMode, GPlayerPawn - это всё классы, созданные именно для Grim Wild (не могут быть напрямую использованы в других играх).
Моды с помощью ETranslation могут переводить текстовые элементы базовой игры и других модов. Это значит, что сообщество сможет создавать свои собственные локализации игры.
Префикс E означает Envision (механики из фреймворка: ESaveGameSystem, EDebugging, ETranslation...).
Префикс G означает либо Grim, либо просто Game (я делал так на случай переименования GW во что-то совершенно другое). Например, GAssetManager, GGameMode, GPlayerPawn - это всё классы, созданные именно для Grim Wild (не могут быть напрямую использованы в других играх).
Моды с помощью ETranslation могут переводить текстовые элементы базовой игры и других модов. Это значит, что сообщество сможет создавать свои собственные локализации игры.
Пример: японец-энтузиаст решил перевести базовую игру на японский язык (который, по понятным причинам, не будет присутствовать в ГВ по умолчанию). Для этого ему нужно создать новый мод, в котором он добавит новый язык: "ja-JP", переведя каждый текстовый блок из базовой игры на свой родной язык.
Он заливает свой мод в Steam Workshop, а когда другие японоговорящие игроки его скачивают и включают, в настройках появляется новая позиция: "Japanese" (Unreal Engine хранит в себе все названия языков по их ID)
Пример 2: испанец-энтузист решил перевести "мод на кастомизацию могил" на испанский язык. Для этого ему нужно создать новый мод, в зависимостях которого указать "мод на кастомизацию могил". А внутри просто создать значения для всех ID текстовых элементов из родительского мода.
Он заливает свой мод в Steam Workshop, а когда другие японоговорящие игроки его скачивают и включают, в настройках появляется новая позиция: "Japanese" (Unreal Engine хранит в себе все названия языков по их ID)
Пример 2: испанец-энтузист решил перевести "мод на кастомизацию могил" на испанский язык. Для этого ему нужно создать новый мод, в зависимостях которого указать "мод на кастомизацию могил". А внутри просто создать значения для всех ID текстовых элементов из родительского мода.
Если игрок-испанец имеет фанатский перевод базовой игры, то и наш переведённый мод автоматически выберет его же.
А что делать, если перевод мода есть, а такого языка у базовой игры нет? В таком случае я ничего с этим поделать не смогу, и игроку придётся вручную выбрать кастомный язык для мода.
Пример 3: энтузиаст решает перевести игру на эльфийский язык. Да, и это тоже возможно. Для этого ему необходимо сделать те же шаги, что в примере 1, просто вместо реального культурного кода указать нереальный. Тогда вместо названия языка в настройках просто отобразится его Id.
Изменения в механике открытого мира
Прошлый пост оказался слишком большим (UPD: как и этот тоже...), поэтому я перенёс разговоры о важном изменении в системе Level-Agnostic (L-A) сюда.
Краткая справка про L-A:
• Игровое пространство состоит из "чанков" - областей размером 64x64 клетки.
• Каждый чанк полностью независим от других, вся внутренняя игровая логика происходит именно на нём.
• Чанки можно стыковать друг с другом, формируя большие уровни.
• 1 чанк = 1 клетка планеты. То есть уровень размером 5x5 чанков занимает те же 5x5 клеток планеты (а не всегда фиксировано одну).
• Игровое пространство состоит из "чанков" - областей размером 64x64 клетки.
• Каждый чанк полностью независим от других, вся внутренняя игровая логика происходит именно на нём.
• Чанки можно стыковать друг с другом, формируя большие уровни.
• 1 чанк = 1 клетка планеты. То есть уровень размером 5x5 чанков занимает те же 5x5 клеток планеты (а не всегда фиксировано одну).
Всё это подразумевает, что расширить игровое пространство, сгенерировав и пристыковав к уровню ещё несколько чанков, можно прямо во время игры.
Когда я спроектировал механику L-A, то понял, что на основе этого можно сделать открытый мир. Достаточно просто подгружать чанки в радиусе N от каждого колониста игрока, и границ бесшовного мира никогда не будет видно.
Но я на всякий случай перестраховался и спроектировал второй, "консервативный сценарий". Все механики "открытого мира" в нём остаются, просто новые чанки генерируются не от присутствия рядом колонистов, а только по явному указанию игрока.
Реализация основного плана шла успешно на протяжении всего лета. Правда, на фоне постепенно накапливались минусы и мелкие проблемы, которые с наступлением осени всё-таки смогли перевесить все его преимущества.
Минусы реализации "полностью открытого мира":
- Не все чанки нужны игроку. Допустим, он ведёт экспедицию в соседнее поселение. Зачем компьютеру тратить ресурсы на постоянную подгрузку новых чанков (и уничтожение старых), попадающихся в пути? С учётом того, что генерация должна происходить в реальном времени, наполнение чанков в таком случае было бы похоже на Minecraft (пустое и безжизненное).
- Неопределённое поведение пешек без чётких границ логики. Они могут произвольно уйти из зоны действия одних активностей, зайдя в зоны действия других. Представьте себе пешку, которая пошла за древесиной и вернулась только через 2 игровых дня. Или не вернулась совсем, потому что наткнулась на проходящий мимо отряд врагов. Конечно, это всё исправляется корректировкой поведения. Но я, честно говоря, таким заниматься не хочу.
- GPU симуляции обрабатываются в каждом чанке отдельно. То есть пришлось бы постоянно создавать и инициализировать, а потом удалять кучу данных в том числе на видеокарте, что, опять же, не так хорошо. Плюсы реализации "консервативного варианта":
+ Устранены все минусы, о которых я написал выше.
+ Если генерация чанков происходит только по требованию (и игрок готов подождать немного времени на загрузочном экране), их содержимое становится возможно сделать очень интересным и насыщенным. Можно тратить на проработку каждого чанка намного больше ресурсов ПК, и они будут казаться для игрока не такими скучными.
Игровой процесс с "консервативным вариантом"
TL;DR: Единственное различие между двумя вариантами - это агрессивность генерации новых чанков. В первом варианте они генерируются на лету, и мы даже не спрашиваем игрока о том, нужны ли они ему. Во втором варианте игрок сам делает запрос на генерацию и присоединение новых чанков.
• Игровое пространство изолировано, но игрок может расширять свою базу, присоединяя соседние клетки планеты по своему желанию.
• Структуры (точки интереса) занимают сразу много клеток планеты, особенно интересно это будет выглядеть для городов других фракций.
• Планета может содержать сложную генерацию даже вне точек интереса. Я планирую реализовать "модификаторы биомов" (насколько я понимаю, похожая механика есть в Minecraft), когда каждая область на планете имеет свои уникальные свойства (по сути, те же логические компоненты, модифицирующие события и генерацию).
Я признаю, что идея открытого мира оказалась неудачной. Я рад, что понял это довольно быстро, потратив на реализацию не так много времени.
[Публичная деятельность]
То, что новая серия ВСЁ ЕЩЁ делается, для вас сюрпризом не станет. Я повторяю эти слова уже много постов подряд, но конца и края моим страданиям не видно до сих пор.
Глава про GPU симуляции готова где-то на 50%. Самое сложное я уже сделал: футажи для воды с учётом многострадальной текстуры, визуальной отрисовки глубины, скорости у волн и теней от поверхностей.
Но меня всё ещё ждёт работа над сценами про тепло, воздух и... кучу других идей (радиация; звуки и шумы; бактерии и вирусы). Хорошо то, что основа под них уже полностью готова, мне просто надо сделать для сцен композицию из объектов и локаций.
***
Сценарий восьмой серии немного улучшился. Я решил вставить туда как минимум два фрагмента, описывающих принцип работы компьютера: один про различия CPU и GPU, а другой про глубину цвета.
Да, это те самые короткие видео из будущей рубрики "Простыми словами", которые выйдут и в виде самостоятельного контента.
То есть получается интереснейшая картина: мой будущий "пулемёт контента" имеет многоразовые пули, где одна сцена используется как самостоятельное видео на двух языках + является фрагментом полномасштабных роликов (тоже на двух языках)!
Планы на декабрь
1) Выпустить седьмой ролик (как бы мне хотелось успеть в срок!)
2) Выпустить обновление 0.4.2, протестировав остатки дел по системе отрисовки
3) Написать на Бусти открытый для всех пост: "Итоги года: 2024"
Спасибо за внимание!
Comments
teedeezet
<div ><div><span class="text">Danil, на днях уже выйдет для спонсоров!</span></div><div></div></div>
Danil
<div ><div><span class="text">Вау ,как всё круто идет .Продолжай в том же духе !Ждем очень новый ролик </span></div></div>
Gigores
<div ><div><span class="text">какой охеренный ураган !!!!</span></div><div></div></div>
