Phase Of Horizon | HollowEngine

Получается ещё один небольшой юбилей ✨

Для тех кто не знает, я 5 месяцев назад на скорую руку сделал аддон для FTB Quests добавляющий всякие мелочи, с тех пор в нём появилось ещё несколько фич:

🏎 Поддержка анимированных картинок APNG со стримингом. (т.е. это своего рода декодер в реальном времени, который не загружает всё сразу в память, а обрабатывает 1-2 кадра в реальном времени)
✨ Шейдерные фоны для разных вкладок в квестах.
🌐 Интеграция с модом EMI. (как JEI, но более гибкий и удобный)
💡 Ну и по мелочи, всякие анимации иконок и форм.

В общем, шутка, которая зашла слишком далеко 💻

🛞 Еженедельный девлог №5 | Я добавил движок в изолятор

📊 Статистика: 8 коммитов , ~8500 добавлений, ~6000 удалений 🔝

На этой неделе я закрыл очень объёмную и болезненную задачу - полностью вынес и изолировал HollowEngine со всеми его зависимостями в отдельный ClassLoader. А это целых 56 миксинов и ещё около 10 ASM-трансформеров в Kool 🦾 (потому что на изолированные классы миксины не действуют)
Основная причина - совместимость с другими модами. Движок использует несколько десятков различных библиотек, причём сложность в том, что если 2 мода используют одинаковые библиотеки разных версий, то Forge крашнется даже без каких либо логов. Из-за этого мод долгое время был не совместим с популярным модом Kotlin For Forge и для его работы нужно было ставить специальный патчер, который к тому же запускался не на всех JVM. Теперь же такой проблемы чисто технически не будет, поскольку ни Forge, ни другие моды просто не смогут найти классы движка 🤯

Ну и у такого подхода есть свои плюсы и минусы, если коротко:

➕ Плюсы

- Нет и не может быть конфликтов библиотек.
- Хорошая основа для обновления движка без перезапуска игры (что важно мне для разработки). То есть в будущем мне не придётся перезапускать игру при добавлении нового интерфейса / фичи.
- Возможность запускать мод из одного jar на любом загрузчике, и Forge, и Fabric в одном jar. (Пока не доступно, но теперь это вполне возможно без ущерба производительности и размеру файла)

❌Минусы

- Нет возможности создать внешние патчи или миксины, чтобы изменить код движка.
- Сложно писать аддоны, пока не появится официальная их поддержка, поскольку обычный мод просто не увидит классы движка.
- Больше мороки с передачей данных между игрой и движком. Нужно создавать мосты для передачи данных между ClassLoader'ами

В общем, задачка не из лёгких, и сложностей она явно добавит, но думаю ради дальней совместимости и надёжности шаг необходимый, тем более для поддержки нескольких версий и модлоадеров 🚀
На текущий момент я проверял, мод запускается на Fabric и Forge, но безусловно, среди тех изменённых 8к строчек кода могли появиться новые баги 👀

Ну а пока, я готовлю ещё одну мощную систему, которая вероятно выйдет на следующей неделе ⭐️
А вместе с ней будет и выпуск мода на CurseForge ⚒️ и Modrinth ⛏️

Вот пока что пара скриншотов с тестовой версии. Блоки для компонентов генерируются автоматически, так что пока что выглядит так себе, тут нужно будет ещё полировать генератор 🙃

P.S. новый логотип откладывается на некоторый срок, когда появится время и возможности

📓 Еженедельный девлог №4 | Интеграция ECS с блоками кода и начало скриптинга

📊 Статистика: ~10 коммитов, ~3000 строчек кода

На этой неделе я по большей части доводил до ума систему сборки HollowEngine Loom и к сожалению пришёл к выводу, что идея оказалась провальная из-за сложности изменениями generic-функций и классов в JVM. В подробности вдаваться не буду, всё равно кроме 1.5 калеки тут никто этого не поймёт 🥲 Но суть в том, что я откатился обратно до Stonecutter.
Так что теперь я вернулся к прошлым задачам.

🎡 Компоненты и блоки кода

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

📜 Скрипты

