@urliveyn - сам сайт, документация;
@axelswamp - макет и дизайн;
@algorithmlx_today - деплой и домен.

✔️ Гибкая настройка всех элементов: размеры, цвета, форма, фильтры, вроде чёрно-белого или размытия, отступы и многое другое.
✔️ Удобная система анимаций: можно настроить переключение многих параметров при наведении курсора, кликах и других событиях.
✔️ Вращение и перспектива: компоненты можно наклонять по 3 осям, при этом нажатия тоже будут обрабатываться в 3D-пространстве
✔️ Классический xml+css подход с возможностью расширения: удобная настройка и стилизация компонентов. Не нужно отдельно настраивать стиль каждой кнопки, достаточно выдать ей тег (хотя если очень хочется, можно и каждую настроить 😂)
✔️ Полная интеграция с Minecraft: предметы, блоки, сущности - всё можно рендерить в гуишке.
🚫 Пока ещё нет динамического добавления новых элеметов, условно из тех же скриптов в духе того же React.
🚫 Пока ещё нет интеграции со скриптами и в целом открыть гуишку кроме как через предпросмотр нельзя.

val dialog = ui(
  <box id="dialog" layout="column" size="300px auto" padding="12px" gap="8px">
    <text value="Привет, игрок!" foreground="#FFFFFF" font-size="16px" />
    <button id="accept" background="#339933" onPressed='emit(struct { event: "accept" })'>Принять</button>
    <button id="cancel" background="#993333" onPressed='emit(struct { event: "cancel" })'>Отмена</button>
  </box>
)

dialog.showScreen(player)

val tag = struct {
    custom_name: {text:"Рандомный меч", color:"gold", bold:true},
    lore: [
        {text:"Это легендарное оружие найденное в каком-то прогнившем подвале", color:"dark_purple", italic:true}
    ],
    enchantments: {
        levels: {'minecraft:sharpness':5, 'minecraft:unbreaking':3}
    },
    unbreakable:{}
}
player.give("minecraft:diamond_sword", tag)

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

Зачем? - В перспективе это значит - больше кастомизации, свои темы, свои стили, более удобные и расширяемые редакторы, прямая интеграция с игрой (меньше багов), стабильная работа на AMD GPU. Меньше странных ограничений "Почему у меня одно окно выталкивает другое, а ещё почему нельзя менять порядок вкладок? - потому что фреймворк так работает, я это так просто не исправлю".

Katari был интересным экспериментом. Он решал часть проблем сюжетных скриптов: приостанавливаемые функции, ожидание событий, удобные сценарии, сохранение состояния и так далее. Но со временем стало понятно, что часть проблем закрыта только частично, а некоторые нормально закрыть невозможно:
➡️ Производительность и стабильность: Я и так уже перенёс порядка 30% функционала Kotlin и построил кучу внутренних утилит просто, чтобы сделать систему базово совместимой с Kotlin. В рамках интерпретатора добиться скорости компилируемых языков практически невозможно, с другой стороны для сюжетных скриптов оно и не нужно.
➡️ Нарративная часть языка имеет много ограничений, которые портят жизнь как мне, так и вам:
- Ограниченное количество типов данных / классов, плюс каждый из них должен иметь возможность сохраняться в файл, а также ручное добавление всех функций и переменных. То есть написать аддон добавляющий новые функции или интеграцию с определённым модом крайне сложно
- Полное сохранение скрипта в ходе его работы... Но, которое работает до первой мелкой правки. Из-за того, что вся ответственность за сохранение легла на язык, он сам размечает данные и сохраняет их. Разберём простой пример - Вы создали сервер с сюжетом, в версии 1.0 у нпс 3 варианта ответа и последствия. А потом выпустили обновление 1.1, где убрали последний вариант и заменили на другую ветку. **Все сохранения** теперь не работают и полностью сбрасывают скрипт на 5000+ строк, поскольку язык априори не может знать, что делать в случае если ветки из сохранения больше нет. И таких нюансов могут быть сотни и все их предусмотреть не возможно. Таким должны заниматься люди, а не язык программирования, сами создавать в скрипте пометки и размечать данные, мол "если была найдена ветка из прошлого сохранения, то заменить её на другую". Или если сохранения вообще не было, то самому с этим разбираться, как тут выкручиваться, а не доверять алгоритму :)

