Готовлю редактор нпс к новому обновлению 🛠 | День 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. насчёт варианта с кодом, возможно имеет смысл там несколько заготовок сделать, которые будут выбираться из списка, или хотя бы "историю выражений" добавить

P.S. Скоро появится опрос, а пока держите ролик 👀

Компоненты, сущности и системы ⛳️ | День 63

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

Но пока что я решил на какое-то время взять перерыв от гуишек, поскольку последний месяц буквально каждый день только ими и занимаюсь 😑
Хотя есть и не менее важные задачи, например - работа с данными сущностей. В классическом Minecraft всё очень скудно в этом плане, например, захотели вы сделать, чтобы ваш нпс мог стрелять из лука, как скелет, кидаться огненными шарами как гаст и взрываться как крипер, если рядом игрок - для этого вам придётся взять код из каждой сущности и написать новую. И так для каждой механики, брать код, ctrl+C, ctrl+V... В общем не удобно.
Для этого и существует ECS (Entity Component System), вместо того, чтобы описывать кем является сущность (одновременно лучник, маг, взрыватель), вы описываете что она умеет (стрелять из лука, запускать огненные шары, взрываться), нужно лишь прописать некоторые условия (например, стрелять, если есть стрелы в инвентаре)

В движке ещё с начала осени была подобная система, но достаточно примитивная и с низкой производительностью. Сейчас же я решил попробовать взять за основу Geary, достаточно простой и удобный фреймворк с разнообразным функционалом. Можно как просто прикреплять компоненты, так и указывать отношения между сущностями (условно репутация с нпс или атакуемые цели), можно легко фильтровать сущности по разным признакам и компонентам. Кроме того, эта система достаточно легко справляется с тысячами сущностей или систем, что явно понадобится, когда движок выйдет за рамки базового функционала. На текущий момент я уже реализовал подключение ванильных сущностей и игроков к ECS, а также реализовал сохранение этих самых компонентов внутри игры. Осталось самое сложное - реализовать синхронизацию компонентов между сервером и клиентом.

Кроме того, в Geary уже есть готовая система префабов (шаблоны тех же нпс и их наследование), к которой я ещё у себя толком не приступал, так что это сэкономит нам кучу времени.

Синхронизация ECS 🕊 | День 64

Немного поговорив с автором Geary ECS пришёл к выводу, что у него есть несколько существенных недостатков, которые в ближайшее время исправлять, как я понял не планируют, так что решил ознакомиться с одним из его аналогов - Флексом 🤯
Честно говоря, как будто оба нуждаются в доработке и второй оказался ещё хуже первого 😅
Но на текущий момент я реализовал на Fleks синхронизацию компонентов и в целом это оказалось не так сложно. Кроме того, новая система исправила несколько старых багов: иногда с сервера приходили данные о сущности, которая ещё прогрузилась на клиенте 🫤

Короче говоря, думаю завтра проведу ещё пару тестов и останусь на том, что более производителен и надёжен)

Всё ещё доделываю ECS 😴 | День 65

Как и писал в прошлом посте, я решил всё же вернуться к Geary, а не Fleks и пока пришёл к выводу, что подход с архетипами всё же эффективнее для HollowEngine, чем разреженные множества. Знаю что вам это ни о чём не говорит, но объяснять это всё тут очень долго, кому настолько интересно читайте на Boosty))
Пока что очень много работы с данными, так что и в постах показывать толком нечего, так что держите Виталика, который решил стать зеркалом 🪞