Я начал постепенно реализовывать функционал связанный с скриптингом и пока-что это `.reload.kts` скрипты. Это самый базовый вид скрипта, который будет использоваться во многих системах и возможностях. Как следует из названия он будет автоматически запускаться при перезагрузке серверных ресурсов при запуске сервера или команде `/reload`. На текущий момент он уже позволяет добавлять / удалять рецепты для верстака и печек, но в будущем тут будет и логика связанная с обработкой событий, создание собственных компонентов, пользовательские системы и другая логика.

Пока я вижу, что дизайн и удобство использования нуждаются в доработке, так что приоритет пока меняю на них. В связи с этим на следующей неделе будет дополнительно 3 поста на эту тему с демонстрациями и небольшой документацией. Пока что полноценную документацию вводить в игру не буду, поскольку на это нужно больше времени, но, пожалуй, хватит и простых .md файлов на GitHub 🫠

Такс, небольшой внеплановый пост)

Некоторые уже успели пожаловаться на новое лого, так что почему бы тогда не обсудить варианты? 🙃
В текущем варианте в самом деле со светом как будто небольшой перебор, да и некоторым сама концепция 3D логотипа не нравится, так что вот пока несколько основных концептов. В игре безусловно 2D вариант смотрится куда приятнее, но как по мне, для обложки группы / сервера это как-то простовато, нет?

P.S. Ниже скоро появится опрос

Channel photo updated

Ну и вот пара скриншотов, продвинутой системы автодополнения в новом HollowEngine Loom 🤯

В общем в последнее время я ушёл прямо в какие-то дебри рендеринга и задачи далёкие от самого движка 🫠
Пожалуй пора возвращаться к функциональной части, интересно было бы услышать, что Вы сейчас ждёте от движка в первую очередь? Скриптинг на Kotlin? Документацию? Расширенную систему компонентов?

📓 Еженедельный девлог №3 | Новая система сборки

📊 Статистика: ~18 коммитов.

На этой неделе я по большей части занимался другими проектами не связанными (или связанными косвенно) с движком.
Первая и, пожалуй, самая важная работа была посвящена кастомным инструментам сборки, а именно - начало миграции со Stonecutter на HollowEngine Loom. Вторую часть я потратил на практику рендеринга освещения.

🆚 HollowEngine Loom

Как многие помнят, движок сейчас работает на Forge и Fabric для 1.20.1, а также есть секретная версия на Fabric 1.21.1 👀
Это возможно благодаря такому инструменту, как Stonecutter. Это что-то вроде препроцессора, который запускает сборку мода на разные версии и модлоадеры частично комментируя строчки кода в зависимости от определённых параметров. Но у него есть некоторые существенные недостатки, которые сильно раздражают при разработке, поэтому я сделал HollowEngine Loom - форк Architectury Loom, который позволяет писать под несколько модлоадеров в разных подпроектах. Я же, в свою очередь, расширил его функционал, чтобы он позволял писать сразу под несколько версий и сразу показывал в IDE методы и переменные со всех версий игры и сразу проверял, чтобы при компиляции не было такого, что на одной версии метод есть, а на другой - нет.
Ну, это если обобщённо, там довольно много удобств в сравнении с подходами использующими препроцессоры:
• Форматирование кода и сортировка импортов не ломает инструкции препроцессора в отличии от того же Stonecutter
• Анализируется общий jar со всех версий + специфические проверки веток, тем самым Вы можете сразу видеть какие проблемы возникают и на каких версиях!
• Код выглядит чисто, а не как свалка закомментированного кода, который можно легко поломать или допустить опечатку во время отладки.
• Автодополнения работают сразу для всех версий, а также я немного их доработал, чтобы явно видеть, на каких версиях они доступны.

В общем интересная штука, про которую я подробнее писал на своём Boosty, так что заглядывайте, если интересно 🙃

На текущий момент эта система готова где-то на 90% и я уже постепенно начал переносить на неё движок, так что уже со следующего билда мод начнёт выходить сразу на 2 версии: 1.20.1 и 1.21.1!

💡Источники света