Поэтому я снова смотрю в сторону Kotlin-скриптинга.

У Kotlin 2.4 появилось и появляется много приятных вещей: исправили проблемы, о которых я писал ещё зимой, упростили синтаксис для списков, контекстные параметры и прочие штуки, из-за которых скрипты можно сделать заметно удобнее. При этом Kotlin остаётся компилируемым языком, а значит производительность ровно такая же, как и у всего написанного на Java. Ну и готовая проверка ошибок, лучше поддержка IDE и меньше неожиданностей при выполнении скриптов.
Пока что я не готов презентовать новую систему скриптинга, да и новая IDE ещё полируется, но как только всё будет готово, в релиз выйдет 2.3, скорее всего уже в этом месяце!

Хочется сделать что-то в духе Effekseer, Kool или Photon, но встроенное прямо в экосистему HollowEngine. То есть не просто "загрузить готовый эффект", а дать возможность удобно собирать эффекты внутри мода: частицы, эмиттеры, кривые, параметры, материалы/шейдеры, цвет, размер, скорость и другие параметры, а также привязка к объектам движка и полная настройка и интеграция со скриптингом, чего сложно добиться с внешней библиотекой, особенно нативной, вроде Effekseer. Ну и разумеется API для разработчиков модов, поскольку напомню, HollowEngine в ближайшее время можно будет использовать как библиотеку для ваших модов.

По удобству хочется ориентироваться скорее на Unity-подобный подход: чтобы эффект можно было собрать, сразу посмотреть, подкрутить параметры, сохранить и использовать без возни с отдельными программами или перезагрузкой ресурсов. Плюс, скриптинг может значительно расширить классические эффекты из разряда "запустил и забыл".

При этом важно не забыть про производительность. Эффекты могут быть красивыми, но если они начинают убивать FPS, пользы от них мало. Поэтому я хочу сразу закладывать нормальную архитектуру: батчинг, либо compute шейдеры, если они поддерживаются для тяжёлых эффектов и симуляций. В качестве примера можете посмотреть этот или этот, на самом деле рендерить миллионы партиклов способны даже встроенные видеокарты, не говоря уже о дискретных, просто зачастую сделаны они довольно халтурно)

👩‍💻 Были добавлены 3 новых типа скриптов:
✈️ Одноразовый - запускается вручную или через другие скрипты.
🔄 Перезагружаемый - запускается вместе с игрой.
📝 Компонент - можно прицепить к определённым объектам.
🔤 Обновлена встроенная IDE, теперь она более отзывчивая и поддерживает больше конструкций связанных со скриптингом и Kotlin в целом.
💾 Более гибкая система сохранения, теперь можно сохранять как глобальные данные скрипта, так и удобно делить его на небольшие фрагменты продолжая с того момента, который вы сами укажете.
📦 Полная интеграция с классами игры, то есть весь функционал доступный в обычных модах теперь доступен в скриптах. Позднее появится и возможность импортировать другие моды в скриптах.

- Завершена миграция с Kool на самописный фреймворк интерфейсов 😕
- Теперь пользоваться UI-фреймворком можете и Вы (см. документацию)
- Встроенная IDE, наконец, поддерживает FIR-плагины (Compose и Serialization теперь работают в скриптах), если вы хоть немного шарите в Kotlin, думаю вам это о чём-то да говорит 💻
- Звуки теперь можно настраивать прямо в редакторе (подробнее тут) 📢
- Улучшена навигация NPC в мире 🖥
- Улучшены действия нпс, починен скиннинг и скелетные анимации. Исправлена поддержка моделей форматов `.geo.json` (и molang анимаций) 🤩
- Добавлены node-скрипты, которые можно прикреплять к нпс или другим сущностям, включая игроков ⚙️
- UI-фреймворк теперь использует высокопроизводительные шейдеры, а также поддерживает практически любую векторную графики 🫣