Сворачивание блоков 🗞 | День 48

Большую часть дня потратил на то, чтобы реализовать перетаскивание блоков из левой панели на холст, пока осталось дописать лишь предпросмотр при перетаскивании, но он пока отказывается работать и не может динамически определить размер блока. Можно было бы заткнуть пока костылём вроде фиксированной картинки, но думаю надёжность сейчас всё же важнее 🙃
Ну зато добавил ещё одну удобную фишку: Сворачивание / Разворачивание блоков, чтобы если блок занимает слишком много места, его можно было свернуть до одного заголовка (В будущем у каждого будет свой "упрощённый" вид)

Полноценная панель с блоками и история изменений 📋 | День 49

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

Если исправления багов не займут много времени, то завтра я уже доведу до ума систему триггеров. А сразу после неё выйдет последняя бета перед релизом!

Ещё одно улучшение UX | День 50 📌

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

По сути осталось лишь доработать сам функционал этих триггеров и на этом система блоков кода будет завершена 🙃

Новая система триггеров | День 51 🌐

Сегодня взялся за переработку системы триггеров. Всё оказалось сложнее, но не в техническом плане, а концептуальном... Похоже, нам всё-таки понадобится документация страниц на 15, чтобы объяснить все нюансы 💀

Листая прошлые посты, понял, что толком не объяснял, как всё работало раньше.
Было: Пользователь вручную запускал скрипт командой, тот начинал слушать события и жил до тех пор, пока триггеры не завершатся.
Тут всплыли две проблемы:
1) Автозапуск. Нельзя сделать так, чтобы скрипт стартовал сам, когда игрок заходит на карту. Приходилось бы делать костыли: запускать вручную и создавать отдельный скрипт для каждого игрока на сервере, даже если это условный нпс-торговец на спавне.
2) Одноразовость. Триггеры умирали после срабатывания. Хотите запретить ломать блоки? Старая система запретит сломать один блок, а дальше скрипт завершится. Если же делать их многоразовыми, то действия разных игроков начнут перезаписывать друг друга, ломая логику.

В связи с этим я решил разделить триггеры на локальные и глобальные:
1) Глобальные - это точки входа (например, "Игрок залогинился на сервер"). Они срабатывают всегда и создают отдельный экземпляр скрипта (контейнер) со своими личными переменными для каждого игрока.
2) Локальные - живут внутри этого экземпляра. Например, "Ломание блока". Они могут срабатывать многократно внутри одной сессии игрока, не мешая другим. Плюс, у них есть доступ к общим переменным контекста.

Но тут есть несколько сложных моментов:
- Когда завершать скрипт? Если локальные триггеры срабатывают бесконечно, скрипт будет висеть в памяти вечно.
Варианты решения: Завершать после выполнения глобального триггера? Добавить режим для одноразового/многоразового запуска триггера? Или дать пользователю блок "Завершить скрипт" (который 99% людей забудут поставить и положат сервер 50-ю копиями скрипта)?

- Конкурентность. Что делать, если игрок сломал блок, скрипт начал задержку на 15 секунд, а игрок тут же сломал второй блок?
Варианты решения: Отменять первое действие? Игнорировать второе, пока первое не доработает? Или запускать асинхронно? (Привет, гонка данных и баги в переменных).

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

Таймлайн | День 52 🎬

Сегодня по некоторым причинам, пост делаю я dan_bat :>
Расскажу я вам про таймлайн, который я делаю уже около 2 недель. Суть его в том чтобы вы могли делать кастомные анимации, катсцены и многое другое, не прибегая к коду, чем то это будет похоже на BBS. Вообще Hollow на своем бусти уже рассказывал про таймлайн и то где он будет использоваться, но там не было концепта дизайна...
К счастью с недавних пор у нас в команде появился дизайнер Axel Encore, который уже приложил руку к HollowEngine, если вы активно следили за постами, вы могли увидеть красивый дизайн дерева файлов и системы блоков, тут огромное ему за это спасибо❤️
Так что концепт дизайна у нас теперь тоже есть! Сегодня, если рассказывать про то что уже сделано, то это большая часть логики: Бесконечный таймлайн, система ключей, система групп, блокировка и скрытие треков и обработка свойств ключей.

Просто к пониманию бесконечного таймлайна: в теории вы сможете сделать 18 часовую катсцену, но вряд ли это вообще кому-то будет нужно. Сейчас по сути осталось задизайнить и после уже начать делать интеграцию и реальную логику, ради который этот таймлайн и делался. Если говорить про то сколько займет времени дизайн, то циферка выйдет не маленькая...
Сегодня я начал делать верхнюю линию сия чуда и получилось так что из 892 строк кода получилось 1106...
В такие моменты хочется спросить: "Боже надеюсь это ружье...". В общем, "да": таймлайн делается и находится на хорошей стадии реализации. Надеюсь, что я успею доделать его до конца каникул, и вы сможете протестировать его уже в HollowEngine, а не посмотреть его на видео, которые я буду вам кидать XD.
На этом у меня сегодня все, больше мне вам пока рассказать нечего, если опустить все детали разработки...
Передавайте хорошие пожелания нашей маленько команде разработчиков и в частности пожелайте здоровья Hollow.
Увидимся в следующих постах!