После того как я осилил инстансинг для любых шейдерпаков, я захотел подробнее изучить тему связанную с цветным освещением, точечным и прожекторным (конусообразным) светом, объёмным туманом и т.п. И знаете, мне уже достаточно навыков, чтобы добавить это в ближайшие недели 🤔
Но проблема в том, что каждый шейдерпак использует свои подходы к рендерингу и освещению, так что чтобы внедрить туда свой всё же придётся модифицировать каждый уникальный шейдерпак. То есть я не могу провернуть тот же трюк, что с инстансингом, когда я делаю какую-то магию и фича начинает работать сразу на всех шейдерпаках. Но по крайней мере я бы мог сделать поддержку самых популярных шейдерпаков, вроде Complementary или BSL. Но пока сомневаюсь, что подобная возможность кому-либо будет нужна в ближайшее, так что вероятно отложу её в долгий ящик.

Выглядит инстансинг примерно так 🙃

📓 Еженедельный девлог №2 | Переменные, локализация и instancing

📊 Статистика: 10 коммитов, 5 356 добавлений и 3 759 удалений.

За последние 7 дней в HollowEngine я работал по следующим задачам: система переменных в блоках кода, подход к локализации, сохранение компонентов и новый рендер моделей через инстансинг.

🧠 Блоки кода и переменные

Я немного доработал систему переменных в блоках кода. Появились новые виды переменных, из-за чего сами скрипты стали заметно гибче: теперь можно аккуратнее работать с данными текущего контекста, сервера и сущностей, ранее были доступны только переменные одной ветки. Но всё ещё продолжается доработка NBT-переменных сущностей.

Параллельно я подчистил валидацию и диагностику графов этих самых блоков. При наличии ошибок, они будут появляться в `hollowengine/logs/codeblocks-validation.log`.

Из видимых изменений:
• появились новые variable blocks и scoped/context-переменные
• улучшена работа output-переменных событий
• доработан анализ графа и сообщений об ошибках
• поправлены проблемы с восстановлением скриптов после сбоев
• добавлены команды и тесты для проверки новой логики

🌍 Новая система локализации

Отдельно переработал lang-систему. Вместо двух огромных файлов en_us.json и ru_ru.json на 1500 строк, локализация теперь разложена по небольшим JSON-файлам по категориям: GUI, code blocks, IDE, теги, команды и так далее.

Так что теперь работать с переводами движка куда проще, одно дело, когда у тебя в моде пара десятков предметов, блоков и несколько механизмов с интерфейсами, а другое, когда у тебя одних только блоков кода штук 150... При этом, всё совместимо с текущей системой переводов Minecraft, поскольку работает через Gradle-скрипт для объединения нескольких lang-файлов, так что бы они собирались в один общий файл без повторов.

🧱 Компоненты и сохранение сущностей

Ещё одно важное исправление - ленивая инициализация ECS-сущностей. Теперь в ECS добавляются только сущности у которых уже есть какие либо компоненты, т.е. на больших сборках нагрузка станет меньше, а обработка нпс - быстрее.

🎨 Инстансинг и поддержка Iris

Самая большая задача недели - начало нормальной поддержки инстансинга для моделей.

Сейчас в рендере происходит сбор одинаковых примитивов, чтобы потом вместо того, чтобы по одному их кидать через `Java -> JNI -> OpenGL -> GPU` сразу отправить большую пачку из десятков, сотен, а то и тысяч моделей. Не стоит пока ждать огромного прироста производительности, посколькe BlockBench-модели состоят из большого количества кубов, каждый из которых даже через инстансинг производительность особо не повысит в сравнении с уже существующим механизмом батчинга, а одновременно обрабатывать и скиннинг, и инстансинг движок пока не умеет. Но в случае с большим количеством статичных высоко полигональных моделей прирост производительности может быть в 10, а то и в 100 раз лучше, чем то, что было раньше.

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

P.S. на Oculus тоже должно работать, но я не проверял, если порт кривой, значит работать не будет, если порт надёжный - работать будет 🙃

🖼 Ещё по мелочи

Помимо крупных задач, был исправлен баг с изображениями при перезагрузке ресурсов в Kool UI.

На этом за неделю всё. Получилось меньше фич, чем в прошлом девлоге, но зато эта неделя хорошо повлияла на производительность и стабильность

Ну и вот напоследок несколько скриншотов с движка 🙃