Что же можно сказать про сами посты? На самом деле много довольно интересных наблюдений. Были и свои сильные стороны и слабые. Как человеку, который обычно работает по 18 часов в сутки, а потом неделю прокрастинирует, переключиться на новый режим было довольно тяжело и болезненно. Было довольно много филлерных постов, когда за день я особо ничего не успел из-за учёбы, коммерческих заказов или простой усталости. Но на удивление, спустя время от этого появились и свои преимущества, например, у меня полностью пропала прокрастинация/лень/выгораний/впишите_нужное. Пройдя самые неприятные монологи с самим собой, почему я не могу просто взять и забросить это всё на условном 30 дне, стало куда проще работать, может сформировалась привычка, может быть просто подтянулась дисциплина - наверняка сказать не могу. Но оно явно в этом может помочь, даже если у вас недостаток силы воли, особенно если есть аудитория, перед которой вы дали обещание 🙃
Также из необычных эффектов... Наверное многие кому уже за 20, замечали, что с каждым годом, время начинает лететь всё быстрее. Когда вроде бы прошёл год, а ты не можешь вспомнить, чего стоящего ты сделал в последнее время. - В моём случае время будто бы остановилось, даже не пролистывая посты или коммиты, я куда лучше помню чем я занимался и что сделал. Наверное, это примерно как с ведением дневника, только в этом случае это дневник, куда ты обязался вписывать не просто, как ты провёл день, а поставил себе цель "достичь хоть чего-то каждый день")

Буду ли я и дальше продолжать выпускать посты или устал ли я от ежедневных постов? Возьму ли я отпуск или продолжу работать и дальше?
На самом деле я бы вполне уверенно мог бы продолжать выпускать ежедневные посты и дальше, но уже не вижу в этом необходимости. Изначально я это всё затеял, чтобы дойти до релиза, сейчас по сути чего я хотел добился, остались лишь мелкие доработки и багфиксы. Так что я думаю ежедневные посты тут скорее навредят, поскольку занимают они довольно много времени, а писать в конце дня пост из разряда "Сегодня я весь день просидел с дебаггером и, наконец, нашёл, почему вылетает, если одновременно нажать ctrl+z и shift+a в полнолуние с включенным месседжером [ДАННЫЕ ЗАМЕДЛЕНЫ] без интернета". Если, когда я ранее занимался преимущественно добавлением нового контента, я мог просто показать пару скринов с этими фичами, то показывать вам список исправленных багов смысла особо нет, скорее это просто лишняя трата времени или создание постов из воздуха.
Так что теперь я думаю перейду на еженедельные девлоги, думаю выйдет куда более интересно, чем просто пара скриншотов и ролик снятый одним дублем 🫤
Да и не исключено, что иногда будут и внеплановые посты, если будет о чём рассказать. Я вот недавно прошёл 3 и 4 главы Deltarune, может быть сделать небольшой обзор?)

Ну а на этом у меня на сегодня всё, следующий пост будет либо 1, либо 8 марта, посмотрим ближе к концу недели 😶‍🌫️

Это конечно не ежедневный девлог, но всё-таки 👀

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

📊 Статистика: 40 коммитов, 12 557 добавлений и 4 488 удалений.

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

Раньше была лишь возможность целиком запустить файл командой и тогда он начинал отслеживать свои триггеры. Также внутри одного файла все переменные были общими, например, если Вы поставите триггер "При сообщении игрока в чат", то скрипт будет срабатывать каждый раз вне зависимости от игрока или текста и перезаписывать старые переменные, даже если прошлый скрипт ещё не завершился.

Теперь система работает иначе.

⚙️ Каждый файл может быть активен или не активен, это влияет на то, будут ли в нём срабатывать триггеры.

Каждый триггер теперь запускает новую ветку (последовательность блоков кода) и эта ветка напрямую связана с вызвавшим триггер.
Например:

⁃ в случае события чата - это игрок
⁃ в случае запуска игры - это сервер

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

⁃ отменить старую и начать новую ветку
⁃ отменить новую и продолжить старую ветку
⁃ добавить новую ветку **в очередь**, сразу после старой

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

🧩 Появилась система output'ов.
Если раньше данные можно было только передать в блок, то теперь можно и наоборот - записать данные из блока в переменные.

Например, при выводе в чат можно сразу записать:

⁃ сущность игрока
⁃ его сообщение
⁃ имя

Это позволяет писать свои собственные фильтры и механики, а не только делать набор стандартных фраз, как в Legacy.

В целом, это все глобальные изменения в рамках блоков кода, остальное уже менее значимо:

• Все имена блоков кода вынесены в файлы перевода - теперь они на 700+ строк
• Реализован поиск блоков на их панели
• Улучшено отображение блоков в свёрнутом виде
• Доработана обработка ошибок - при удалении блоков или повреждении их структуры в одном из обновлений поломается лишь один блок, а не весь файл

🛠 Новые инструменты

Я немного поработал над динамическим добавлением предметов.

Без перезапуска игры и сервера, прямо в мире одной командой можно обновить префабы связанные с предметами и они сразу появляются в игре!

Но пока что эта система сильно упрощена в сравнении с тем, какой она должна быть:

• нет динамического удаления таких предметов из всех инвентарей
• нет нормальной синхронизации с клиентом
• нет динамического добавления моделей без полной перезагрузки ресурсов
• нет возможности добавить явный функционал вроде Меча/Кирки

Короче говоря, это пока что минимальный Proof-Of-Concept, что пропатчить регистраторы и динамически добавлять новые предметы, блоки и сущности - возможно.

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

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

🧱 После этого была обновлена следующая крупная задача - система компонентов и префабов.

В редакторе префабов модель теперь отображается только если есть соответствующий компонент, без стандартной заглушки.

Сохранение компонентов стало централизованным:

сущности и компоненты теперь могут универсально сохраняться в
• NBT - для сохранения в сущности
• YML - для сохранения префабов
• JSON - для метаданных в редакторе префабов

Также появилась возможность скрывать компоненты из редактора, чтобы Вам не показывался мой мусор, на который вам смотреть нельзя 🙂

🤖 Были добавлены новые AI-компоненты и связанные с ними системы:

• LookAt - всё время смотрит на сущность или блок указанный в компоненте
• MoveTo - всё время идёт к сущности или блоку указанному в компоненте
• Patrool - всё время ходит по указанным точкам в компоненте
• AttackTarget - атакует сущность указанную в компоненте

🎭 Система моделей тоже получила несколько доработок:

• Больше не вылетает и не пропадает модель при перезагрузке ресурсов
• В контроллере анимаций теперь можно настроить повороты тела и головы
• Исправлен контекст самого скрипта - теперь он корректно обрабатывает ошибки, а не ругается на всё подряд

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

📌 Ну и по мелочи:

• Поправлены несколько виджетов Markdown
• Закрыты часть старых TODO
• Улучшен файловый менеджер в scripting UI
• Мод обновлён до Forge 47.4.13
• Прошёл один точечный эксперимент с `ServerGamePacketListenerImplMixin` и был быстро откатан отдельным revert-коммитом - он чинил мод на ядре Mohist и ломал его на всех остальных ядрах 😃
• Частично исправлены дёрганья тела при повороте NPC

На этом у меня всё, получается сжал кучу ежедневных девлогов в один, оказалось, контента меньше не стало, на картинки даже места не хватило, а премиума у меня нет 🙃

📓 Еженедельный девлог №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.

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

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

📓 Еженедельный девлог №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. Но пока сомневаюсь, что подобная возможность кому-либо будет нужна в ближайшее, так что вероятно отложу её в долгий ящик.