Шейпкеи или же морф таргеты 🎹 | День 53

В последние дни я немного приболел, так что так и не доделал обещанную бету, но теперь я снова тут, и завтра возвращаюсь к разработке 🙃
А пока вот доработал фичу, что просил у меня некий Анонимчик - поддержка шейпкеев для моделей 🫣
Если коротко, это некоторые модификации самих моделей, которые позволяют плавно менять положение некоторых вершин. Как это работает вы можете увидеть в ролике. То есть при желании можно не делать 5-10 моделей под: женскую/мужскую версию, slim/обычный скин, 2 слой скина, всякие декорации и т.п. А просто создать одну модель с готовыми настройками в редакторе 🤯

P.S. Да, это значит, что теперь при желании можно сделать даже редактор персонажа при входе в игру 🔥

Блоки-завершения ⛔️ | День 54

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

На выходных уже буду заниматься моделями и анимациями для нпс, а также багами, которые вы уж точно найдёте 🫠
P.S. В ближайшие 10-15 минут выложу билды в сообществе 👀

Шаблоны и Редактор НПС ♟ | День 55

Сегодня я немного поработал над редактором нпс. Теперь их можно создавать через специальные файлы в системе шаблонов. Если коротко, то через шаблоны можно создавать различные уже настроенные предметы, блоки, самих нпс и многое другое. И для каждого настраивать различные компоненты (фрагменты с логикой)

Пока что интерфейс ещё сыроват, но мы пока думает, как его сделать удобнее 😉
Ну а тем временем, на Boosty вышел новый пост с не менее интересной фичей, ради которой мне пришлось вспоминать физику и 4 часа сидеть с дебаггером меняя один параметр на другой...

Готовлю редактор нпс к новому обновлению 🛠 | День 57

Недавно был закончен дизайн для редактора нпс, так что на текущий момент я занимаюсь его реализацией в игре.
Но в последние дни я всё чаще слышу вопросы о релизе мода, в связи с чем появилась мысль, немного упростить задумку и сделать релиз в ближайшие несколько дней.
Вопрос заключается в том, нужен ли сейчас редактор моделей и анимаций? Задумка у меня следующая: будет компонент для нпс, в котором можно будет открыть редактор модели, который позволит скрыть/показать определённые кости, настроить некоторые части модели (например, настройка костей для рэгдолла или для отображения предметов в руках), а для анимаций планируется граф-подобная система, как в Unity (пока дизайна нет, так что это тоже займёт некоторое время), суть в том, что можно на холсте указать анимации и стрелочками указать переходы, из какой анимации в какую может быть переход и при каких условиях этот переход будет осуществляться.
Вопрос в том, нужно ли сейчас заморачиваться с такими системами, или пока Вам достаточно указать путь к модели и несколько стандартных анимаций (стояние, ходьба, бег и т.п.) без возможности их как либо настраивать?

Предпросмотр анимаций и первые наброски редактора нпс ⏯️ | День 58

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

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

Улучшаю парсер Markdown ✅⬇️| День 59

Пока исправляю всякие небольшие баги, в том числе и в системе разметки Markdown, теперь здесь активно могут использоваться таблицы с центрированием, а в недалёком будущем появятся ещё всякие картинки, предметы, сущности, крафты и т.п.
Кроме того, эту разметку можно будет использовать и в диалогах, т.е. нпс сможет явно упомянуть какой-нибудь предмет или иконку, что, как по мне довольно полезно 🤔

Макет редактора нпс завершён 🧶| День 60

Практически закончил с редактором нпс, остались только некоторые баги с отображением и дёрганьем модельки, но это в целом уже не так долго (надеюсь). Думаю скоро уже перейду к редактору анимаций 👀

Будет ли HollowEngine для Hytale? 🫤 | День 61

Пока я занимаюсь лишь мелкими правками, а макет редактора анимаций ещё дорабатывается, в посте рассказывать особо нечего... Так что сегодня пост про мои мысли на тему Hytale'а и его моддинга!

Сразу предупрежу, что не буду говорить о багах, вылетах, сомнительной стилистике/текстурах, всё же это ранняя версия и многое могут переделать. Прежде всего, что мне понравилось - высокая производительность в сравнении с ванилой и любыми Minecraft сборками. Я буквально захожу в мир, открываю карту, а там уже прогружено множество чанков... И в целом, догнать эту прогрузку летая по миру у меня практически не получалось, что сильно меня порадовало. Но ещё больше, меня радует наличие в игре из коробки теней, динамического и цветного освещения, причём fps при этом существенно выше чем у того же Sodium+Iris. Я уже декомпилировал jar сервера и подробно изучил его ядро. В отличии от Minecraft с его (по большей части) ООП, в Hytale используется ECS, то есть есть некая сущность, на которую крепятся всякие компоненты, причём они крайне разнообразные, помимо ожидаемых здоровья, трансформации (координаты и поворот), скорости и т.п. тут есть и довольно неожиданные для меня подходы, например, на сущность можно наложить компонент телепортации или смерти 🤔
Также поведение мобов куда более интересное в сравнении с Minecraft и как будто здесь даже подходы совсем другие, например, глобальный патчфиндинг, который кэширует пути. Пока не знаю, насколько это реализуемо в том же Minecraft, где буквально всё висит на игроке, и ты не можешь послать условного нпс в соседнюю деревню не выгрузив чанки, а даже если и заставишь, это будет сильно тормозить сервер. В Hytale в свою очередь ECS позволяет симулировать хоть тысячи сущностей одновременно и это не будет так уж сильно нагружать сервер (в сравнении с Minecraft)

Но к сожалению, есть и достаточно весомые минусы, особенно для меня, как мододела. В первую очередь - это полное отсутствие клиентского моддинга. Сделано это для защиты пользователей и клиента в целом, но это также значит, что никаких тебе кастомных GUI'шек, отрисовщиков моделей, эффектов, анимаций и т.п. Всё ограничено встроенным функционалом: их GUI фреймворк, их система моделей и анимаций, их эффекты. Это значит что любые мои наработки касательно визуала - абсолютно бесполезны в рамках Hytale, ни интерфейсов из Kool, ни gltf моделей, ни партиклов на compute-шейдерах. Да даже мелкие фичи, вроде мода MouseTweaks, там не повторить, потому что с сервера нельзя нормально отслеживать мышь игрока. И ладно, ещё если бы их системы были качественными и надёжными, но увы: интерфейсы не поддерживают графы (условно говоря меню квестов как FTB Quests или блоки кода как в HE), нельзя применить какие-нибудь фильтры вроде обрезки или шейдеров, а ещё нет никакой документации, а сама система закрытая из-за чего я даже не могу посмотреть список виджетов или их параметров💀; встроенная система моделей не имеет ни скиннинга со скелетной анимаций, ни шейпкеев (ну или опять таки, в самих файлах и документации я ничего не нашёл); по системе эффектов тоже пока ничего не ясно, можно ли будет создавать свои шейдеры для них и интегрировать с отрисовщиком мира?

В общем для меня этого достаточно, чтобы отказаться от моддинга Hytale в целом. Как игра - она очень даже не плохая, но для моего творчества эта платформа увы пока не годится 🥲
Не исключено, что в будущем ситуация станет лучше и систему интерфейсов доработают, документацию допишут, проблемные места поправят, но пока я пас, есть дела и поинтереснее.

Ну и чтобы не быть голословным, вот небольшой мод, над которым я недавно работал, вернее лучшее чего я смог достичь с текущей системой интерфейсов. В целом можно довести эту систему до ума (но именно как список квестов, а не удобная графовая система), но когда тебе приходится редактировать интерфейсы буквально в блокноте, а любая ошибка в нём кикает тебя с сервера и требует перезагрузки этого самого сервера, то желания этим заниматься постепенно пропадает 🙃
Так что да, никуда я не уйду и как делал HollowEngine, так и буду делать 🙂

Редактор анимаций и переходов между ними 🎞 | День 62

Сегодня я начал графовую систему для анимаций нпс, по итогу было решено сделать что-то напоминающее систему из Unity: граф из анимаций и стрелки, которые отображают переходы между этими анимацями при определённых условиях.
Самое сложное я уже реализовал - это узлы, которые можно перетаскивать, стрелки, которые не перекрывают друг друга, а также прогрутка и приближение, короче говоря за день сделал то, что я делал дней 5 раньше для блоков кода.
Следующий этап - параметры анимаций и переходов. И тут есть 2 варианта:
1) Реализовать это через Kotlin код, условно в условии перехода из анимации Walk в анимацию Run, Вы пишете условие одной строкой: entity.isMoving() && entity.speed >= 0.3.
2) Реализовать это через какой-нибудь конструктор, вроде [Флаг [Сущность двигается?]] и [Параметр [Скорость сущности] [>=] [0.3]].
Лично мне кажется второй вариант не удобным, поскольку написать короткую строку проще, чем выбирать всякие параметры в редакторе, с другой стороны требовать ради этого компилятор Kotlin тоже не хочется, а вы что думаете? 🤔
P.S. насчёт варианта с кодом, возможно имеет смысл там несколько заготовок сделать, которые будут выбираться из списка, или хотя бы "историю выражений" добавить